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).
All of this is dynamic. If we only change this when necessary there shouldn't be too many problems. (Could even drop a few packets on purpose to trigger slow start for TCP.)Exactly.
There are two cases: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.
Obviously if session and transport are both in the kernel there is a lot that can be done to make them work better together. It would be cool to have standardized mechanisms for this but in practice this is all about TCP anyway.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 the bigger problem is that we have so many transport protocols that are implemented in kernel space - this was a huge problem for SCTP,
We made the mistake of requiring changes to all applications once, let's not do it again.OTOH, if the "session" layer was implemented in the kernel, it would become available to all applications at the same time.
You're right, but we don't have anything on the table at this point so how can we come up with a good name?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.