A Survey Of The Stream Control Transmission Protocol

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: [email protected] Matriculation Number: G0703431D

Abstract—This paper represents a survey of the Stream Control 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 communications, 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 applications 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 applications on the Internet, it has some disadvantages. Later, SCTP was introduced. Initially, SCTP was standardized by the Signaling Transport (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 offered 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 comparable 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.

Fig. 2.

An association consisting of two redundant links/paths: the sender is choosing the wired network (a) the wired network is down (b).

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 connections. 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 fourway handshake, as shown in Fig. 4(b). A new association is

TABLE I C OMPARISON OF TCP AND SCTP

Multihoming support Multistreaming per stream

TCP

SCTP

Not Supported

Supported

By multiple TCP connnections

By a single one association

Setup connections/associations

Three-way handshake

Four-way handshake

Shutdown connections/associations

Four-way handshake

Three-way handshake

Half-open support

Supported

Not supported

Ordered delivery

Strict ordered

Ordered within a stream

Unordered delivery

Not supported

Supported

Message boundary

Stream-oriented

Message-oriented

Option

Mandatory

Not support

Supported

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

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 threeway 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 messageoriented protocol. The SCTP transport layer treats data received 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 acknowledgement (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 communications. 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 handshake 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 multistreaming 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 applying 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 association. 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 applications 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 multiple 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, Internet 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 conservative 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 multistreaming for small-memory devices, especially mobile devices 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 applications 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 separately 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 implementations 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 developed as developers’ options. SCTP should be provided for common platforms, not only Linux, such as Windows, MacOSX, 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 multiple 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 generalpurposed protocols such as UDP and TCP. Due to its reliable, 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 Engineering, 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 Multistreaming, 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 Communications, 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 Multihomed 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 Review, 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