Stream Control Transmission Protocol (SCTP) is a transport-layer protocol, serving in a similar role to the popular protocols TCP and UDP. It is standardized by IETF in RFC 4960.
SCTP provides some of the same service features of both: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP; it differs from these in providing multi-homing and redundant paths to increase resilience and reliability.
HTTP should have made SCTP a lot more popular. SCTP is a natural fit for reliably transporting static files, which is what HTTP was originally designed for. So many of the HTTP2/SPDY/etc. features are there to make up for the fact that TCP doesn't have a length "field" since it's stream-oriented.
Obviously, there are exceptions and you can have both streams and known-length content served over HTTP, but I still think streams over SCTP would have been a better choice than datagrams over TCP.
Edit: Also firewalls that filter out anything but TCP (or TCP + UDP, or TCP + UDP + ICMP) can die a fiery death. The fact that basically any new protocol has to tunnel over UDP instead of properly over IP is heresy and bullshit.
Considering the MTU issues: Does anyone know why this was not solved in IP (and IPv6) by the following method:
1) There is a field MTU in the IP header.
2) The sending host sets MTU := <MTU of the outgoing link>.
3) Any router on the path sets MTU := min(MTU, <MTU of outgoing link>).
4) The receiving host instantly knows the MTU of the path (the MTU field).
This seems like a much simpler, more reliable and more efficient system than PMTU discovery: no problems with firewalls blocking ICMP, no additional delay due to too large packets.
All at the cost of a single minimization operation at the router. The IP header checksum would need to be recalculated, but, due to the simplicity of the IP checksum, fixing it up changing one word is trivial (AFAIK).
I can imagine a potential issue with adding that to IPv6 when it was designed, that IPv6 should be tunnelable over IPv4 which doesn't have this, but still surely there are ways to deal with that.
IP is based on packet switching and has no concept of a circuit/connection. Each subsequent packet sent between same endpoint can take different path with different PMTU.
Also, dedicating even two bytes in each and every IP packet just for MTU would be quite an overhead, especially since IP already has a mechanism (fragmentation) to deal with this.
You don't need this in every packet, you only need it in one packet (or once every few minutes). Instead of putting a field in every packet that only <1% of them need, we could create an out of band message to notify when the MTU has been exceeded. And the endpoint that needs to know that is the sender, so that's who you would send it to. Which is what they did.
That works perfectly well, the problem is that many misconfigured firewalls drop the ICMP messages. No one predicted that level of incompetence when the protocols were being designed.
In reality the MTU is 1500 because the odds of all devices on a given path supporting anything larger is almost zero. The only way IPv6 could have helped was mandating a larger fixed known MTU... say 4096 or 8192.
I've been dying to write a protocol to replace both TCP and UDP (me being naive, I think I could write a decent one). I feel like there's fundamentally really no good reason to have multiple protocols, because fundamentally, neither is UDP 100% unreliable, nor is TCP 100% reliable. I think what we should really have is just one protocol with adjustable tolerance parameters. But I haven't had the time to put much thought into stuff like congestion control, so I don't know what it involves yet. I'm glad someone is doing something similar though.
If you allow tcp to drop/re-order packets, the entire abstraction of a stream protocol is gone. The application now has to understand packet boundaries, which packets are missing, etc.
So to me it sounds like you just want to write a UDP protocol with some extra reliability. Most applications built on top of UDP do this already, but maybe there would be some value in a general library for UDP protocols.
SCTP allows configurable delivery parameters - you can choose whether data should be reliable, how many retransmissions, whether it needs to be in order, etc.
As another commenter mentions SCTP can be encapsulated if needed. SCTP is actually in pretty wide use in online gaming, and has been since at least 2007...
Eh, I'm not too optimistic about this. Too many millions of routers and middleboxes only support TCP and UDP for this to ever be workable on the public internet. Since layer 4 is traditionally done in the kernel were talking about updating the firmware of countless devices. A better solution is to piggyback on UDP support and add your own protocol in user space.
building a protocol on top of UDP has historically been a good compromise. The base protocol is simple enough that it doesn't add much overhead to just build whatever you want on top of it. The ubiquitous support for UDP leaves little reason to roll your own.
The only bad downside to both UDP and TCP is that support for unsolicited connections is usually completely broken for end users since the 90s because of the vast adoption of NAT.
Well technically the only thing those routers and middleboxes need to support is IP, why some of them decide they need to meddle with the payload is something I don't understand.
Isn't DCCP just an congestion control add-on that is generic, and you can for example use it over UDP? In that case it wouldn't matter, as long as routers support UDP, which they do.
> A better solution is to piggyback on UDP support and add your own protocol in user space.
I haven't looked at the code, but I imagine this would be relatively trivial to change if it is written at all sanely, right? Hardly sounds like a big thing to focus on.
I fully understand that networking protocols are truly in the center of the main vein of subjects interesting to the community of Hacker News. But can we at least admit to ourselves that being endlessly enamored with novelty and lack of precedence, telegraphs our deepest motivations to people who might have ulterior motives, allowing them to easily gain our attention and compliance by simply pointing out to us that the world is filled with irony, and novelty, and unprecedented phenomena?
If you remove "DCCP", "socket", and "type" from this headline, you are left with the universal format of a clickbait headline. If DCCP is truly a networking protocol worthy of the attention of the readers of Hacker News, just imagine how much more convincing of an argument there is to be made, based on its true underlying merits. I am perfectly willing to admit that this protocol may in fact be the best networking protocol by every objective measure available. But the fact that someone who knows more than I do about it, believes that their best opening bid in the negotiation that is convincing me of its merits, is a logical fallacy, inevitably leads me to question their entire premise.
If we can all agree that we don't like clickbait headlines in the general sense, then lets be even more vigilant against clickbait headlines that we are the least able to resist.
Edit: added a couple of missing words that were lost on the way from my brain to my fingers.
I think you're reading a little too much into it. The title, like the conclusion, was supposed to a joke about how DCCP is obscure and therefore hipster-esque. The intention of the article wasn't so much as to make the case for the merits of DCCP but to describe some of the aspects of networking technology that would be unfamiliar to most people, including the much of the Hacker News community. I really don't see how describing something as obscure is logically fallacious.
While I will admit that I did choose the title to be alluring, I do not think it is provocative, sensationalising or misleading in any way to be called clickbait.
> just imagine how much more convincing of an argument there is to be made, based on its true underlying merits
Leaving aside the merits of your claim concerning the title containing a logical fallacy, HN's 80-character limit on the length of a submission's title can, at times, make this approach a bit difficult in practice.
[+] [-] yoaviram|9 years ago|reply
Stream Control Transmission Protocol (SCTP) is a transport-layer protocol, serving in a similar role to the popular protocols TCP and UDP. It is standardized by IETF in RFC 4960.
SCTP provides some of the same service features of both: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP; it differs from these in providing multi-homing and redundant paths to increase resilience and reliability.
https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...
Edit: fix typo
[+] [-] IgorPartola|9 years ago|reply
Obviously, there are exceptions and you can have both streams and known-length content served over HTTP, but I still think streams over SCTP would have been a better choice than datagrams over TCP.
Edit: Also firewalls that filter out anything but TCP (or TCP + UDP, or TCP + UDP + ICMP) can die a fiery death. The fact that basically any new protocol has to tunnel over UDP instead of properly over IP is heresy and bullshit.
[+] [-] voidz|9 years ago|reply
[+] [-] kosinus|9 years ago|reply
[+] [-] ycmbntrthrwaway|9 years ago|reply
[+] [-] epx|9 years ago|reply
[+] [-] nickpsecurity|9 years ago|reply
http://udt.sourceforge.net/
[+] [-] ambrop7|9 years ago|reply
1) There is a field MTU in the IP header.
2) The sending host sets MTU := <MTU of the outgoing link>.
3) Any router on the path sets MTU := min(MTU, <MTU of outgoing link>).
4) The receiving host instantly knows the MTU of the path (the MTU field).
This seems like a much simpler, more reliable and more efficient system than PMTU discovery: no problems with firewalls blocking ICMP, no additional delay due to too large packets.
All at the cost of a single minimization operation at the router. The IP header checksum would need to be recalculated, but, due to the simplicity of the IP checksum, fixing it up changing one word is trivial (AFAIK).
I can imagine a potential issue with adding that to IPv6 when it was designed, that IPv6 should be tunnelable over IPv4 which doesn't have this, but still surely there are ways to deal with that.
[+] [-] magnat|9 years ago|reply
Also, dedicating even two bytes in each and every IP packet just for MTU would be quite an overhead, especially since IP already has a mechanism (fragmentation) to deal with this.
[+] [-] zrm|9 years ago|reply
You don't need this in every packet, you only need it in one packet (or once every few minutes). Instead of putting a field in every packet that only <1% of them need, we could create an out of band message to notify when the MTU has been exceeded. And the endpoint that needs to know that is the sender, so that's who you would send it to. Which is what they did.
That works perfectly well, the problem is that many misconfigured firewalls drop the ICMP messages. No one predicted that level of incompetence when the protocols were being designed.
[+] [-] xenadu02|9 years ago|reply
[+] [-] vbernat|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] robert_foss|9 years ago|reply
[1] https://en.wikipedia.org/wiki/Multipath_TCP
[2] http://blog.multipath-tcp.org/blog/html/index.html
[+] [-] gonzo|9 years ago|reply
https://wiki.freebsd.org/SummerOfCode2016/TCP-IP-RegressionT...
[+] [-] scott_karana|9 years ago|reply
[+] [-] erpellan|9 years ago|reply
[+] [-] kylert|9 years ago|reply
[+] [-] busterarm|9 years ago|reply
[+] [-] wfunction|9 years ago|reply
[+] [-] hueving|9 years ago|reply
So to me it sounds like you just want to write a UDP protocol with some extra reliability. Most applications built on top of UDP do this already, but maybe there would be some value in a general library for UDP protocols.
[+] [-] IshKebab|9 years ago|reply
It's used for WebRTC data channels:
https://www.html5rocks.com/en/tutorials/webrtc/datachannels/
Also worth checking out enet:
http://enet.bespin.org/Features.html
[+] [-] riffraff|9 years ago|reply
By not being designed to handle streams, UDP can sidestep a ton of issues.
So, the adjustable parameters in your protocol should be a lot, methinks.
[+] [-] partycoder|9 years ago|reply
[+] [-] nomadlogic|9 years ago|reply
[+] [-] kevin_thibedeau|9 years ago|reply
https://tools.ietf.org/html/rfc6951
[+] [-] ailideex|9 years ago|reply
[+] [-] chrisallick|9 years ago|reply
[+] [-] drake01|9 years ago|reply
[+] [-] lucb1e|9 years ago|reply
[+] [-] nrjdhsbsid|9 years ago|reply
building a protocol on top of UDP has historically been a good compromise. The base protocol is simple enough that it doesn't add much overhead to just build whatever you want on top of it. The ubiquitous support for UDP leaves little reason to roll your own.
The only bad downside to both UDP and TCP is that support for unsolicited connections is usually completely broken for end users since the 90s because of the vast adoption of NAT.
[+] [-] pantalaimon|9 years ago|reply
[+] [-] takeda|9 years ago|reply
[+] [-] wfunction|9 years ago|reply
I haven't looked at the code, but I imagine this would be relatively trivial to change if it is written at all sanely, right? Hardly sounds like a big thing to focus on.
[+] [-] tmuir|9 years ago|reply
If you remove "DCCP", "socket", and "type" from this headline, you are left with the universal format of a clickbait headline. If DCCP is truly a networking protocol worthy of the attention of the readers of Hacker News, just imagine how much more convincing of an argument there is to be made, based on its true underlying merits. I am perfectly willing to admit that this protocol may in fact be the best networking protocol by every objective measure available. But the fact that someone who knows more than I do about it, believes that their best opening bid in the negotiation that is convincing me of its merits, is a logical fallacy, inevitably leads me to question their entire premise.
If we can all agree that we don't like clickbait headlines in the general sense, then lets be even more vigilant against clickbait headlines that we are the least able to resist.
Edit: added a couple of missing words that were lost on the way from my brain to my fingers.
[+] [-] unmole|9 years ago|reply
While I will admit that I did choose the title to be alluring, I do not think it is provocative, sensationalising or misleading in any way to be called clickbait.
[+] [-] webmaven|9 years ago|reply
Leaving aside the merits of your claim concerning the title containing a logical fallacy, HN's 80-character limit on the length of a submission's title can, at times, make this approach a bit difficult in practice.