Re: [nbs] Working out a part of the name-based approach.
Javier Ubillos <firstname.lastname@example.org> Tue, 07 June 2011 12:58 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B1A11E8102 for <email@example.com>; Tue, 7 Jun 2011 05:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+MnzZ9lA7y8 for <firstname.lastname@example.org>; Tue, 7 Jun 2011 05:58:46 -0700 (PDT)
Received: from letter.sics.se (letter.sics.se [188.8.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8272F11E80C0 for <email@example.com>; Tue, 7 Jun 2011 05:58:46 -0700 (PDT)
Received: from [184.108.40.206] (bit.sics.se [220.127.116.11]) (Authenticated sender: firstname.lastname@example.org) by letter.sics.se (Postfix) with ESMTPSA id CB0FC402BB; Tue, 7 Jun 2011 14:58:43 +0200 (CEST)
From: Javier Ubillos <email@example.com>
To: Denis Martin <firstname.lastname@example.org>
References: <1306915800.9571.79.camel@asus1001px> <4DEDFE8F.email@example.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VatX2tkKvTbmSgW7NsEW"
Date: Tue, 07 Jun 2011 14:58:43 +0200
X-Mailer: Evolution 2.28.3
Subject: Re: [nbs] Working out a part of the name-based approach.
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nbs>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:email@example.com?subject=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
- [nbs] Working out a part of the name-based approa… Javier Ubillos
- Re: [nbs] Working out a part of the name-based ap… Denis Martin
- Re: [nbs] Working out a part of the name-based ap… Javier Ubillos