💾 Archived View for stanner.bayern › en › sctp › sctp1.gmi captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
If you never heard of SCTP folks, then it's about time. So grab a beer and put on your seat belts!
We have SCTP at our hands already – the kernel contains a full fledged implemantation, ready to use. Unfortunately, barely anyone uses the protocol, and many don't even know that it exists.
In context to working on a project of a friend and mine we took a closer look onto this compratively young protocol. The Stream Control Transmission Protocol was designed over 20 years after TCP und UDP and is probably the most interesting layer 4 protocol.
As you will see over the course of this blog series, SCTP is technologically far superior to those other two, who have the internet grasped in their iron fists.
As a first taste, let us inform you about a few of SCTP's features compared to UDP and TCP (yes, I know there is Quic. We'll talk about that one later):
SCTP is message based. The user does not need to serialize his data with HTTP, JSON or TLV, he can just pass a message to the SCTP socket.
SCTP allows subconnections (streams) in one SCTP connection. This makes data serialization even more unnecessary. You can create a data stream, a metadata stream, a control data stream... up to 2^16 streams are possible
If ordered packet receiving is not necessary or suitable for your application, you can switch it off.
This is the most insane of all killer features the protocol offers. The extension RFC 3758 introduces a new partial reliability to SCTP. Using this mechanism, you can switch off the reliability for *individual streams* within your connection.
This enables you, for example, to use one SCTP socket for a voice over IP application, where one partial reliable stream transports the user speech whereas another, reliable stream transports the control flow.
To make this even better, SCTP supports partial reliability in a way they call “timed reliability”. And yes, it is as cool as it sounds: You can configure a time span within which the SCTP stack will try to retransmit lost packages. If the time elapses, the receiver will no longer expect the packages to arrive.
This might be extremely useful for many applications. Consider our VoIP example: The human ear can detect latency when it reaches roughly 100ms. An internet roundtrip time is usually far shorter than this. Lost VoIP packages therefore could be retransmitted in time for the receiver to push them to the headphones.
The same reason not everyone is using the Opus audio codec, although it is by far superior to all other audio codecs and can easily replace them all (except the ultra low bandwith and lossless codecs of course):
History, lobbyism, lack of knowledge, but, most importantly:
A common dogma when discussing layer 4 protocols is that you can not use anything but UDP and TCP, because there are so called middle boxes which will regedly block your traffic whenever you try to do something cool. Interestingly, you rarely hear what those middle boxes are, precisely.
One of the biggest problems apparently is the network address translation (NAT), which uses a quadruppel of target addr, source addr, target port and source port. A crappy NAT box in the IPv4 world will not be able to pass SCTP traffic if it can not identify the port numbers within the SCTP packet header. Hence, it has to explicitely understand the protocol. The situation might be a bit better with IPv6, as it does not require (nor allow) any ridiculous NAT technology – and as far as we know, even the most incompetent industry folks have not been able to damage IPv6 in this regard, yet.
What leads us to yet another problem. There are two kinds of firewalls: Insane, ridiculous company firewalls which nowadays often block everythin what is not HTTP or HTTPS. And more decent firewalls, which for example protect your home network from being scanned from remote.
The primer completely rape and destroy the open architecture of the internet. There is nothing to be done here, nothing to be saved – not once the windows click admins closed every port, only to witness that everyone now tunnels everything over encrypted TLS connections... dugh. The later introduce problems to SCTP users: As with TCP, it's almost impossible to establish a SCTP connection between two users behind such firewalls. The stateful firewall will only allow outgoing traffic, but won't accept it incoming. If this is true for both parties, you'll almost certainly need a relay server to forward your traffic to your peer. And, to be fair in this article: That's a problem only UDP can solve by using whole punching.
That's something we are trying to find out as well. For a starter, here is an interesting anecdote: Recently, I wrote to the support of a well known and quite respected home router manufacturer and asked whether they support SCTP or not. The answer was: No, we don't, but we forward your question as a feature request to our developers.
But: It's actually possibly to establish an SCTP connection over such a router to a remote server – *if* you use IPv6, which does neitheir require nor allow NAT. The wonders of technology.
Unfortunately, our tests in at least one mobile LTE network showed that the provider seems to actively filter SCTP packets, for both v4 and v6. I have no idea what the background of their decision is, but I can see no reason at all to filter the protocol. Quite the contrary, the provider's hard- and software has to actively evaluate the next-header field (resp. protocol field in v4), what means the purposefully implemented the filter-functionality. The check costs small, but existing delay and power and therefore money, what indicates that they might have a goal with their filter.
This distructive behavior, which contradicts against everything a network provider should be – someone who transmits IP datagrams.
Their insanity causes us additional work in making protocols except TCP and UDP usable, but as we will see, the goal can be achieved.