mlhpdxUDP isn't unreliable, it's a convertible (2024)
https://www.proxylity.com/articles/udp-is-a-convertible.html
This is something that the classic TCP/IP books (both Comer and Stevens) got wrong, inexplicably, because David Reed was very clear about it. UDP isn't a transport protocol at all. It's an extension interface for building new transport protocols. It is the thing you would use (and weirdly didn't) to ship SCTP, and did use to build QUIC. It does not make sense to compare UDP to TCP; it's like saying TCP is worse at URL handling than HTTP.
Talking about what UDP provides is a little bit like talking about what IP provides. It's almost a category error. Is "UDP" "reliable"? It's as reliable as whatever transport you build on it is!
I disagree. Raw UDP is about as useful as raw TCP if your application matches the protocol's features and weaknesses. Plenty of protocols work by spamming packets around the network where it doesn't matter if half of them go missing or arrive out of order.
TCP is also barely enough to be a real "protocol". It does a bunch of useful stuff but in the end raw text is pretty useless as a protocol. That's why everything from IRC to HTTP has its own protocol on top.
SCTP is a bit of a weird outlier to be placed at the level of TCP and UDP, but there's no need to go all QUIC and reinvent TCP if you want to use UDP. DNS, NTP, and plenty of other protocols don't need to rebuild reliability and streams to be useful.
I mean, OK, but the inventor of UDP disagrees. I agree you don't have to build a real transport at all if you don't want to. But the moment you do so much as a sequence number that lets you detect that you've missed some packets, you've build a transport, and you're not just using UDP.
The inventor of UDP could have intended one thing 45 years ago, but that does not actually mean that's the only way it happened to be. UDP is great for building a transport protocol on top of. Most uses of UDP do treat it as such. That is not evidence UDP must not be able to qualify or be used as a transport protocol itself.
I mean, sure, but then by that logic so is IP. UDP is just IP with an extra checksum and a 32-bit multiplexing field instead of an 8-bit one.
All transport protocols are "just" adding things on top of a network protocol so you can multiplex to applications instead of hosts. That's what makes them transport protocols instead of alternate network protocols. TCP is "just" adding a few more things. I kinda wish UDP didn't have the checksum field, it would have been a bit nicer to build other transports with if one could decide to validate their headers with one's desired checksum approach (or not bother, if so desired) rather than have 2 separate checksums for the transport layer role. You could at least blank it for wasted space riding on v4, then v6 mandated it for some reason.
UDP also isn't the only transport protocol used extensible either, it's just far more common because it has fewer assumptions. E.g. TCP has MPTCP and a bolt-on transport extension.
OK. But if you put a 32-bit header with a sequence number and an "ACK requested" flag on top of UDP, and arrange to send NACKs when you see skips in the sequence numbers, you're not using UDP; you're using a transport you built on top of UDP.
This isn't just a semantic argument. People getting this conceptually wrong has broken the deployment story for things like SCTP, which for no good reason rides on top of IP directly and thus gets blocked by middleboxes.
The disagreement is in that being the ONLY way UDP can be used is in building a more complex transport layer, not that building a more complex transport layer on top of UDP means it's still just UDP alone. Any transport protocol can be built upon as such, even including transport protocols already built atop UDP. That UDP can be layered on top of does not redefine UDP's ability to be a complete transport layer protocol in itself. UDP cannot be used as a network layer protocol, so it is not one, but UDP provides multiplexing (source+dest based), datagram sizing independent of the network layer, and even header checksumming on top of a network layer protocol - making it a (relatively) minimal transport protocol. The ability to be a transport layer protocol is not defined by the lack of ability to be built on top of to make a more complex transport layer on top of the given protocol.
A classic practical example of "plain Jane UDP transport" might be an traditional SNMP trap (not one of the newer fancy flavors). No ACK, no bidirectional session setup, no message ID/sequence number, no retransmission, no congestion control - just a one shot blast of info to the given destination - split into datagrams and multiplexed to the receiving service via the transport layer over an arbitrary network layer.
A lot of things broke SCTP... but I'd rather not get into a side debate about what those reasons are. Just that it's not because UDP alone is unusable as a transport layer protocol.