[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Whither a session layer, and where (was Re: Consensus on identifier/locatorsplit?)
Spencer Dawkins wrote:
To the chairs - if this is seriously off-topic for multi6, please
feel free to say so...
I don't have any problem to move this elsewhere, if needed....
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).
Exactly. Now, if we do the id/loc split at the IP layer,
or anywhere between the packet forwarding function in the
IP layer and the connection/transaction management at the
upper layer, much of the above has to be thought again.
Or at least we have to have a mechanism to tell the
transport layer that the underlaying connection path is
not the same any more. And if we want to have real load
balancing, that is not enough. But I am certainly not a
transport area person, and most probably I underestimate
the potential problems...
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.
Well, the transport API is one thing.... Another benefit
might be found in the amount of signalling that is
necessary to establish and change the paths.
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...
OTOH, if the "session" layer was implemented in the
kernel, it would become available to all applications
at the same time.
N.B. I am not quite sure whether we should call this
"session" layer or not. In some ways it provides some
of the same services that the OSI session layer presumably
did, but in other ways it doesn't.
--Pekka Nikander