[nbs] Synthesized names as session-labels - "Was: Re: I-D Action:draft-ubillos-name-based-sockets-03.txt"
Javier Ubillos <jav@sics.se> Wed, 20 October 2010 13:43 UTC
Return-Path: <jav@sics.se>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFF03A68B9 for <nbs@core3.amsl.com>; Wed, 20 Oct 2010 06:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.563
X-Spam-Level:
X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZp7h8Tm5kad for <nbs@core3.amsl.com>; Wed, 20 Oct 2010 06:43:03 -0700 (PDT)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id B92BE3A6828 for <nbs@ietf.org>; Wed, 20 Oct 2010 06:43:02 -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 9A524400E2; Wed, 20 Oct 2010 15:44:34 +0200 (CEST)
From: Javier Ubillos <jav@sics.se>
To: Rémi Després <remi.despres@free.fr>, Jan M <jmgm@iki.fi>
In-Reply-To: <1287497726.2189.113.camel@bit>
References: <20100917140001.E64E93A69BA@core3.amsl.com> <4CBA725A.30702@gmail.com> <1287493383.2189.89.camel@bit> <23ACFA24-8FE7-4E74-8289-493AF9F12A4A@free.fr> <1287497726.2189.113.camel@bit>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fcFaS2a7A91e9nXNY4t9"
Date: Wed, 20 Oct 2010 15:44:30 +0200
Message-ID: <1287582270.2189.328.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Cc: nbs@ietf.org
Subject: [nbs] Synthesized names as session-labels - "Was: Re: I-D Action:draft-ubillos-name-based-sockets-03.txt"
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2010 13:43:05 -0000
Rémi and Jan. About the whole "synthesized ip" issue. I have thought about it a lot and I'm curious as what you think about the methods along the following lines of thought. The reason I like the synthesized addresses at all is that it's easy to derive from something innate to the host. You don't need any pre-negotiation and it _might_ be better than a randomly generated nonce. However, two issues have made me rethink a bit: * When working with TCP, two names on the same host cannot share IP:Port pairs. The remote host, if it is not upgraded, wouldn't be able to distinguish the two flows. There for, a host needs some book-keeping mechanism to keep the 4-tuples unique. * Locally, we need the session-identifier to be unique as well to be able to keep the separate sessions distinct, but also manageable so that sessions who wish to multi-home/multi-path are able to find and re-use the correct session label. So, in other words: We need to be able to keep a record of which sessions use which srcIP:dstIP:srcIP:dstIP pairs (or whichever identifier a particular protocol uses) What needs to be solved is: * How to name unnamed nodes * How to generate sensible session-labels * To be able to separate sessions * And still allow to aggregate "sub-sessions" (e.g. a multi-path sessions) Personally, I think "sub-sessions" are a non-issue, as in the multi-path TCP case, we can still run standard TCP-sockets as each sub-socket to the master-socket which will need a session-label. A thought I'm playing with is to use a combination of a synthesized names and SRV-record syntax. This is an incomplete solution, let me show by an example: Host A communicates with Host B. Host A has IP(A) and wants to talk TCP/HTTP to B. So, it generates src name: _<sourceport>._tcp.<IP(A)>.ipv6.arpa dst name: _http._tcp.<IP(B)>.ipv6.arpa src IP: IP(A) dst IP: IP(B) src Port: _<sourceport> dst Port: 80 This way, when spawning new sockets, one can by just looking at the local name, avoid ip:port conflicts. However, this breaks in the mobility case, where this generated name no longer has a relation to the ip:port pairs used. Do any of you have any good suggestions on how to achieve the goal? Perhaps an overlap in session-labels is not a problem at all (maybe we can separate sockets at an application level, where no two applications may interfere with each others sockets... Do you guys have any good ideas/suggestions? // Javier On Tue, 2010-10-19 at 16:15 +0200, Javier Ubillos wrote: > On Tue, 2010-10-19 at 16:03 +0200, Rémi Després wrote: > > Le 19 oct. 2010 à 15:03, Javier Ubillos a écrit : > > >>> ... > > >>> o ip6.arpa. Using one of the hosts interfaces addresses as a name. > > >> > > >> Why would I want to use this? > > > > > > Another thing I should be more explicit about. > > > This is a construct for when a host does not have a name associated with > > > it. Then a name can be synthesized for it. > > > > Since translations from addresses to names are generally time consuming, and not necessarily as up to date as those from names to addresses, this should, as minimum, be an option that applications would have to request. > > The whole reverse-resolution/ip6.arpa infrastructure is not very broadly > deployed. > > The way I see it, it's comparable with a nonce, but which _might_ > contain some valuable extra information (the IP the communication was > started with). > > Also, i6.arpa -> name could very well generate multiple answers. How do > you know which one is right. > > In other words, this is not a huge deal, the intention is to _maybe_ > provide something that _might_ be more informative than an arbitrary > label. > If too many finds that it is just confusing and an eye-sore, we'll have > to reconsider that possibility. > > // Javier > >
- Re: [nbs] I-D Action:draft-ubillos-name-based-soc… Brian E Carpenter
- Re: [nbs] I-D Action:draft-ubillos-name-based-soc… Javier Ubillos
- Re: [nbs] I-D Action:draft-ubillos-name-based-soc… Rémi Després
- Re: [nbs] I-D Action:draft-ubillos-name-based-soc… Javier Ubillos
- [nbs] Synthesized names as session-labels - "Was:… Javier Ubillos
- Re: [nbs] Synthesized names as session-labels - "… Rémi Després
- Re: [nbs] Synthesized names as session-labels - "… Javier Ubillos