In the mean time we could have had nice things: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
SCTP would be a fantastic protocol for HTTP/HTTPS. Pipelining, multi homing, multi streaming, oh my.
Going back to David Reed, this is specifically why UDP exists: as the extension interface to build more non-TCP transport protocols.
On top of that, I believe the UDP checksum can be omitted as well at least on some OSes (and is arguably not necessary for fully encrypted/authenticated payloads) – leaving really just the two bytes for the "length field".
If we just allowed all L4 protocol numbers through and ditched NAT we could have nice things. Or we could kick it up two layers to use QUIC for what SCTP could have been.
Having a diversity of IP protocols isn't a nice thing. The designers of TCP/IP made a protocol specifically for doing the thing you wanted to see SCTP do: it was called UDP.
we're fighting for bits here!!! if you want to be 100% safe you need 576 packet size, UDP header is 1.4% of that
I am very aware of what you can do with UDP, I have done some very fun work trying to minimize bandwidth usage on crappy mobile connections by using and abusing it. But I think at the end of the day it is an engineering crutch.
If we insisted on properly supporting a diverse set of L4 protocols years ago we wouldn’t have wound up with NAT and slow adoption of IPv6. Address exhaustion would have been a real pressing issue. Instead you can’t even ping a server behind a NAT and firewalls run out of memory trying to manage stateful connections.
UDP is a pretty elegant design for what it is but it is barely good enough to allow us some room to make things work. Ultimately it did limit us more than it enabled us.
And I agree: it stifled what could have been a much nicer to work with set of protocols and who knows what could have been created had we not just said "well there is always UDP if you want to do your own thing".
The fact of ICMP not being itself a UDP protocol caused major problems for systems programmers, because it meant that OS kernels all "owned" ICMP, provided only a baroque sockopt programming interface to like 5% if it, and required userland programs to hold suser privileges to do any real ICMP work. Awful design. And ICMP is slow-pathed by routers, because it isn't UDP.
UDP literally doesn't do anything but multiplex raw IP. Unless you're actually worried about the 8 bytes the header takes up, there's no reason, none at all, to slide a new IP protocol anywhere but on top of UDP. Again: that's why UDP was designed in the first place. You can go look this up! David Reed still talks about it!
PMTUD breaks when ICMP is blocked.
The same argument can be made that everything but HTTP being blocked is not a problem because everything can be transported on top of HTTP.
Imagine at the beginning of a connection, sending a burst of packets, you could send (ignoring tcp timestamps because it makes the math hard, PAWS is a waste of bytes for most flows, and etc) [0,1460); [1400, 2800), ...
If you get an ack of the first packet, great. If not, you resend it as a 1400 byte payload and probe again in a future burst. Maybe even premptively resend the first packet as a 1400 byte segment after a short delay. Anyway, have enough failed large packets and probe smaller. Probe bigger again every so often if the connection stays open for a meaningful amount of time.
Good news, then: QUIC uses UDP.
> As for as QUIC support? Never gonna happen here.
So generic UDP is allowed, but QUIC is specifically detected and filtered? That would be bizarre.
And UDP hole punching is a crutch for the fact that we still use IPv4.
But even UDP is heavily restricted in most cases.
Too many things that people actually need to work run over it these days, including VPNs, videoconferencing etc.
WebRTC has been doing just that for peer to peer data connections (which need TCP-like semantics while traversing NATs via UDP hole punching).
UDP is a good solution but all it does is provide an 8 byte overhead and nothing that IP itself doesn’t provide for something like SCTP.
Source and destination port just seem like a reasonable baseline for alternate protocols, that's 4 more – leaving just the checksum. (If you're really desperate for space and have integrity provided by your protocol, you can even cram two more bytes in there!)
Sure, it would be conceptually nice to be able to skip UDP, but I think in terms of performance it absolutely does not matter.
But my point isn’t even about performance. It is about the fact that NAT and IPv4 address exhaustion and bad firewall practices have killed any innovation of level 4 protocols. Imagine if instead of TCP, SCTP had won the protocol wars in 1980-1990s. Or even better if we had realized that we were going to run out of IPv4 addresses much earlier when the cost of switching was smaller. It would have been so much better to have firewalls that don’t filter anything but protocols 6 and 17. We could have had the opportunity to experiment with different types of transports, baked encryption in at a lower level, etc.
Basically where we are is that we have 6 and 8 dot LEGO bricks to play with and are told that we can build anything with those but aren’t allowed to play with any other shapes.
Does it not? Not sure if it's really mandatory, but I believe one rationale for IPv6 getting rid of both its checksum and length fields was that both TCP and UDP duplicate both fields.
Given that QUIC doesn't have its own length field, I would imagine it relies on that of UDP, at least in situations where the lower layer does not provide reliable framing?
> Imagine if instead of TCP, SCTP had won the protocol wars in 1980-1990s. [...] We could have had the opportunity to experiment with different types of transports, baked encryption in at a lower level, etc.
Would we? Instead of TCP, SCTP would have become ossified in the stack all other things being equal (in particular the need for something like NAT due to IPv6 exhaustion), no?
As in, we wouldn't have to implement it on top of UDP
I’m not sure I agree though, because many firewalls already pass other protocols today, like GRE, IPSEC, etc.
SCTP is another high-performance protocol that provides many of the same network and performance features as QUIC, but it has been around for ~25 years. It was widely implemented. It was even in Linux 2.4 and available for Windows XP and MacOS. WebRTC in browsers can use SCTP, which makes sense (it predates QUIC) but is actually a bit of a problem if you want wide interoperability with WebRTC.
But despite SCTP being around and widely implemented, and doing many of the good things QUIC does, SCTP was never widely adopted, nor seriously considered for HTTP, mainly because of the problem of firewalls. (And to be fair, some operating system API limitations).
Basically, if TCP were invented today, it could not be deployed succesfully over much of the internet unless it was wrapped in UDP and encrypted.
UDP-with-encryption is now playing the role that the IP protocol is supposed to play, just because too many firewalls block nearly every IP packet that doesn't have type TCP or UDP. If UDP is used but without encryption for a popular protocol, eventually too many firewalls deep-packet-inspect that UDP protocol too, and do the same kinds of blocking, tampering or making protocols break.
This sad problem is called protocol ossification. As Google's AI puts it: "QUIC is the first IETF transport protocol to deliberately minimise its wire image to avoid ossification.". See also https://en.wikipedia.org/wiki/Protocol_ossification and https://http3-explained.haxx.se/en/why-quic/why-ossification
There are some downsides to QUIC's ossification resistance. I did some work for a mobile equipment manufacter who adaptively manage the queues for multiple TCP streams from different users and different applications from the same user, to help ensure a better, fairer and lower-latency experience. QUICs properties made it difficult to measure what's going on at the protocol level, forcing the queue management to use crude statistical estimators instead, which don't work well on bursty protocols.