A Survey of the Stream Control
Transmission Protocol
Sivadon Chaisiri
Parallel and Distributed Computing Centre (PDCC)
School of Computer Engineering
Nanyang Technological University, Singapore
Email: siva0020@ntu.edu.sg Matriculation Number: G0703431D
Abstract—This paper represents a survey of the Stream Con-
trol Transmission Protocol (SCTP) which has more advantages
than the Transmission Control Protocol (TCP) in the TCP/IP
transport layer. Due to the original limitation of TCP, SCTP
is designed for the improvement. Currently, IETF offers SCTP
as a general-purpose protocol for Internet applications. This
survey shows main features of SCTP such as multistreaming
and multihoming which can be applied for many applications
to avoid head-of-line blocking , to increase high throughput
of data transfer, and to offer high-availability communications.
Furthermore, some examples of applications using SCTP are
introduced. Moreover, the analysis studies of SCTP performance
are also included. Finally, some comments on SCTP are suggested
for further improvement.
I. BACKGROUND K NOWLEDGE
The TCP/IP model is introduced for using in the Internet
and other similar networks. It provides the layered architecture
which has less complexity than the standard OSI model. The
TCP/IP model composes of link layer, Internet layer, transport
layer, and application layer [17]. The link and the Internet
layers provide only hop-to-hop protocols, while the upper ones
provide end-to-end protocols. This survey mainly focuses on
the transport layer that provides services for communications
between two or more end-point application. Main service
functions provided by the transport layer are flow control,
error detection / recovery, congestion avoidance, and reliable
delivery. Originally, the model introduced two core protocols,
Transmission Control Protocol (TCP) and User Datagram
Protocol (UDP), for handling two different types of commu-
nications, connection-oriented communication respectively.
UDP [18] does not add anything to the underlying layers
except to offer end-to-end communications. Although UDP
is connectionless, unreliable protocol; it produces a minimum
overhead and can be greatly applied for some applications
which do not concern much reliability.
UDP is useful; however, it is not suitable for many ap-
plications running on the Internet. The link and the Internet
layers might not offer reliable communications; so TCP [19]
is designed as a connection-oriented, reliable protocol. TCP
provides services that guarantee the reliable delivery such as
flow control, error control, and congestion control.
II. I NTRODUCTION TO SCTP
The Stream Control Transmission Protocol (SCTP) [20] is
the latest TCP/IP transport protocol offering a connection-
oriented, reliable end-to-end communication like TCP. While
today TCP supports functions required by most popular ap-
plications on the Internet, it has some disadvantages. Later,
SCTP was introduced.
Initially, SCTP was standardized by the Signaling Trans-
port (SIGTRAN) working group of the Internet Engineering
Task Force (IETF) for supporting Signaling System 7 (SS7)
messages, a set of telephony protocols, over IP networks [1],
[2]. The SS7 transport requires reliable and timely delivery.
Absolutely, TCP was also evaluated for the transport; however,
it has several limitations presented later.
Basically, SCTP was derived many functions from TCP, but
SCTP enhances more improvements. Currently, SCTP is of-
fered by IETF as a common transport layer protocol like TCP
and UDP. Two major features of SCTP are multistreaming and
multihoming as discussed next.
A. Multihoming
SCTP is designed to enable fault resilience during network
failures. In SCTP terminology, a term association is compa-
rable to a TCP connection. One endpoint of association can
bind to one or more IP address. For example, an endpoint
registers two IP addresses over two different links/paths (one
address per one link independently), wired link and wireless
link. When setting up an association, the endpoint chooses the
wired link as the primary path. If the wired link is down, it can
transparently reroute to the available wireless link and continue
its ongoing activity over the same opening association. The
multihoming feature allows high availability communications
by reusing redundant links. The multihoming mechanism is
not supported in TCP.
Fig. 1 illustrates an association consisting of two redundant
links in which endpoint has two network interfaces (i.e.,
eth0 and eth1), the former is for the 802.3x wired Ethernet
network and the latter one is for 802.11x wireless network.
The sender selects the eth0 as the primary interface to transfer
data to the receiver, illustrated in Fig. 1(a). At some point
of time, the receiver’s line is down. Then the multihoming
mechanism transparently switches to the wireless network
(shifting to the sender’s and the receiver’s eth1 interfaces) to
continue the holding communication without reestablishing a
new association, shown in Fig. 1(b).
 Fig. 1. An association consisting of two redundant links/paths: the sender is choosing the wired network (a) the wired network is down (b).
Fig. 2. An example of head-of-line blocking occurred when B2 is lost.
B. Multistreaming
Multistreaming can multiplex data from the application
layer onto a single association. A data segment (or chunk [2],
[13]) is transferred in a stream. One association can carry
one or more stream. Each stream independently transports
each different set of segments. If a segment of one stream
is lost, segments belonging to other streams are not affected
and continuing their transfer.
TCP is conformed to strongly strict ordered delivery, so
it causes a head-of-line (HOL) blocking in some cases for
making sure that the data will be arrived at the destination
as the accurate orders. If a packet is lost, sequencing packets
are queued up in the receiver buffer for reordering until the
lost packet is resent from the sender. This blocking increases
a packet transfer delay.
In Fig. 2. illustrates an instance when the sender has 2
data, A and B, sending to the receiver. Each data consists
of 3 segments equally. The sender is transmitting both data
over a single TCP connection. At some point of time, the
receiver’s buffer kept four data segments including A2, B1, A1,
and A3 for later correcting their order before delivering to its
application. When B2 is lost during transmission, it causes the
HOL blocking to wait for retransmission of B2. Although the
entire data A is arrived, it cannot be sequenced and delivered
to the application.
SCTP avoids the HOL blocking, where each stream carries
only its segment concurrently and independently [9]. The HOL
blocking can be found within the scope of individual streams
Fig. 3. An SCTP association consisting of five streams.
without affecting to the entire association. In Fig. 3, if Stream
3 is in the HOL blocking state, other four streams have no
effects to this Stream 3.
C. Comparison of TCP and STCP
A comparison of TCP and SCTP based on [1] is illustrated
in Table I. The first row shows that SCTP supports the
multihoming capability, while TCP cannot support this feature.
The second row in Table I shows the multistreaming capability.
A multistreaming-like function can be implemented on TCP
by establishing multiple connections, but it can waste many
resources and much overhead for maintaining these connec-
tions. SCTP supports the real multistreaming on a single one
association with less overhead.
The next comparison in the third row shows how different
between TCP and SCTP is, when setting up new connections
/ associations. When setting up a new connection, TCP uses a
three-way handshake, as shown in Fig. 4(a). A new connection
on the server is established, when receiving an INIT message
from the client. In this way, TCP is vulnerable to a denial of
service (DoS) attack called SYN flooding attack; an attacker
continuously sends many bogus SYN messages to the server.
After receiving a SYN message, the server allocates some
memory space for a new connection. Finally, at some point
of time the server’s free memory will be exhausted to offer
non-attacker clients.
SCTP avoids the SYN flooding attack by following a four-
way handshake, as shown in Fig. 4(b). A new association is

C OMPARISON OF TCP AND SCTP
Multihoming support
Multistreaming per stream
Setup connections/associations
Shutdown connections/associations
Half-open support
Ordered delivery
Unordered delivery
Message boundary
Selective Acknowledgement
Keep alive heartbeat
Fig. 4. Setup connections/assoications: TCP three-way handshake (a), and
SCTP four-way handshake (b).
established after the client got the server’s INIT ACK and
then returned the COOKIE ECHO back to the server. The
INIT ACK message includes the cookie information (e.g.,
IP addresses of endpoints, stream number, etc.), which the
client must return the COOKIE ECHO back to the server.
So the server does not maintain an association state, although
TABLE I
TCP SCTP
Not Supported Supported
By multiple TCP connnections By a single one association
Three-way handshake Four-way handshake
Four-way handshake Three-way handshake
Supported Not supported
Strict ordered Ordered within a stream
Not supported Supported
Stream-oriented Message-oriented
Option Mandatory
Not support Supported
receiving the client’s INIT, which can avoid the attack.
The fourth row in Table I relates to a shutdown mechiansm.
When an endpoint engages a shutdown process, it can keep
the connection alive, also called the half-open, for receiving
further incoming data from another side. TCP supports this
half-open connection via a four-way handshake shutdown;
while SCTP does not support the half-open by using a three-
way handshake shutdown, as compared in the fifth row.
Both TCP and SCTP supports reliable ordered delivery
mode, as presented in the sixth row. TCP only supports strict
ordered, while SCTP supports ordering delivery per a stream.
Moreover, SCTP offers unreliable, unordered delivery mode
like UDP; while TCP does not support this mode, as noted
in the seventh row. Furthermore, SCTP also provides partially
ordered mode or partial reliability communication, which one
association consists of both ordered delivery and unordered
delivery modes; either of them is assigned for a stream. The
partial reliability mode is useful for applications requiring both
modes at the same time. For example, an association carries
three distinct contents including image, text, and video; which
both image and text require ordered delivery, while the video
is compromised to transfer with the unordered mode.
The next row presents the fact that TCP is a stream- (or
byte-) oriented protocol in which data represent as a series of
bytes, implied that the data has no boundary. So application
developers have to specify scopes of such sequenced bytes
as boundary messages. In comparison, SCTP is a message-
oriented protocol. The SCTP transport layer treats data re-
ceived from the above application layer as messages. As long
as there is a sufficient buffer at the receiver, a whole individual
message can be delivered to the receiver without combining
itself to another message.
The ninth row in Table I relates to a selective acknowledge-
ment (SACK) mechanism. This mechanism is used for a fast
retransmission that speeds up loss detection and also increases
bandwidth utilization. SACK is supported in TCP as an option
[21], while SACK is mandatory in SCTP. An old mechanism
using in TCP is a cumulative acknowledgement scheme, this
induces a sender either to learn about lost packets in each
roundtrip time, or to retransmit segments which just have been
accurately got by its receivers. SACK allows the receivers to
inform their senders about all arrived correct segments; hence
the senders just transmit only the lost ones.
The last row in Table I refers to the keep-alive mechanism
used to detect unreachable or idled hosts during communica-
tions. A host uses a keep-alive message to probe its other
connected hosts. If a connected host does not response to
the message in threshold duration, this host is assumed as an
unreachable one. TCP supports this mechanism as an option,
while it is mandatory in SCTP.
D. Summary of SCTP Features
Based on a list of SCTP features presented in [2], this
summary shows interesting features of SCTP as follows
• Message-oriented protocol. SCTP is the message-oriented
protocol, while TCP is the stream-oriented protocol.
• Multihoming support. This feature offers high-availability
to applications. Moreover, the multihoming also induces
a concurrent multipath transmission, as discussed in the
next section.
• Avoiding HOL blocking. The SCTP multistreaming is
used to encounter HOL blocking.
• Three delivery modes support. SCTP supports ordered
delivery, unordered delivery, and partially ordered modes.
• Selective acknowledgement support. SACK is mandatory
in SCTP.
• Heartbeat keep-alive mechanism. This mechanism is
mandatory in SCTP.
• DoS protection. As mentioned early, the three-way hand-
shake of SCTP can protect the SYN attack found in TCP.
III. A PPLICATION U SINIG SCTP
A usage of SCTP was introductorily proposed for signaling
transport applications such as VoIP. Currently it is determined
in the wider range of applications, as presented by [1], [3],
[4], [5], [6], [7] as some instances. This section presents
some examples of applications using SCTP which include file
transfer, web applications, high availability servers, parallel
transmission or concurrent multipath transmission, and multi-
streaming over mobile devices with limited memory.
A. File Transfer Applications
File transfer protocol (FTP) [15] is a protocol used to
transfer files from one host to another host. This protocol is
widely used in the Internet. Originally, FTP is implemented
by TCP. Although TCP offers the reliable transfer for FTP
connections, it induces so much overhead. The first main
overhead comes from the nature of FTP which consists of two
separate control and data flows. These two flows produce extra
overhead. Moreover, the control flow is venerable to timeouts
because of its control commands.
Furthermore, FTP over TCP also has one limitation on
the data flow which is non-persistent that introducing much
overhead. For example, when a client needs to transfer a file,
even request a list if directories; a connection must be setup
which introduces overhead. In addition, overhead incurs for
each file transfer due to sending a control command.
Instead of using TCP, Ladha and Amer [3] introduce ap-
plying SCTP multistreaming for FTP. They introduce three
implementations as follows
1) FTP over SCTP by keeping the same semantics of the
classic FTP. This way mimics the FTP which means one
SCTP association for the control flow and the other one
for the data flow.
2) FTP over SCTP with multistreaming feature to combine
both control and data flows together into a same asso-
ciation.
3) FTP over SCTP with multistreaming and command
pipelining. The additional command pipelining avoids
unnecessary reduction of congestion window size (cwnd)
for a multiple file transfer.
Their experiments have done by comparing the new 3 ways
and the original FTP over TCP by observing transmission
time and percent of loss possibility. The results show that
all SCTP versions perform much less loss packets and much
faster transfer. The implementation with command pipelining
is the best one. The next better one is FTP over SCTP with
only multistreaming. Though the first implementation is not
changed from TCP much, SCTP can outperform TCP. The
more efficient congestion control and the robustness (e.g., error
recovery) of SCTP are the reasons.
B. Web Applications
Web applications such as Internet web browsers generally
use HTTP over TCP to retrieve data over the Internet [16].
The evolution of web contents introduces more variety of data
presented on a single web page or once retrieval. The contents
can be HTML text, images, video, audio, and any executable
scripts/programs such as Java Applets, ActiveX and Flash.
A various kinds of web contents could be transferred to a
client in a single one TCP connection, but this way induces a
HOL blocking. On one hand, an individual bundle of content
can be delivered independently to present on a client; which
content arrives the client first, then it presents first. Many
web applications establish multiple TCP connections; each
one transfers a bundle of content. This method concurrently
delivers and presents more content to a client, but it consumes
much resource due to multiple established connections.
Fu and Atiquzzaman [1] introduce to use the multistreaming
mechanism to transfer many web contents in parallel fashion,
one bundle of content per one stream. In [4], Y. J. Lee and
M. Atiquzzaman apply HTTP over STCP; however, this work
did not cover a usage of multistreaming. They compare the
object transfer latency between HTTP over SCTP and HTTP
over SCTP during the slow start phase of a congestion control.
They conclude that the latency of the HTTP over SCTP is less
than HTTP over TCP by 11%.
C. High Availability Servers
The SCTP multihoming feature can be applied for any ap-
plications requiring high availability, such as high availability
servers (HA servers), by using the redundancy of links, as
shown in Fig 2. This feature does not appear in both UDP and
TCP as mentioned. A host is multihomed when it has two or
more network interface. Each interface binds an IP address to
its individual link. The multihoming mechanism selects a link
(e.g., the most reliable and fastest link) as primary. When the
primary link is down, the mechanism reuses another redundant
link. An example of HA servers can be database servers and
application servers which offer critical functions (e.g., banking
and financial services). Another application is mobile devices
including multiple network interfaces. For example, a mobile
device with two network interfaces (i.e., 802.11b and GPRS)
can switch to one of these two links, when one link is down.
D. Concurrent Multipath Transmission
One powerful function provided by the multihoming feature
is the concurrent multipath transfer (CMT). CMT increases
high throughput of transmission by distributing data to mul-
tiple paths simultaneously. TCP can offer a kind of parallel
transfer by creating multiple TCP connections. This way
increases throughput in high bandwidth networks. The transfer
must be done along the same path to a receiver, while CMT
utilizes multiple different paths concurrently. Some examples
of CMT applications can be file download accelerators, Inter-
net web browsers, load-balancing server farms, and parallel
computing programs.
Iyengar et al. [5] introduce algorithms to implement CMT
to avoid three negative side-effects of CMP which are (1)
unnecessary fast retransmission by a senders; (2) overly con-
servative cwnd growth at a sender; and (3) increased traffic
of acknowledgement (ACK) due to fewer delay ACKs by
a receiver. They conclude that CMT also enhances fault
resilience for transmission. An original SCTP has to explicit
probe to gather about path information. If the probe is done
infrequently or an association is idled for a while, a host
may be not aware of an unreachable path. CMT is able
to counter this limitation, because it simultaneously utilizes
multiple paths in which those paths are implicitly probed.
Perotto et al. [6] offer an issue of CMT implementation
plugged to the original SCTP. They implement two SCTP
implementations, SBPP-SCTP and W-SCTP which support
CMT. Their experimental results show that SBPP-SCTP and
W-SCTP increase much more throughputs than the original
unsupported-CMT SCTP.
E. Mobile Devices with Limited Buffer Size
An amount of data that can be sent by a sender, over either
TCP or SCTP, is limited by a cwnd size and its receiver’s
buffer size. If a destination host does not have much available
buffer, it can reject to keep incoming data.
Atiquzzaman and Ivancic [7] propose to use SCTP mul-
tistreaming for small-memory devices, especially mobile de-
vices with limited buffer size such as wireless, satellite, and
radio devices. Their simulation shows that SCTP performs
more efficient than TCP. They present that the multistreaming
can reduce the requirement of the receiver’s buffer and increase
throughputs by avoiding HOL blocking at the receiver. This
implies that SCTP can work well on such devices which have
less memory and battery-power.
IV. P ERFORMANCE E VALUATION OF SCTP
This section represents performance evaluation studies of
SCTP. They reveal some experiments and measurements to
show that SCTP can be efficiently applied for Internet applica-
tions due to acceptable results. The first study studies an event
whenever TCP and SCTP concurrently share the same network
resources. Then the study of throughput performed by SCTP is
explored. Next, the observation of HOL blocking induced by
SCTP is presented. Finally, the study of a congestion control
mechanism over SCTP multistreaming is introduced.
A. Two Competing Protocol Instances
SCTP congestion control is designed similar to that of TCP
with a goal that is to assure that SCTP will not behave more
aggressively than TCP or SCTP traffic will consume more
network resources than TCP traffic.
Jungmaier et at. [12] evaluate how SCTP performs in a
network, when competing with TCP. When loading packets
with different sizes, they show that SCTP traffic has the
similar throughput controlled by the congestion decision of
TCP connections as general TCP traffic; if the transport
protocol of some applications was changed from TCP to
SCTP, the performance of other TCP applications would not
be affected. They present that SCTP is neither more nor less
aggressive than TCP. Finally, they conclude that TCP and
SCTP connections share resources fairly and SCTP will not
degrade the performance of existing TCP traffic. This can be
implied that SCTP can be a general purpose protocol like TCP.
In addition, Afzal et al. [11] also present the same conclusion
taht SCTP and TCP perform similar behavior in term of delay
in a single flow and competing network traffic.
B. Throughput
Islam and Kara [13] analyze the throughput of the SCTP
multihoming mechanism by focusing on different data chunk’s
sizes. Their experimental results show that SCTP gain higher
throughput during large data chunks transmission, because
the SCTP multihoming lets a sender to retransmit lost data
chunks via another redundant path which reduces the chance
of missing retransmitted ones (or lessening the possibility
of packet loss), and causes rarely loss in the throughput
during large chunks transmission. They summarize that SCTP
increases the throughput due to the progressive congestion
control mechanism such as SACK, limited transmit, and
appropriate byte counting, as presented as follows
• As mentioned before, SACK is mandatory in SCTP. This
mechanism avoids the problems found in the cumulative
acknowledgement using in TCP.
• The limited transmit mechanism allows a sender to use
a fast retransmit algorithm when recovering lost chunks,
rather than using a high cost retransmission timeout.
 • SCTP increases cwnd size by counting a number of
acknowledged bytes instead of a number of SACK
messages. This is the appropriate byte counting which
prevents slow increment of cwnd size found during large
chunks transmission.
Afzal et al. [11] observe the SCTP congestion control on
the transmission throughput during different loss probability is
generated. They also found that SCTP takes higher throughput
than TCP due to the progressive congestion control.
As mentioned in the previous section, CMT [5], [6] is
introduced by leveraging the SCTP multihoming mechanism
which is able to transfer multiple data over different paths
concurrently. In this way, CMT over SCTP can increase much
more throughputs and take less latency.
C. Head-of-Line Blocking
Grinnemo et al. [9] have conducted an experimental study
on HOL blocking in SCTP. They study on the impact of HOL
blocking of the ordered delivery mode and also the unordered
delivery mode. They found that although HOL blocking is
happened during the reliable delivery, this produces only a
marginal impact on the transmission delay. When testing the
same sample on the unreliable delivery, they observe that the
improvements are in the range of 0% to 18% in average
message transmission delay.
D. Congestion Control over Multiple Streams
Seo et al. [8] observes an SCTP congestion control in
terms of fairness among streams within SCTP associations,
when initiating the multistreaming feature. They found that a
multistreaming application with only one congestion control
per one association (named global congestion control) does
not give the fairness for every stream. If a single lost data
chunk is incurred inside a specific stream, the congestion
control reduces cwnd size of the whole path affecting to every
stream. They suggest using a stream congestion control that
each stream is managed by a particular congestion control sep-
arately and independently. This mechanism can offer fairness
among streams.
V. C OMMENTS ON I MPROVEMENTS
This section introduces comments on future improvements
of SCTP. There are three issues -implementation, performance,
and security.
A. Implementation Issues
There are a small number of widely, commonly used imple-
mentations of SCTP. Most of them are provided for a specific
platform, especially Linux operating systems. This could be a
gap between application developers and SCTP. Some of them,
both commercial and open-source, are introduced in [1].
More open-source versions of SCTP libraries and SDKs
with supporting many useful SCTP functions should be de-
veloped as developers’ options. SCTP should be provided for
common platforms, not only Linux, such as Windows, Ma-
cOSX, Google’s Android, Symbian, and Java virtual machine.
B. Performance Issues
This issue discusses two topics. The former topic relates to
the multistreaming mechanism, and the later one presents an
issue of CMT provided by the multihoming mechanism.
The multistreaming offers an application to create multi-
ple streams. Each stream consumes an endpoint’s resources.
If there are so many streams inside an association, many
resources can be much more consumed. This side-effect is
significant for devices with limited capability such as mobile
devices. One way that we can encounter this problem is to
turn off one or more idled stream, when it is not in use for
a while. In the other hand, every stream may be not utilized
at the same time, which some of them can be turned-on only
when its application needs.
CMT provided by SCTP is an interesting solution for
increasing the transmission throughput; however, this method
increases a bottleneck at a receiver’s side to reorder received
data from multiple paths. This problem can be solved by new
models of processors such as multi-core or SMT processors,
which multiple threads can reorder the data receiving from
many paths concurrently. To improve by software, this issue
is one open topic for research.
C. Security Issues
Although SCTP can protect the SYN flooding attack (a type
of DoS), SCTP and TCP cannot avoid a distributed denial of
service (DDoS) attack. DDoS is an attack method controlling
multiple attackers located over the Internet to flood messages
to a same target concurrently. This type of attack can be
protected by some methods presented in [14].
VI. C ONCLUSION
SCTP can be applied for Internet applications like general-
purposed protocols such as UDP and TCP. Due to its re-
liable, connection-oriented communication; SCTP provides
functions like TCP. Multihoming and multistreaming are its
major features which can highly increase both robustness and
performance for data communications.
In this survey, some SCTP applications are introduced
such as file transfer applications, web applications, concurrent
multipath transmission, high-availability servers and mobile
applications with limited memory.
The survey also presents the performance evaluation studies
of SCTP protocols. The results of studies show that SCTP has
more advantages than TCP which are less delay, less packet
loss, less HOL blocking, more efficient congestion control,
and higher throughput of data transfer.
In the last discussion, the survey shows three issues for
further improvements of SCTP - implementation, performance,
and security issues. The implementation makes a gap between
developers and SCTP due to the small number of widely and
commonly used development libraries. The next issues relate
to SCTP performance including multistreaming performance
and CMT performance. The last issues discuss the DDoS
which can be happened in SCTP, but a number of solutions are
explored for defending this problem. Some simple solutions
are also introduced for further improvements of these issues;
however, they are still the open issues in which we need to
find out appropriate solutions.
ACKNOWLEDGMENT
This survey is a part of the course Computer Networks
(EE6108) under School of Electrical and Electronic Engineer-
ing, Nanyang Technological University. The author would like
to thanks all professors and instructors of this course.
R EFERENCES
[1] S. Fu and M. Atiquzzaman, SCTP: State of the Art in Research, Products
and Technical Challenges, IEEE Journal Communication Magazine, April
2004
[2] R. Stewart and C. Metz, SCTP New Transport Protocol for TCP/IP, IEEE
Internet Computing, November-December 2001
[3] S. Ladha and P. D. Amer, Improving File Transfer Using SCTP Multi-
streaming, IEEE International Conference on Performance, Computing,
and Communications, 2004
[4] Y. J. Lee and M. Atiquzzaman, HTTP Transfer Latency over SCTP and
TCP in Slow Start Phase, IEEE International Conference on Communi-
cations, 2007
[5] J. R. Iyengar, P. D. Amer, and R. Stewart, Concurrent Multipath
Transfer Using SCTP Multihoming Over Independent End-to-End Paths,
IEEE/ACM Transactions on Networking, Vol. 14, No. 5, October 2006
[6] F. Perotto, C. Casetti, and G. Galante, SCTP-based Transport Protocols
for Concurrent Multipath Transfer, IEEE Wireless Communications and
Networking Conference, 2007
[7] M. Atiquzzaman and W. Ivancic, Evaluation of SCTP Multistreaming over
Wireless/Satellite Links, IEEE International Computer Communications
and Networks, 2003
[8] D. W. Seo, H. Kim, and J. G. Kim, Analysis of Dynamic Congestion
Control of SCTP, IEEE International Conference on Convergence and
Hybrid Information Technology, 2008
[9] K. J. Grinnemo, T. Andersson, and A. Brunstrom, Performance Benefits
of Avoiding Head-of-Line Blocking in SCTP, IEEE Joint International
Conference on Autonomic and Autonomous Systems and International
Conference on Networking and Services, 2005
[10] A. Chukarin and N. Pershakov, Performance Evaluation of the Stream
Control Transmission Protocol, IEEE Mediterranean Electrotechnical
Conference, 2006
[11] M. K. Afzal, A. U. Khan, A. Pescape, Y. B. Zikria, and S. Loreto,
SCTP vs. TCP Delay and Packet Loss, IEEE International Multitopic
Conference, 2007
[12] A. Jungmaier, M. Schopp, and M. Tuxen, Performance Evaluation
of the Stream Control Transmission Protocol, IEEE High Performance
Switching and Routing Conference, 2000
[13] M. N. Islam and A. Kara, Throughput Analysis of SCTP over a Multi-
homed Association, IEEE International Conference on Computer and
Information Technology, 2006
[14] J. Mirkovic and P. Reiher, ”A Taxonomy of DDoS attack and DDoS
Defense Mechanisms”, ACM SIGCOMM Computer Communication Re-
view, 2004
[15] J. Postel and J. Reynolds, File Transfer Protocol (FTP), IETF RFC959,
http://tools.ietf.org/html/rfc959
[16] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
P. Leach, and T. B. Lee, Hypertext Transfer Protocol – HTTP/1.1,
http://tools.ietf.org/html/rfc2616
[17] R. Braden, Requirements for Internet Hosts - Communication Layers,
IETF1122, http://tools.ietf.org/html/rfc1122
[18] J. Postel, User Datagram Protocol, IETF RFC768,
http://tools.ietf.org/html/rfc768
[19] ”Transmission Control Protocol, IETF RFC793,
http://tools.ietf.org/html/rfc793
[20] R. Stewart, Ed, Stream Control Transmission Protocol, IETF RFC4960,
http://tools.ietf.org/html/rfc4960
[21] M. Mathis, J. Mahdavi, and S. Floyd, TCP Selective Acknowledgement
Options, IETF RFC2018, http://tools.ietf.org/html/rfc2018