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

Javier Ubillos <jav@sics.se> Wed, 01 June 2011 08:10 UTC

Return-Path: <jav@sics.se>
X-Original-To: nbs@ietfa.amsl.com
Delivered-To: nbs@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6760AE06F2 for <nbs@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ovkmbksy0zg5 for <nbs@ietfa.amsl.com>; Wed, 1 Jun 2011 01:10:04 -0700 (PDT)
Received: from letter.sics.se (letter.sics.se []) by ietfa.amsl.com (Postfix) with ESMTP id 57593E075A for <nbs@ietf.org>; Wed, 1 Jun 2011 01:10:04 -0700 (PDT)
Received: from [] (h69n1-haes-a12.ias.bredband.telia.com []) (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 <jav@sics.se>
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 <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 01 Jun 2011 08:10:05 -0000

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
* 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