Vint Cerf's webby

A while ago I extolled TCP as a "gold standard" and now, it appears, it's finally getting the credit it deserves. Even Tim Berners-Lee has gotten into the act, making many of the same points, albeit with a bit more polish, in introducing internet pioneer, Webby recipient and Google fellow Vint Cerf. Cerf's response, a Webby-standard five-word acceptance speech, would be a cliche coming from most of us. Considering the source, it's startlingly audacious: "You ain't seen nothing yet."

So, whatever could make an engineering masterpiece like TCP and decades of other career highlights look like "nothing", you can be assured Cerf is hard at work on it.

TCP: A gold standard

If you're looking for a paradigm for network standards, you could do worse than TCP. It's been in continuous use for decades now with very little revision. It's been implemented on a staggeringly wide variety of platforms. It works on hardware spanning orders of magnitude in performance. I don't mean this just historically, though hardware has certainly become faster over time. You could be using a dial-up connection to talk to someone with a T1 connection by way of gigabit or faster networks in the middle and TCP will happily manage the whole connection end to end.

TCP underlies most (though not all) of the other famous Ps: HTTP, SMTP, NNTP, FTP, POP, IMAP, etc., etc. If you're reading this, your browser almost certainly used HTTP over TCP to fetch the contents. TCP works on anything from a single computer (using loopback) to the whole internet. And it does it so quietly you can easily forget it's even there.

TCP is successful because of two well-chosen abstractions:

It uses the abstraction of a best-effort datagram protocol. That is, it assumes that there is a way of sending a packet of data, up to a given size, to a given address on the network. It doesn't assume that such a datagram will always get there, or that any two datagrams will arrive in the order sent, or will arrive intact, or will only arrive once. It works best when these things happen, but it still works even if they don't, as long as they don't happen too much.

TCP provides a useful abstraction. Once you establish a TCP connection to another host, one of three things will happen:

1. The data you send will arrive, in the order you sent it, intact and reasonably timely (and likewise for data the other end sends back).
2. Failing that, the connection will be closed and you will get an error.
3. Failing that, you will have bigger problems to deal with than a broken TCP connection.

TCP isn't perfect. If you care more about latency than every single byte arriving intact, for example if you're sending live audio or video, you [possibly] don't want to use TCP. If you're particularly concerned about security, you'll need to take some extra steps to avoid certain well-known attacks. Bearing this in mind, TCP does hit a sweet spot that's more than good enough for a number or applications, and it does so by making only minimal and reasonable assumptions about the system it's running on.

Not bad at all for something invented when the Net as we now know it was still firmly in the realm of speculation.