From jav@sics.se Wed Jun 1 01:10:05 2011 Return-Path: X-Original-To: nbs@ietfa.amsl.com Delivered-To: nbs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6760AE06F2 for ; Wed, 1 Jun 2011 01:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovkmbksy0zg5 for ; Wed, 1 Jun 2011 01:10:04 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by ietfa.amsl.com (Postfix) with ESMTP id 57593E075A for ; Wed, 1 Jun 2011 01:10:04 -0700 (PDT) Received: from [192.168.0.224] (h69n1-haes-a12.ias.bredband.telia.com [213.65.145.69]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id EE51F400E2; Wed, 1 Jun 2011 10:10:02 +0200 (CEST) From: Javier Ubillos To: nbs@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-7Wss9DFf0C7zKSw1pQOO" Date: Wed, 01 Jun 2011 10:10:00 +0200 Message-ID: <1306915800.9571.79.camel@asus1001px> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Subject: [nbs] Working out a part of the name-based approach. X-BeenThere: nbs@ietf.org 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: Wed, 01 Jun 2011 08:10:05 -0000 --=-7Wss9DFf0C7zKSw1pQOO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone. This list has been resting for a while now. I'd like to (re-)kick start things with a few questions to you all. At which layer should a name-based approach be at? The way I see it, we already have a name-based interface in the high level languages. However, these implementations are typically unilateral and non-dynamic (in the id/locator-split sense). I guess we're trying to shoot three monsters at the same time: * A name-based network programming interface * An (simple) id/locator-split framework (not hard-defining names to be FQDNs) * A standardized way to check for bilateral support. E.g. to allow signaling for integrated protocols. These are the topics we've tried to address with the current name-based sockets prototype. Another decision in there was to place the bilateral-support check in the network-layer. Which on the major OSes means kernel-space. I guess this is bound to wherever one chooses to have the multiplexing point for the id/locator split. 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. Currently, we are still developing the name-based sockets prototype. We have integrated it with shim6, multi-path TCP, and happy-eye balls. We are looking at improving details and complementing naming infrastructures, keeping DNS compatibility, but making names require less infrastructure/overhead. // Javier Ubillos --=-7Wss9DFf0C7zKSw1pQOO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk3l89UACgkQGBo5FLRz4gp1+QCffFFEwib7+ctRoiUY6Mv/0in8 TskAoLgCjyKoor2sVExQcQGd9/evM2mN =8N2k -----END PGP SIGNATURE----- --=-7Wss9DFf0C7zKSw1pQOO-- From martin@kit.edu Tue Jun 7 03:34:01 2011 Return-Path: X-Original-To: nbs@ietfa.amsl.com Delivered-To: nbs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056DE11E80F0 for ; Tue, 7 Jun 2011 03:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 802FROrOQ0v6 for ; Tue, 7 Jun 2011 03:34:00 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id E825D11E80CA for ; Tue, 7 Jun 2011 03:33:59 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1QTtbc-0002jJ-4y; Tue, 07 Jun 2011 12:33:57 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1QTtbc-0008Fo-1Z; Tue, 07 Jun 2011 12:33:52 +0200 Received: from [172.21.164.46] (unknown [195.37.186.61]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTPSA id EB622205E2; Tue, 7 Jun 2011 12:33:51 +0200 (CEST) Message-ID: <4DEDFE8F.1060403@kit.edu> Date: Tue, 07 Jun 2011 12:33:51 +0200 From: Denis Martin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Javier Ubillos References: <1306915800.9571.79.camel@asus1001px> In-Reply-To: <1306915800.9571.79.camel@asus1001px> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1307442837.745812000 Cc: nbs@ietf.org Subject: Re: [nbs] Working out a part of the name-based approach. X-BeenThere: nbs@ietf.org 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 10:34:01 -0000 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). Denis -- Dipl.-Inform. Denis Martin Institut für Telematik, KIT Tel +49 721 608 46420 Zirkel 2, D-76131 Karlsruhe Fax +49 721 608 46789 http://telematics.tm.kit.edu Geb. 20.20, Raum 371 From jav@sics.se Tue Jun 7 05:58:47 2011 Return-Path: X-Original-To: nbs@ietfa.amsl.com Delivered-To: nbs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B1A11E8102 for ; Tue, 7 Jun 2011 05:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+MnzZ9lA7y8 for ; Tue, 7 Jun 2011 05:58:46 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8272F11E80C0 for ; Tue, 7 Jun 2011 05:58:46 -0700 (PDT) Received: from [193.10.66.63] (bit.sics.se [193.10.66.63]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id CB0FC402BB; Tue, 7 Jun 2011 14:58:43 +0200 (CEST) From: Javier Ubillos To: Denis Martin In-Reply-To: <4DEDFE8F.1060403@kit.edu> References: <1306915800.9571.79.camel@asus1001px> <4DEDFE8F.1060403@kit.edu> 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 Cc: nbs@ietf.org Subject: Re: [nbs] Working out a part of the name-based approach. X-BeenThere: nbs@ietf.org 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 --=-VatX2tkKvTbmSgW7NsEW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2011-06-07 at 12:33 +0200, Denis Martin wrote: > Hi, >=20 > 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. >=20 > Just for understanding: What would be the reason to have the > multiplexing point above the transport protocols? >=20 > 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 --=-VatX2tkKvTbmSgW7NsEW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk3uIIAACgkQGBo5FLRz4gokgQCbBnWxlzwhzFURoh8Gs667vk6A ZbsAn0fWOoOCDkDraKB+clm3EDf7YfTo =9zTx -----END PGP SIGNATURE----- --=-VatX2tkKvTbmSgW7NsEW--