Re: [nbs] Working out a part of the name-based approach.

[Javier Ubillos <[e-mail]>]

On Tue, 2011-06-07 at 12:33 +0200, Denis Martin wrote:
> Hi,
> 
> On 01/06/11 10:10, Javier Ubillos wrote:
> > This also has implications for distribution, e.g. if we choose the
> > multiplexing point above the transport protocols, it can easily be
> > distributed as a user-space library to be used by applications.
> 
> Just for understanding: What would be the reason to have the
> multiplexing point above the transport protocols?
> 
> At the network layer, you gain, e.g., mobility support through loc/id
> split, and thus a certain flexibility during the life-time of a
> communication. The transport protocol or service address (port) cannot
> change during the communication. Initial flexible selection of a
> transport protocol or a service discovery, however, is not affected
> (i.e. can still be done).


Look at how e.g. MPTCP solves that issue.

The point is, using a name-based approach, we _can_ aggregate (almost)
arbitrarily, e.g. using multiple connections at a transport level.

Having the multiplexing point above the transport layer would allow
easier distribution of the solution. Looking at platforms as e.g.
Windows, OSX, linux, or frameworks as Java, Python and so on. They all
"cut" at the transport layer. Applications are allowed to open up a
socket and to pick a transport protocol, but that's about it.

Drawbacks are that you loose the ability to manipulate the other layers
headers, e.g. as we have chosen with the current prototype, to add
IP-extension headers for the extra signaling.

// Javier