SCTP: Stream Control Transmission Protocol
Download
Report
Transcript SCTP: Stream Control Transmission Protocol
SCTP: Stream Control
Transmission Protocol
1
Table of Content
Introduction
Motivations for Developing SCTP
SCTP Features
SCTP Terminology
SCTP Packets
SCTP States
SCTP Data Transmission
SCTP and Multihoming
SCTP Streams
SCTP Extensions
Other STCP Research Topics
References and Resources
2
Introduction
3
SCTP
is
a reliable transport protocol
operating on top of a potentially
unreliable connectionless packet
service such as IP.
offers acknowledged error-free
non-duplicated transfer of
datagrams.
a selective retransmission
mechanism is applied to correct
loss or corruption of data.
Application
UDP TCP SCTP
IPv4/IPv6
Link Layer
Physical Layer
IP
Network
4
Motivations for
Developing SCTP
5
Development by IETF SIGTRAN working group
To
create a new, IP based transport protocol
For transport of signaling data over IP-based networks
Anticipation of carrier network convergence
All-IP networks
3GPP networks
based on IPv6 possible
communication between signaling gateways (SGs), media
gateway controllers (MGCs) and signaling end- and transferpoints (SEP, STPs)
6
Problems for TCP
Byte-Stream Oriented
Provide
strict ordering of information, which causes Head of
Line (HOL) Blocking problem
No built-in support for multi-homed IP hosts
Vulnerable for SYN flooding attacks (a kind of DoS attack
using TCP three-way handshake
Problems for UDP
Unreliable data
transfer
No congestion/flow control (applications must handle it by
themselves)
7
SCTP Features
8
Provide an end-to-end reliable transmission service over IP
networks
Support multiple streams: multiple streams per path
Support multi-homed hosts
Message-oriented: conserve message boundaries
Unordered delivery: SCTP can deliver messages as ordered or
unordered.
Congestion Control: SCTP congestion control is similar to TCP.
Multiple IP addresses per host
More tolerant to network failures
Enable seamless introduction of SCTP into IP networks
SCTP is rate adaptive similar to TCP
slow start, congestion avoidance, fast retransmit and fast recovery
delayed Selective ACKs (SACKs) and duplicate SACKs
9
Features Comparison
10
SCTP Terminology
11
Chunk
A unit
of information within an SCTP packet, consisting of a
chunk header and chunk-specific content.
SCTP association
A protocol relationship between
SCTP endpoints.
It is composed of the two SCTP endpoints and protocol state
information including Verification Tags and the currently
active set of Transmission Sequence Numbers (TSNs), etc.
An association can be uniquely identified by the transport
addresses used by the endpoints in the association.
Two SCTP endpoints MUST NOT have more than one SCTP
association between them at any given time.
12
Path
The
route taken by the SCTP packets sent by one SCTP
endpoint to a specific destination transport address of its peer
SCTP endpoint.
Primary Path
The
destination and source address that will be put into a
packet outbound to the peer endpoint by default.
The above definition includes the source address since an
implementation MAY wish to control the return path taken
by reply chunks better and on which interface the packet is
transmitted when the data sender is multi-homed.
Stream:
A uni-directional logical channel
established from one to
another associated SCTP endpoint.
All user messages are delivered in sequence except for those
submitted to the unordered delivery service.
13
14
TSN:SSN
Data Chunk
Application
Application
SCTP
SCTP
s1
s3
s2
7:3
8:3
9:3
4:2
5:2
6:2
1:1
2:1
3:1
s1
Association
buffer
10.0.2.1:999
IP2
IP
s3
s2
buffer
10.0.1.1:999
10.0.1.2:888
IP1
IP1
IP
10.0.2.2:888
IP2
Primary Path
Retransmission Path
15
Idle destination address
An
address that has not had user messages sent to it within
some length of time.
Inactive destination transport address
An
address which is considered inactive due to errors and
unavailable to transport user messages.
SCTP packet
The
unit of data delivery across the interface between SCTP
and the connectionless packet network (e.g., IP).
An SCTP packet includes the common SCTP header,
possible SCTP control chunks, and user data encapsulated
within SCTP DATA chunks.
16
Transmission Sequence Number (TSN)
A 32-bit
sequence number used internally by SCTP.
One TSN is attached to each chunk containing user data to
permit the receiving SCTP endpoint to acknowledge its
receipt and detect duplicate deliveries.
Stream Sequence Number (SSN)
A 16-bit
sequence number used internally by SCTP to assure
delivery of the user messages within a given stream.
One stream sequence number is attached to each user
message.
17
Message Authentication Code (MAC)
An
integrity check mechanism based on cryptographic hash
functions using a secret key.
It is used by an endpoint to validate the State Cookie
information that is returned from the peer in the COOKIE
ECHO chunk.
Verification Tag
A 32
bit unsigned integer that is randomly generated.
It provides a key allowing a receiver to verify that the SCTP
packet belongs to the current association and is not an old or
stale packet from a previous association.
18
SCTP Packets
19
An SCTP packet forms the payload of an IP packet.
An SCTP packet is composed of a common header and
chunks.
A chunk may contain either control information or user
data.
Multiple chunks may be multiplexed into one SCTP
packet up to the Path-MTU size.
Control chunks bundled before data chunks
20
An SCTP-Protocol Data Unit with several chunks
21
SCTP Common Header
Source and Destination Port
Verification Tag
the same port concept as TCP and UDP
the receiver of this packet uses the Verification Tag to validate the sender
of this SCTP packet.
Checksum
each SCTP packet is protected by a 32 bit checksum (Adler-32 algorithm),
which is thus more robust than the 16 bit checksum of TCP and UDP
22
SCTP Chunks
23
Payload Data (DATA) (0)
Stream Identifier
Identifies the stream to which the following user data belongs.
Stream Sequence Number
this value represents the stream sequence number of the following user
data within the stream S.
24
Initiation (INIT)
Initiate Tag
This value MUST be placed into the Verification Tag field of every SCTP
packet.
Advertised Receiver Window Credit (a_rwnd)
This value represents the dedicated buffer space.
25
Initiation Acknowledgement (INIT ACK)
The parameter part of INIT ACK is formatted similarly to the
INIT chunk. It uses two extra variable parameters: The State
Cookie and the Unrecognized Parameter:
26
Selective Acknowledgement (SACK)
27
Selective Acknowledgement (SACK)
SACK is sent to the peer endpoint to acknowledge received
DATA chunks and to inform the peer endpoint of gaps in the
received subsequences of DATA chunks as represented by
their TSNs.
Cumulative TSN Ack
Gap Ack Block Start
Indicates the Start offset TSN for this Gap Ack Block.
Gap Ack Block End
This parameter contains the TSN of the last DATA chunk received in
sequence before a gap.
Indicates the End offset TSN for this Gap Ack Block.
Gap Ack Blocks
TSNs >= (Cumulative TSN Ack + Gap Ack Block Start) and TSNs <=
(Cumulative TSN Ack + Gap Ack Block End)
These TSNs are assumed to have been received correctly.
28
Selective Acknowledgement (SACK)
Duplicate TSN
Indicates the
number of times a TSN was received in
duplicate since the last SACK was sent.
Every time a receiver gets a duplicate TSN (before sending
the SACK) it adds it to the list of duplicates. The duplicate
count is re-initialized to zero after sending each SACK.
29
Selective Acknowledgement (SACK)
TSN=17
Cumulative TSN Ack = 12
miss
a_rwnd = 4660
TSN=15
TSN=14
Num of block=2
12+2 ~ 12+3
miss
12+5 ~ 12+5
TSN=12
Num of dup=0
Block #1 start=2 Block #1 end=3
Block #2 start=5 Block #2 end=5
TSN=11
TSN=10
30
Selective Acknowledgement (SACK)
TSN=16
Cumulative TSN Ack = 10
TSN=15
a_rwnd = 4660
TSN=14
TSN=13
Num of block=1
10+2 ~ 10+6
Num of dup=1
TSN=13
Block #1 start=2 Block #1 end=6
TSN=12
Duplicate TSN 13
miss
TSN=10
31
Heartbeat Request (HEARTBEAT)
Sent by endpoint and to probe the reachability of a particular
destination transport address.
Heartbeat Acknowledgement (HEARTBEAT ACK)
32
Abort Association (ABORT)
It is sent to the peer of an association to close the association.
If an endpoint receives an ABORT with a format error or for an
association that doesn’t exist, it MUST silently discard it.
DATA chunks MUST NOT be bundled with ABORT.
33
Shutdown Association (SHUTDOWN)
An endpoint in an association MUST use this chunk to initiate a
graceful close of the association with its peer.
Shutdown Acknowledgement (SHUTDOWN ACK)
34
Operation Error (ERROR)
An endpoint sends this chunk to its peer endpoint to notify it of
certain error conditions.
Error causes are defined as variable-length parameters
35
Operation Error (ERROR)
Each error cause may carry its own set of parameters. The error
causes that have been defined are
36
Cookie Echo (COOKIE ECHO)
It is used only during the initiation of an association
It must precede any DATA chunk sent within the association, but
may be bundled with one or more DATA chunks in the same
packet.
Cookie Acknowledgement (COOKIE ACK)
37
Shutdown Complete (SHUTDOWN
COMPLETE)
Be sent to acknowledge the receipt of the SHUTDOWN ACK
chunk at the completion of the shutdown process.
38
SCTP States
39
Association
establishment and
shutdown. SCTP uses a
cookie mechanism in a
four-way handshake to
establish an association.
The shutdown process
is a three-way
handshake.
40
Normal Association Establishment
a
41
The endpoint that initiates the association will be referred
to as “Node A”; the peer endpoint that receives the
association establishment requests will be referred to as
“Node B”.
1.
2.
Node A generates an INIT chunk and sends it to
Node B. Node A starts the INIT timer.
If Node B wishes to accept the association, it
generates an INIT_ACK chunk that includes a
cookie. It then sends the INIT ACK chunk, along
with a cookie, back to Node A.
42
3.
4.
5.
Node A receives the INIT ACK chunk and stops
INIT timer. Node A generates a COOKIE ECHO
chunk, which is then sent to Node B. Node A starts
the cookie timer. DATA chunks may be also be
bundled in this packet.
Node B checks the validity of the cookie. Following
validation it sends a COOKIE ACK back to Node A.
Node A receives the COOKIE ACK and enters into
the next phase of data transmission.
43
Association Termination
a
44
1.
2.
3.
Node A sends a SHOTDOWN chunk to Node B and
start the shutdown timer.
Node B acknowledges the receipt of the SHUTDOWN
chunk through the generation of SHUTDOWN ACK
chunk, which is sent to Node A.
Node A receives the SHUTDOWN ACK and responds
by stopping the SHUTDOWN timer. Then, Node A
generates a SHUTDOWN COMPLETE chunk and
sends the chunk to Node B.
45
SCTP Data
Transmission
46
General Concepts
Detection of loss and duplication of data chunks is enabled by
numbering all data chunks in the sender with the so-called
Transmission Sequence Number (TSN).
The acknowledgements sent from the receiver to the sender are
based on TSNs.
Retransmissions are timer-controlled. The timer duration is
derived from continuous measurements of the round trip delay
(RTT).
Whenever such a retransmission timer expires, (and congestion
control allows transmissions) all non-acknowledged data chunks
are retransmitted and the timer is started again doubling its initial
duration (like in TCP).
47
General Concepts
When the receiver detects one or more gaps in the sequence of
data chunks, each received SCTP packet is acknowledged by
sending a Selective Acknowledgement (SACK) which reports all
gaps.
Whenever the sender receives four consecutive SACKs reporting
the same data chunk missing, this data chunk is immediately
retransmitted (fast retransmit).
Most up-to-date operating systems already support a similar
optional extension to TCP.
48
Flow Control
SCTP uses an end-to-end window based flow and congestion
control mechanism similar to the one that is well known from
TCP.
The receiver of data may control the rate at which the sender is
sending by specifying an octet-based window size (the so-called
Receiver Window), and returning this value along with all SACK
chunks.
The sender itself keeps a variable known as Congestion Window
(CWND) that controls the maximum number of outstanding
bytes
Each received data chunk must be acknowledged, and the
receiver may wait a certain time before that is done
49
Selective Acknowledgement
The acknowledgements carry all TSN numbers that have been
received by one side with them.
That is, there is a so called Cumulative TSN Ack value, that
indicates all the data that have successfully been reassembled at
the receivers side, and has either already been delivered to the
receiving Upper Layer Process, or may readily be delivered upon
request.
Moreover, there are so-called Gap Blocks that indicate which
segments of data chunks have arrived, with some data chunks
missing in between.
50
Selective Acknowledgement
Should some data chunks have been lost in the course of
transmission, they will either be retransmitted after the
transmission timer has expired, or after four SACK chunks have
reported gaps with the same data chunk missing. In the latter
case, the missing data is retransmitted via the Fast Retransmit
mechanism.
51
Flow Control for Multihomed Endpoints
By default, all transmission is done to a previously selected
address from the set of destination addresses, which is called the
Primary Address (or Primary Path).
Retransmissions should be done on different paths, so that if one
path is overloaded, retransmissions do not affect this path.
Acknowledgements shall be sent to the transport address from
which originated the data.
52
Congestion Control
According to RFC2960, the congestion control behavior of an
SCTP implementation may have an impact where timely delivery
of messages is required.
The congestion control mechanisms for SCTP have been derived
from RFC 2581 - TCP Congestion Control, and been adapted for
multihoming.
For each destination address (i.e. each possible path), a discrete
set of flow and congestion control parameters is kept.
From the point of view of the network, an SCTP association with
a number of paths may behave similarly as the same number of
TCP connections.
53
Slow Start and Congestion Avoidance
Similar to TCP, SCTP has two modes, Slow Start and
Congestion Avoidance.
The mode is determined by a set of congestion control variables,
which are path specific.
For successfully delivered and acknowledged data, the
congestion window variable (CWND) is steadily increased, and
once it exceeds a certain boundary (called Slow Start Threshold,
SSTRESH), the mode changes from Slow Start to Congestion
Avoidance.
In Slow Start, the CWND is increased faster (roughly one MTU
per received SACK chunk), and in Congestion Avoidance mode,
it is only increased by one MTU per Round Trip Time (RTT)
measurement.
54
Slow Start and Congestion Avoidance
RTO timeout or fast retransmission will trigger retransmission
and cause the SSTHRESH to be cut down drastically and reset
the CWND.
Fast Retransmission
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
RTO timeout
ssthresh = max(cwnd/2, 2*MTU)
cwnd = MTU
55
SCTP and
Multihoming
56
An essential property of SCTP is its support of multi-homed
nodes, i.e. nodes which can be reached using several IP
addresses.
If the according IP networks are configured on physically
different paths, associations become tolerant against physical
network failures and other problems of that kind.
57
Address Management at Association
Setup
If a client is multi-homed, it informs the server about all its IP
addresses with the INIT chunk's address parameters.
The client is only required to know one IP address of the server
although the server provides all its IP addresses to the client in
the INIT-ACK chunk.
SCTP is able to handle IPv4 and IPv6 addresses.
An SCTP instance regards each IP address of its peer as one
“transmission path” towards this endpoint.
If no explicit IP addresses are contained in the INIT or INITACK chunk, the source IP address of the IP packet which carries
the SCTP datagram is used.
58
Path Monitoring
An SCTP instance monitors all transmission paths to the peer
instance of an association.
HEARTBEAT chunks are sent over all paths which are currently
not used for the transmission of data chunks. Each HEARTBEAT
chunk has to be acknowledged by a HEARTBEAT-ACK chunk.
Each path is assigned a state: active or inactive.
The number of events in which heartbeats were not
acknowledged within a certain time or the number of
retransmission events exceeds a certain configurable limit, the
peer endpoint is considered unreachable and the association will
be terminated.
59
Path Selection
At the set-up of an SCTP association, one of the IP addresses
from the returned list is selected as initial primary path. Data
chunks are transmitted over the primary transmission path by
default.
For retransmissions, however, another active path may be
selected, if one is available.
The users of SCTP are informed about the status (state and
measurements) of a transmission path on request or when a
transmission path changes its state. They may then instruct the
local SCTP instance to use a new primary path.
60
SCTP Streams
61
Multiple steams can be used to deliver multiple objects
belonging to the same association
objects on a webpage, multimedia streams (audio/video/text), files in an
FTP
62
Flexible Datagram Delivery
Streams are unidirectional logical data flows that the SCTP
endpoints negotiate during association setup.
SCTP distinguishes different streams of messages within one
SCTP association.
Datagrams can be assigned into different streams within an
association.
Within each stream, SCTP assigns independent Stream Sequence
Numbers (SSN) to the user datagrams. SSNs are used at the
receiver to determine the sequence of delivery.
63
Flexible Datagram Delivery
SCTP performs in-sequence delivery per stream. However, while
one stream may be blocked waiting for the next in-sequence user
message, delivery from other streams may proceed.
The partial in-sequence delivery mechanism avoids head-of-line
blocking between independent streams of datagrams within one
association.
With TCP, this could only be achieved by setting-up several
connections (one per stream) which would lead to additional cost
and overhead.
64
SCTP Extensions
65
Partial Reliability SCTP (PR-SCTP)
PR-SCTP is defined in RFC 3758.
It allows an SCTP sender to signal to its peer that it should no
longer expect to receive one or more DATA chunks.
PR-SCTP consists of two new elements
a single new parameter in the INIT/INIT-ACK exchange that indicates
whether the endpoint supports the extension
a single new chunk type, FORWARD TSN, that indicates the receiver
should move its cumulative ack point forward
PR-SCTP uses lifetime, which is an SCTP parameter, specifies
the life time of the user data, to support "timed reliability"
service.
66
In base SCTP
lifetime is used to avoid efforts to transmit the overdue user messages.
The user data will not be sent by SCTP after lifetime expires.
Attempted to transmit before lifetime expired, the user data will be
(re)transmitted until the peer receives.
In PR-SCTP
The definition of lifetime is extended further.
The lifetime of user data is set to be SCTP_LIFETIME_RELIABLE
(0xFFFFFF), it just likes what base SCTP does. The data are delivered as
reliable transmission.
The lifetime of user data is set to be zero, it will be sent only once. The
lost data will not be retransmitted. The data are delivered as unreliable
transmission.
Otherwise, the data are abandoned no matter if the data have been
(re)transmitted or not when their lifetime expires. The data are delivered
as partial reliability transmission.
If the ack of user data has not been received after lifetime expired, a
Forward TSN chunk is sent to receiver to upgrade and advance its
cumulative TSN point.
67
Advantages of PR-SCTP
A single SCTP association can carry both reliable and unreliable
content. That is, instead of sending different types of data using
separate protocols, the number of datagrams can be reduced to
save network overheads.
PR-data can enjoy the failure detection as the normal reliable
SCTP data traffic dose.
PR-SCTP can provide ordered, unreliable data transfer service.
PR-SCTP employs the same congestion control for all data
traffic, which enforces TCP-friendliness.
68
Streaming over PR-SCTP
MPEG-4 streaming over PR-SCTP
PR-SCTP allows to tune the retransmission per packet. The key
point is that more I frames received, better video quality :
give a long lifetime to I frame to guarantee the reliable transmission of
them
set a shorter lifetime to the P, B frames to limit the retransmission of them
Using PR-SCTP for MPEG-4 video streaming improved video
quality and consistency.
69
Mobile SCTP (mSCTP)
In base SCTP, the IP addresses used are pre-configured and
cannot be changed.
However, this feature limits the use of SCTP for mobile hosts.
The SCTP extension described in ADDIP makes SCTP a
mobility enabled transport protocol.
ADDIP provides SCTP with the ability to:
reconfigure IP address information on an existing association
set the remote primary path
exchange adaptation layer information during association setup
70
Mobile SCTP (mSCTP)
ADDIP extension introduced two new chunk types that will be
used to transfer the control information reliably.
Address Configuration Change Chunk (ASCONF)
Address Configuration Acknowledgment (ASCONF-ACK)
There are three major parameters introduced by ADDIP to
achieve mobility
Add IP Address
Delete IP Address
Set Primary Address
71
get a new IP, send ASCONF with “Add IP” carrying the new IP
add IP into the association, send ASCONF-ACK
send ASCONF with “Set Primary” to change remote primary
send ASCONF-ACK and change primary path
send ASCONF with “Delete IP” carrying the old IP
Node A
delete IP from the association, send ASCONF-ACK
Node B
72
Other STCP Research
Topics
73
Priority stream scheduling
Researchers are investigating the theoretical and
practical implications of adding a priority stream
scheduling scheme to SCTP.
Priorities allow the sending end point to give
precedence to data specified as critical during periods
of increased network delay or decreased throughput.
Priority schemes can help applications adapt to
periods of heavy network congestion or poor quality
of service.
74
Concurrent Multipath Transfer (CMT)
Internet
With
With
CMT
With
TCP
Existing
current Paths
SCTP
Path 1
ISP
1
ISP
4
one
for
for
Notall
used
retransmission
transmission
Path 2
ISP
2
ISP
3
ISP
5
Path 3
ISP
6
75
Transparent SCTP Shim
Migrate existing TCP applications to SCTP transparently
Application gains: fault tolerance, SACK support
http://www.cis.udel.edu/~bickhart/research.html
76
References and
Resources
77
Implementations
www.sctp.org -- a site hosted and maintained by Randy Stewart.
www.sctp.de – contains links to all relevant standards, tools and our
userland-implementation
SCTPLIB -- An SCTP Library maintained by Michael Tüxen. sctplib1.0.3 is the current stable version. socketapi-1.3.2 is the Socket API
Library supports sctplib-1.0.3. sctplib-1.3.1 is the developer's version
supports ADDIP extension.
Hypertext Index of current SCTPLIB snapshot
Upcoming Linux Kernel Implementation developed by Jon Grimm
(IBM), La Monte Yarroll (Motorola) and many others.
The implementation from Randy Stewart has been integrated into the
KAME stack, and additional, more up-to-date patches can be got at
www.sctp.org.
Sun was developing a kernel implementation for Solaris.
78
RFCs, Drafts and Standards
RFC 2960: Stream Control Transmission Protocol.
RFC 3257:Stream Control Transmission Protocol Applicability
Statement.
RFC 3286: An Introduction to the Stream Control Transmission
Protocol (SCTP).
RFC 3309: Stream Control Transmission Protocol (SCTP) Checksum
Change.
RFC 3758: Stream Control Transmission Protocol (SCTP) Partial
Reliability Extension.
RFC 2719 -- Framework Architecture for Signaling Transport, L. Ong
et al.
SCTP Extensions for Dynamic Reconfiguration of IP Addresses, R. R.
Stewart, M. A. Ramalho, Q. Xie, M. Tuexen, I. Rytina, P. Conrad
The SCTP implementor's guide -- The "Don't Panic!"-Draft for RFC
2960, R.R. Stewart, L. Ong, et al.
Mobile SCTP -- describes how SCTP in combination with the addIP
79
extension can be used for providing a mobility concept
Papers and Publications
T. Dreibholz, A. Jungmaier, M. Tüxen: A New Scheme for IP-based Internet
Mobility,
from the Proceedings of the 28th IEEE Conference on Local Computer
Networks (LCN 2003), Bonn/Königswinter, October 2003, pp. X-Z. See also
the slides from the conference presentation !
A. Jungmaier: A Gentle Introduction to SCTP,
a presentation on SCTP given at the 19th Conference of the German CCC,
Berlin, December 2002.
A. Jungmaier, E.P Rathgeb, M. Tüxen :
On the Use of SCTP in Failover-Scenarios,
from the Proceedings of the SCI 2002, Volume X, Mobile/Wireless
Computing and Communication Systems II; Orlando, USA; July 2002, pp.
363-368.
A. Jungmaier,M. Schopp, M. Tüxen :
Performance Evaluation of the Stream Control Transmission Protocol
(English) - From the "Joint IEEE ATM Workshop 2000" (ATM 2000
Conference, Heidelberg, Germany), June 2000.
80
Papers and Publications
A. Jungmaier, E.P Rathgeb, M. Schopp, M. Tüxen :
SCTP - A multi-link end-to-end protocol for IP-based networks,
AEÜ - International Journal of Electronics and Communications, 55 (2001)
No.1, pp. 46-54.
A. Jungmaier,M. Schopp, M. Tüxen :
Das Simple Control Transmission Protocol (German)
Veröffentlichung in "Elektrotechnik und Informationstechnik", Heft 06/2000.
Ivan Arias Rodriguez :
Stream Control Transmission Protocol - The Design of a New Reliable
Transport Protocol for IP Networks
Seok J. Koh, et al., “mSCTP for Soft Handover in Transport Layer”, IEEE
Communications Letters, Vol. 8, No. 3, pp. 189 – 191, March 2004.
Hongtao Wang; Yuehui Jin; Wendong Wang, “The performance comparison of
PRSCTP, TCP and UDP for MPEG-4 multimedia traffic in mobile network”
Janardhan R. Iyengar, Keyur C. Shah, Paul D. Amer, “Concurrent Multipath
Transfer Using SCTP Multihoming”
G. Heinz P. Amer, “Priorities in SCTP Multistreaming”, SCI '04, Orlando, FL,
7/04
81
Software
Ethereal, the excellent packet tracer that was used throughout most of
our debugging sessions, and has been modified to support SCTP by M.
Tüxen.
Dummynet,the excellent network emulation module that comes with
FreeBSD.
Tcpdump has become SCTP aware !! It can be downloaded from here.
SCTP support was added by Jerry Heinz (Temple University), John
Fiore (U of Pennsylvania), and Armando Caro (University of
Delaware).
The network simulator (ns-2). An SCTP patch for ns-2 is available
here, thanks to Armando Caro and Janardhan Iyengar.
82
SYN Flooding Attack
attackers
victim
Flooded!!
SYN
128.3.4.5
SYN-ACK
ACK
TCB
TCB
TCB
TCB
SYN
221.3.5.10
SYN-ACK
ACK
TCB
Unavailable, reserved resources
• There is no ACK in response to the SYN-ACK, hence connection
remains half-open
• Other genuine clients cannot open connections to the victim
• The victim is unable to provide service
83
Head-of-Line Blocking in TCP
Sender
Receiver’s App
Receiver
1
2
3
ACK 1
1
ACK 2
2
4
5
ACK 2
ACK 2
Packet 3 is blocking the
head of the line.
84
Head-of-line Blocking
TCP provides a single data stream.
When a segment is lost, subsequent segments must wait
to be processed.
Problem for some applications (telephony)
85
Slow Start & Congestion avoidance
20
Congestion occurs
Congestion
avoidance
Congestion
avoidance
15
Congestion
window
Threshold
10
5
Slow
start
Slow
start
0
Round-trip times
Timeout
86
Fast retransmit
Sender
1
2
3
4
5
Receiver
ACK 1
ACK 2
ACK 2
6
four consecutive
SACKs
ACK 2
ACK 2
retransmit 3
ACK 6
87