Re: [tae] [tsv-area] Transport negotiation

On 3 Dec, 2008, at 13:57, james woodyatt wrote:
> The "transport layer" is identified by the upper layer protocol  
> header at the end of the extension header chain of the inner-most  
> encapsulated IP packet.

This might be a fine answer to the question, "What is the transport  
layer?" on the mid-term exam for an introductory undergraduate  
networking class.

The notion of layers in networking is an artificial simplifying  
assumption introduced to help us think about software design (and to  
help ISO divide their people up into seven committees). Like all  
simplifying assumptions, there are cases where it is helpful, and  
cases where it is not. This is a case where religious adherence to  
apparent layer boundaries is not helpful.

Bryan Ford's excellent "Breaking Up the Transport Logjam"  
presentation pointed out that what we call the "transport layer"  
artificially takes three functions (demux, flow control, and  
operational abstraction) and lumps them together in what we  
traditionally call "transport layer", while leaving out other  
functions (session, presentation, etc.) and artificially deeming them  
to be "not transport layer". Such artificial distinctions do not help  
guide our networking design thought processes in useful ways.

For our purposes here, there are three relevant groupings:

C. Application/Presentation/Transport/etc.
B. IP
A. Datalink/Hardware/etc.

In group (A) there are differences due to inherent differences in the  
underlying hardware.
The purpose of IP (group B) is to homogenize away those hardware  
differences and present a uniform service model.
In group (C) there are intentional differences due to the different  
requirements of different applications.

The point is that the differences in group (C) are *intentional*.  
Different applications have different requirements. The whole *point*  
of having different transport protocols is that they offer different  
operating semantics -- e.g. UDP preserves message boundaries; TCP  
does not.

I think that when we denote a certain application protocol using a  
name like "foobar", that name has to encompass the complete package  
of everything the application uses, requires, and assumes, from the  
IP layer up. Tempting as it is to think of networking as a set of  
tinker-toy components that can be just plugged together in whatever  
order we feel like, in the real world software is a lot more brittle  
than that. I'm all in favour of applications negotiating capabilities  
and requirements, but that has to be done by the applications, and  
done carefully, with thorough testing. Thinking that we can solve  
this problem by just enumerating all the permutations in the DNS  
seems naive to me.

Stuart Cheshire <cheshire@apple.com>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae