1 Motivation and Design Philosophy

TCP and UDP have served well for many years; is there really any need for anything else? What motivates the design of Tau---what problems is it supposed to solve, and how does it solve them?

1.1 Upper-level Architecture of the Internet

The Internet effectively has no architecture above TCP and UDP port numbers: there is no general way to structure functions that operate above TCP and UDP. Some special mechanisms have been developed for specific applications or classes of applications, for example the Real Time Protocol.

Some consequences of this lack of structure:

It makes code re-use difficult. Because functionality is built into the application it is typically customized for that application. This can be a good thing, but it means useful functions have to be re-implemented for the particular application. A (somewhat dubious) example is security and multimedia. The Transport Level Security protocol provides a generic service but requires TCP, and therefore is incompatible with RTP.
There is no standard way of encoding configuration information. This is crucial for interoperability. In some cases the configuration information is encoded in the address (port number), e.g. some applications use one well-known port with security and another without it. In other cases it is encoded in a version number in the protocol headers (e.g. the attempt by PCT to "steal" half of the SSL version number space). In still other cases it is explicitly negotiated by protocols (e.g. any of the many "generic extension" mechanisms now under development).
The Transport-Application boundary, which is inviolate (at least in TCP implementations), impedes certain performance optimizations. For example, using TLS over TCP requires at least three round trips before the application can transmit its first byte of data. By "piggybacking" round trips and allowing the associations to be established in parallel, the delay can be reduced by a third. Moreover, when carrying data that is protected by a cryptographic integrity check, TCP still computes its (much weaker) checksum over all transmitted data.

1.2 Non-Backward-Compatible Improvements

Some of what has been learned over the past 15 years is simply not compatible with the design of TCP and/or the sockets interface. Consider Application Layer Framing, which suggests that applications be allowed to decide whether and how to recover from errors introduced at the lower level. While it is clear that the application knows best whether recovery is warranted for any particular data item, it is less clear that having all applications develop and implement their own mechanisms is a good idea.