Rant: It should have been TCP / UDP / IP not TCP / IP

[jbenet]

Once upon a time, the Engineers of the Internet decided, rightly so, to refactor the new and shiny TCP -- which was much better than the old and sluggish NCP -- into TCP/IP, a cleaner, layered design. The idea was that IP would provide the Host-to-Host connectivity in a best-effort basis, and TCP would provide reliability to streams of data. All well and good.

In that refactoring, UDP got "un-designed" as an afterthought. It was the place to put all the protocols that would not require the advanced reliability and congestion control of TCP.

Actually, UDP was “un-designed” by me and others. By this I mean that UDP was the final expression of a process that today we would call “factoring” an overcomplex design. ... UDP was actually “designed” in 30 minutes on a blackboard when we decided pull the original TCP protocol apart into TCP and IP, and created UDP on top of IP as an alternative for multiplexing and demultiplexing IP datagrams inside a host among the various host processes or tasks. But it was a placeholder that enabled all the non-virtual-circuit protocols since then to be invented, including encapsulation, RTP, DNS, …, without having to negotiate for permission either to define a new protocol or to extend TCP by adding “features”. ~ David Reed, "designer of UDP" and author of the End-to-End Principle.

TCP and UDP are the new thin-waist of the internet. Thankfully, enough applications depended on UDP that NATs were forced to implement support for both TCP and UDP. Unfortunately, all new transport protocols have to be built on top of one of these.

What is UDP good for anyway? It provides packet multiplexing for distinct flows of information in each host (+ a weak checksum, that arguably should be refactored into a different layer). It's like an extended IP address: 10.20.30.40:5678 is just a 6 octet address. If only they had realized IP needed to connect programs, instead of hosts! Make IP addresses 6 octets, reduce TCP complexity, and have no UDP. But sadly, the notion of an endpoint was broken in two pieces, the IP address of the computer, and the Port of the server, inside a program, inside the computer. (You would think that with the IPv6 address size this would have been rethought...).

It gets worse. If only they had decided to do the next best thing: make UDP the standard way to multiplex information flows between hosts, and make TCP use UDP! Note that all UDP functionality is a subset of TCP. It would have been a (mostly) trivial decision then! Simpler TCP. Simpler OS network stacks. Simpler NATs. Simpler Thin Waist. Simpler Routers. Simpler network programs.

Simpler WebRTC. Yes, we will still live with this annoying indecision for a long time to come.

[davidad]

Interesting thought. My knee-jerk reaction would be that forcing all TCP streams to pass through a UDP layer seems like unnecessary inefficiency, but given the tight kernel-space integration between TCP and IP anyway, I guess this wouldn't have really costed anything after all! (Which I guess is what you're hinting at in the title.)

But, I have a feeling that one of the main use cases of TCP, flow/congestion control, would still have to be special-cased (since plain UDP doesn't have ACKs), so I'm not so sure that everything would become as simplified as you suggest.

I'm certainly with you on endpoint addresses being strictly superior to host addresses, though :smile:

[jbenet]

given the tight kernel-space integration between TCP and IP anyway, I guess this wouldn't have really costed anything after all! (Which I guess is what you're hinting at in the title.)

Yeah, it would've been only a few more instructions per packet. (checking one more proto field against a table... or a register in high performance routers :] ).

But, I have a feeling that one of the main use cases of TCP, flow/congestion control, would still have to be special-cased (since plain UDP doesn't have ACKs), so I'm not so sure that everything would become as simplified as you suggest.

Congestion control + Acks would still happen in TCP (/UDP/IP). Not special cased, just the regular TCP stack. Today, ACKs have a full TCP header, including ports + checksum = UDP. This actually opens the door for ACKs smaller than data TCP packets. (for when data-ack piggybacking is not done-- which is often because data acks can cause deadlock :( )

I'm certainly with you on endpoint addresses being strictly superior to host addresses, though :smile:

Yeah, endpoints for sure. It's annoying to think udp is still required by middlebox assumptions, now that we have IPv6.

Btw, one issue with hash addressing is that routers no longer have hints in the addresses themselves. I'm not convinced routing systems at the scale + performance level of the entire internet can do without that (primarily backbone). Though maybe an intra/inter-backbone-ISP layer 2.5 protocol can handle that, if the identity address and location address tuples are pushed to backbone gateways (most longhaul traffic happens in jumbo frames anyway). [this is only relevant for networks seeking to run at scale and not as IP overlays. which is in-scope of this thread, and should be out of scope of our worries for a long time :) ].

[dominictarr]

Totally agree. Another thing for the time-travelling todo list.

[hufans]

why not udp/ip