 TCP seemed to be an all-out winner when it came to its comparison against UDP in an all-IP scenario. In an all-IP scenario, the end hosts and the internet working devices were all gelled into the same environment. So the requirement was only to ensure congestion control, reliability, flow control and in-order delivery within that network. However, the situation changed and it had to change when this all-IP network was to be integrated and dovetailed with other external networks. In this module, we shall explore a protocol called stream control transmission protocol which is an extension and a value-added reliable protocol at the transport layer that adopts and inherits so many of its features from TCP but does avoid very successfully the limitations of TCP. We'd explore SCTP by looking at some of its features. Let's look at TCP limitations first. The TCP limitations become obvious when we realize that it is an in-order byte stream. It means whatever is sent by the sender to the receiver in a pipeline manner would be delivered segment by segment. Since TCP implements go back in, in the wake of a certain segment loss or delayed segments, TCP starts its own congestion awareness mechanism and thoughts the transmission of subsequent segments. This may appear very useful in managing congestion in the network, but on the contrary, from the end host's point of view, this is indeed head of the line blocking. So this is a very serious issue with regards to transmission, especially in networks which involve real-time information. The second limitation of TCP was that since it is a byte stream, so it did not have specific message boundaries. But we know that in other kinds of networks where out-of-band signaling is performed, each signal can be attributed to a certain message and that message is to be given priority treatment over the others. How would have TCP handled it? We all know that TCP would have really affected its performance adversely. And of course, TCP did not have provision for multi-homing. It means TCP only establishes a virtual hand-through-hand shaking, a virtual contact between two endpoints. It doesn't allow this endpoint scaling up or extension. SCTP is essentially a transport layer protocol. It is created and designed to take care of signaling, which is a very important aspect, especially in mobile communications and fixed-line networks where the signaling is carried out using signaling protocols such as SS7. SCTP has actually been adopted and standardized by the third-generation partnership project. The strengths of SCTP are aimed at becoming in harmony and being useful for providing mobility and also help to aggregate data. This data aggregation is not of a concern in TCP when only two endpoints are communicating with each other. But if you really want to have multiple endpoints on the two end hosts to communicate with each other using different wired and wireless interfaces, it cannot be done by TCP. So SCTP was introduced to incorporate these features. SCTP comes with the message-based protocol format. It means it is meant to encapsulate a message every time an SCTP segment is transferred from the transport layer of the sender to that of a receiver. It has support for multi-homing. It means it allows two SCTP endpoints to associate across multiple IP addresses. Whereas, if you recall, the TCP socket would only work on the source IP and destination IP. Of course, the concept of port numbers is already there, but I am only referring to the IP addresses here. SCTP also provides multi-streaming capability. That is, the in-order delivery of segments from the sender to the receiver could cause head-of-the-line blocking. But if you have multiple parallel streams which could be established between two endpoints, then the head-of-the-line blocking phenomenon can be addressed significantly. SCTP provides congestion control, but instead of incorporating the go-back-end mechanism that uses TCP slow-start and TCP congestion awareness mechanisms such as adaptive, additive increase, multiplicative decrease, here, the selective acknowledgement mechanism is adopted by SCTP. This selective acknowledgement is an option in TCP, but it is mandatory here in SCTP. Although we know that TCP nowadays comes up with something called the transport layer security, but when initially TCP was conceived, it was only meant for reliability, so it incorporated a three-way handshake. SCTP actually came up with an advanced form of handshaking called the four-way handshake. The four-way handshake identifies the end hosts and only authorizes the legitimate end hosts to send the SIN packets to establish connections. So this somehow is successful in preventing the denial-of-service attack. Let's look at an end-to-end scenario between two applications which run multiple streams over more than one IP network. So you see here using more than one IP network means that these IP networks are providing some kind of multi-homing mechanism. It means in the wake of one going down, the other one is still operational. With that, if you also incorporate multi-streaming, it means that instead of having only one endpoint at every entity, that is the sender and the receiver, instead here we have multiple streams. Allowing multiple streams helps the application to choose either of the outgoing streams to avoid head-to-line blocking. So SCTP incorporates multi-homing and multi-streaming to get rid of the constraints and limitations which TCP had.