Subject: Layer 3.5 considered useful

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Jan 2004 19:16:54 +0100

[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.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 27 Jan 2004 07:27:31 +0900

Iljitsch;

The fallacy of layer 3.5 is introduced to assert that layer 3
solutions had existed, which is why Brian wrote a sweeping
definition:

> We can hardly disagree. But TCP is not SCTP, UDP, DCCP or ICMP either.
> The systems level argument for a layer 3.5 solution is that it can cover
> all cases, including ones we have not invented yet.

As you modify Brian's definition of layer 3.5 that:

	UDP being a special case 

there will be other special cases for non-TCP protocols including
ones we have not invented yet that there is no reason to insist
on the fallacy.

So, your reduced requirement is merely that:

	The systems level argument for a layer 3.5 solution is
	that it can cover a TCP case.

which is a TCP specific layer 4 solution.

That is, there is no such thing as layer 3 solutions.

Note that layer 4 protocols can and will share some function
calls to control M6, just as TCP and UDP can share a function
call to compute check sum that it is an issue independent of
layering. We don't have to make transport layer check summing
layer 3.5, only to let TCP and UDP share some function calls.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Jan 2004 23:45:31 +0100

On 26-jan-04, at 23:27, Masataka Ohta wrote:

> ones we have not invented yet

UDP is a special case because it doesn't provide reliability or 
congestion control. There is no reason why UDP should necessarily be a 
special case for multihoming. The only reason to make it a special case 
would be because UDP interactions are often very short-lived.

And yes, there will always be special cases, the world is a complex 
place.

> that there is no reason to insist on the fallacy.

Which fallacy?

> which is a TCP specific layer 4 solution.

I don't see any reason why a solution that sits between IP and upper 
layers couldn't work with all upper layers, first and foremost TCP, but 
also UDP and the real-time protocols built on top of UDP.

> layer 3.5, only to let TCP and UDP share some function calls.

If you prefer to look at it this way, I have no problem with that. 
Different people have different outlooks. One man's waves are another 
man's particles...

Iljitsch

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 27 Jan 2004 08:09:31 +0900

Iljitsch;

> And yes, there will always be special cases, the world is a complex place.
> 

> Which fallacy?

Layer 3.5 with the definition of:

	it can cover all cases, including ones we have not invented yet.  

> also UDP and the real-time protocols built on top of UDP.

You are confusing layering of protocols and structure of
implementations.

See below.

> Different people have different outlooks. One man's waves are another 

TO enlighten you, quantums are neither waves nor particles
but are distributions. It is not a problem of outlook.

That some implementation share some function calls does not
mean others must also share them.

That you have some function calls in some layer 4 but not in
others means that the functionality is at layer 4.

						Masataka Ohta