Layer 3.5 considered useful

[Iljitsch van Beijnum <iljitsch@muada.com>]

[About the "layer 3.5": yes, this is arbitrary and not exactly 
well-defined. But to the extend that just 9 characters bring to mind 
the concept of something sitting between IP and the protocols that 
provide transport functionality, it is a very useful term.]

If we consider transport protocols such as TCP (UDP being a special 
case as it provides almost none of the functionality traditionally 
associated with transport protocols) it is fairly obvious that each 
transport session lives in a universe of its own, with little or no 
regard for the possible existence of other sessions. In many cases, 
this isn't a good thing. For example, even to this day most HTTP 
interaction happens over a large number of concurrent TCP sessions, 
rather than over a single session. Another problem comes up when a 
single host "reflects" some data over a somewhat large number of TCP 
sessions, which can lead to catastrophic momentary congestion caused 
synchronization of the TCP session slow start state.

Then there is multiaddress multihoming. The simplest way to do this 
would be to associate the multihoming state with a pair of source and 
destination addresses. This isn't satisfactory because it can lead to 
fairly serious security problems. Similar risks make it necessary to 
have a good deal of negotiation between the two hosts involved, 
something that would be problematic if it had to be done for each 
individual TCP session used to retrieve a web page and the pictures 
embeded init.

These considerations alone make a layer that sits between IP on one 
side and TCP and similar protocols on the other side: such a new layer 
would make it possible to aggregate individual sessions to a 
comfortable level somewhere between the TCP view where every session is 
unique and independent, and IP where only the destination address 
counts.

Another good reason to introduce a new layer is that it allows 
continued use of both unmodified TCP and other transport protocols and 
even UDP, and unmodified IP.

However, we probably do want to change TCP (or switch to something 
different, such as SCTP) at some point in the future. So we should 
avoid painting ourselves into a corner by focussing on supporting 
unmodified upper layer protocols exclusively. In this regard it makes 
sense to analyze proposals that boil down to introducing a "layer 3.5" 
and see what functionality can be accomplished on one end (ie, one end 
has the new layer and unmodified TCP, the other also the new layer but 
a new TCP that is aware of the layer 3.5 functions and wants to have a 
say in how these functions are perfomed) and which require cooperation 
between both ends. Functions that can be performed on one end should 
NOT be a layer.

So our new layer 3.5 would consists of mechanisms that work end-to-end 
and it would have a private interface that provides hooks to future 
versions of transport protocols.

That would be useful.