SCTP is another protocol like TCP and UDP with aspects of both.

Your computer may not support SCTP yet and there’s always the chance this protocol will fail to gain enough support. I’m explaining it in this episode mainly so you’ll understand that the world is bigger than just TCP and UDP. All of these are just software protocols that establish standard ways for computers and devices to communicate. That means new protocols can be designed anytime.

SCTP started out from some telecom companies who were looking for a protocol that would meet the needs that the phone companies have built up over the years. They wanted a protocol that would run on IP. The two main existing options are TCP and UDP. Even though SCTP started out as a protocol designed for telephones, it can be used outside of that domain. The problem though is a general lack of support. SCTP has some really useful capabilities but until it gets wider support from both computer operating systems and the routers that direct network traffic, you might have trouble with it. You can always install software or write your own to handle SCTP traffic on your computer but it’s a whole different story when it comes to getting hardware devices to understand it.

SCTP stands for stream control transmission protocol and I’ll focus this episode on two of the main differences and benefits as compared with TCP and UDP.

The first main problem is called head-of-line blocking. Have you ever stood in line at a bank or anywhere when there’s one a single person available to serve people? I know I have and sometimes wonder if anybody in front of me is going to have a difficult problem. I hope they all have everything ready and can take their turn quickly. But sometimes, there’s a person in line with a whole packet of papers, unorganized, who could take an hour. The whole line comes to a complete stop while this person blocks everything. That’s head-of-line blocking. Relating this back to TCP, if a packet gets lost or damaged, then the other packets can continue to arrive but the processing will stop while that problem packet is retransmitted. If all the packets are related to each other, then there’s nothing you can do. You need that missing packet.

The problem in this case is that TCP guarantees ordered, reliable delivery of information. So why not use UDP? Well, UDP has no guarantee. It’s quicker to setup since there’s no connection involved and it allows unrelated packets to be sent independently. But if UDP loses a packet, then it just gets ignored.

SCTP solves this by guaranteeing delivery like TCP but at the same time allowing separate processing of unrelated messages. It’s like what happens when the bank opens up additional teller windows. Now, when there’s an especially slow case, it’s not as troublesome because there are other windows to keep the overall processing going. A single slow person can no longer block the entire line.

What do I mean by a related message? Let’s say that you want to send a lot of different files. Each file is unrelated to the others. Just because a packet from one file gets lost should not delay the communication of the other files.

The second main problem that SCTP solves is called multihoming. Let’s say you own a company and need to communicate with another company as quick as possible about a complicated issue. Maybe you’re trying to negotiate a new partnership with the other company. Now, one way to do this would be for both companies to establish a single point of contact through representatives. There’s one representative from your company and another one from the other company. And both representatives end up on the phone almost constantly. It gets to the point where you have something new to relate with the other company but your representative already has so many things to discuss that the topic won’t be mentioned until next week. What started out as a good way to organize communication turns into a bottleneck.

What we need are more representatives. And the same thing applies with computers and devices. You might have a computer with both a wired ethernet connection and a wireless connection. What if you could use both connections at the same time? That would be like adding extra representatives to your negotiating team.

You can do this with SCTP and get not only better speed but more reliable connections too. If you have multiple connections that you can use and one of them stops working, then SCTP can continue using the remaining connections. TCP would have to establish a whole new connection after waiting for the old connection to timeout.


What's on your mind?

On a scale of 0 to 10, how likely are you to refer us to a friend?