[nbs] A name-oriented API: What should it look like? How should it behave?

Javier Ubillos <jav@sics.se> Wed, 01 December 2010 09:18 UTC

Return-Path: <jav@sics.se>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id E17603A6CD4 for <nbs@core3.amsl.com>; Wed, 1 Dec 2010 01:18:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id v5LsFERnzudc for <nbs@core3.amsl.com>; Wed, 1 Dec 2010 01:18:46 -0800 (PST)
Received: from letter.sics.se (letter.sics.se []) by core3.amsl.com (Postfix) with ESMTP id 6B0DF3A69DA for <nbs@ietf.org>; Wed, 1 Dec 2010 01:18:46 -0800 (PST)
Received: from [] (bit.sics.se []) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 3AED140005; Wed, 1 Dec 2010 10:19:58 +0100 (CET)
From: Javier Ubillos <jav@sics.se>
To: Name-based Sockets List nbs <nbs@ietf.org>, Christian Vogt <christian.vogt@ericsson.com>, Stefan =?ISO-8859-1?Q?G=F6tz?= <stefan.goetz@cs.rwth-aachen.de>, Denis Martin <dmartin@tm.uka.de>, Helge Backhaus <backhaus@tm.uka.de>, Bengt Ahlgren <bengta@sics.se>, Stuart Cheshire <cheshire@apple.com>, Dave Thaler <dthaler@microsoft.com>, Erik Nordmark <erik.nordmark@oracle.com>, Miika Komu <mkomu@cs.hut.fi>, Tobias Heer <heer@cs.rwth-aachen.de>, Saleem Bhatti <saleem@cs.st-andrews.ac.uk>, Mingwei Xu <xmw@csnet1.cs.tsinghua.edu.cn>, Zhongxing Ming <mingzx@126.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-DfKn4KjrTrYsGwBkil5B"
Date: Wed, 01 Dec 2010 10:19:45 +0100
Message-ID: <1291195185.2018.417.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Subject: [nbs] A name-oriented API: What should it look like? How should it behave?
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, 01 Dec 2010 09:18:48 -0000

Hello everyone.

At the name-based sockets BoF (IETF79 November 8th) there was a clear
interest in defining an (abstract) API.

I wanted to get that discussion started, and I'd like to emphasize that,
at this stage, everything is an open question.
Here's a starting draft in which I intend to capture these discussions.

I have tried to synthesize, the feedback during the BoF and the  chats 
afterwards. Thank you Erik Nordmark, Saleem Bhatti, Mika Komu,  Tobias
Heer, David Thaler, Randall Stewart, Stuart Cheshire and everyone who
have argued with me and given me feedback. I greatly appreciate it!

Today we are already seeing name-oriented APIs in all kinds of
frameworks, they are very popular.
However, they tend to only leverage app-protocol functionality.
Also, as the service used defines the application-protocol used,
bi-lateral support is implied by the used service. This limits the
used to application-protocol functionality.

The objective is to make it easier for applications to make use of
networking solutions.

To achieve this *I* believe we need to:

API wise:
   * Provide an API in parallel to the socket() calls.
      * This API should take "names" in different formats.
         * Ability to select resolution system for names

   * The API should be able to receive information about which functions
     the application wants (e.g. multi-homing)

   * The API should be able to provide information
      * About which functions are available.
      * If the remote peer supports the requested features (if
        support is needed.)
      * About relevant changes (e.g. if the set of locators has changed)

Behavior wise:
   * When a recipient receives a connection, the receiving
     receives a simple, unauthenticated session handle.
      * If the application needs more information, it calls some part of
the API
        and is obviously prepared to pay whatever performance cost the
      * Possible (and optional!) features are:
         * Name exchange
         * Authenticity
         * (you name it...)

   * Making the name-exchange an optional part (and not an integral
part) means
     that it can be done on-demand. Whenever the user or some thing else
     requested by the user requires it.

I believe this also means that we need to have some functionality which
checks for bi-lateral support, and is able to exchange information about
what functions the respective peer wishes to use.

The name-based sockets implementation and draft(s) are attempts to
capture this (however, still incomplete when it comes to API questions).

// Javier