Re: Whither a session layer, and where (was Re: Consensus on identifier/locator split?)

["Spencer Dawkins" <spencer@mcsr-labs.org>]

To the chairs - if this is seriously off-topic for multi6, please
feel free to say so...

The problem with having session layer functionality (as
I understand it) underneath the transport layer, is that
so much of transport-layer functionality is tied to a
single connection path (P-MTU and RTT, to name two).

If path changes reset all of this functionality, it's not clear
to me what the benefits of being "above" session-layer
functionality might be.

And the bigger problem is that we have so many
transport protocols that are implemented in kernel
space - this was a huge problem for SCTP, and I
expect it will be a huge problem for DCCP as
well. If session-layer functionality is above transport,
end users can make decisions about deploying it;
if it's below transport, we're waiting for OS releases
before anything is possible. This shouldn't be "fatal",
but we even ended up deploying RTP-over-UDP
so we didn't have to wait for OS support of RTP
in kernels...

Spencer

----- Original Message ----- 
From: "Pekka Nikander" <pekka.nikander@nomadiclab.com>
To: "Iljitsch van Beijnum" <iljitsch@muada.com>
Cc: "Alain Durand" <Alain.Durand@Sun.COM>; <multi6@ops.ietf.org>
Sent: Tuesday, August 12, 2003 2:24 PM
Subject: Whither a session layer, and where (was Re: Consensus on
identifier/locator split?)


> Iljitsch van Beijnum wrote:
> > A much more useful approach would be to run the session layer
> > _underneath_ the transport layer so the transport protocol can do
its
> > magic and the session layer can juggle the addresses.
>
> I concur.
>
> The interface between such a session layer and the transport layer
> seems to become very interesting.  For example, which layer is going
> to keep track of MTU and RTT?  How to do traffic shaping between
> several transport connections going over a single
endpoint-to-endpoint
> "session"?  Etc.
>
> --Pekka Nikander
>
>
>