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

Javier Ubillos <> Tue, 07 June 2011 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26B1A11E8102 for <>; Tue, 7 Jun 2011 05:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z+MnzZ9lA7y8 for <>; Tue, 7 Jun 2011 05:58:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8272F11E80C0 for <>; Tue, 7 Jun 2011 05:58:46 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id CB0FC402BB; Tue, 7 Jun 2011 14:58:43 +0200 (CEST)
From: Javier Ubillos <>
To: Denis Martin <>
In-Reply-To: <>
References: <1306915800.9571.79.camel@asus1001px> <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VatX2tkKvTbmSgW7NsEW"
Date: Tue, 07 Jun 2011 14:58:43 +0200
Message-ID: <1307451523.7685.11.camel@dab>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Subject: Re: [nbs] Working out a part of the name-based approach.
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Name based sockets discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jun 2011 12:58:47 -0000

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