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.
I honestly think a lot of stuff like SNMP's UDP semantics are based on faulty path dependence from people believing they had basically two options, either TCP's rigid sequential delivery and HOLB, or yolo-mode UDP.
On the contrary, I think it was clearly a very intentional and deliberate decision to not add complexity (it is, after all, "Simple" Network Management Protocol) to the transport layer of SNMP. At the very least, the people involved certainly had alternative transports in consideration rather than a mistaken view of TCP vs UDP alone. Additional transport requirements were just not relevant to the use cases of SNMP. Select excerpts from RFC 1157:
> Consistent with the goal of minimizing complexity of the management agent, the exchange of SNMP messages requires only an unreliable datagram service, and every message is entirely and independently represented by a single transport datagram. While this document specifies the exchange of messages via the UDP protocol [11], the mechanisms of the SNMP are generally suitable for use with a wide variety of transport services.
From this, the authors intentionally kept things within a single datagram across any unreliable datagram service - UDP was just an obvious choice to define for the needs.
> In the text that follows, the term transport address is used. In the case of the UDP, a transport address consists of an IP address along with a UDP port. Other transport services may be used to support the SNMP. In these cases, the definition of a transport address should be made accordingly.
They continued to account for and allow for how other generic transport protocols could be used (at the time, not as many), rather than assume they only had the options of TCP or UDP.
> In cases where an unreliable datagram service is being used, the RequestID also provides a simple means of identifying messages duplicated by the network.
This shows other portions of SNMP did account for which specific features may need to be built on top of a minimal transport protocol and only added those to the specific PDUs which needed it. E.g. for this request based PDUs used by Get/GetNext/GetBulk etc they intentionally added an ID to handle message duplication, just not to every PDU, like traps, because it was unnecessary.
> A limited number of unsolicited messages (traps) guide the timing and focus of the polling. Limiting the number of unsolicited messages is consistent with the goal of simplicity and minimizing the amount of traffic generated by the network management function.
This shows the design of traps was heavily focused around simplicity and minimization of traffic, not based on what TCP or UDP could specifically offer. In fact, you won't find a mention of "checksum" or "hash" anywhere either in the RFC - UDP just had it as extra cruft on top of that generic "unreliable datagram service" they were designing against!
.
SNMPv3 did eventually add TCP as an option for traps a couple decades later, and hardly anyone ever opted to use it since as there really isn't much benefit from other transports for the use case. More have used the TLS option, but even more have just relied on the minimal, purpose defined encryption and HMACs added instead.
Thanks for this discussion by the way, there is nothing more I love working with or talking about than network protocol design and history :).
