[nbs] A suggestion for an "on-demand API".

Javier Ubillos <jav@sics.se> Tue, 07 December 2010 09:24 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 DE6B33A6892 for <nbs@core3.amsl.com>; Tue, 7 Dec 2010 01:24:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Level:
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 u84+AXqr0RuN for <nbs@core3.amsl.com>; Tue, 7 Dec 2010 01:23:58 -0800 (PST)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 0C3663A692B for <nbs@ietf.org>; Tue, 7 Dec 2010 01:23:35 -0800 (PST)
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 5C6D84020A; Tue, 7 Dec 2010 10:25:00 +0100 (CET)
From: Javier Ubillos <jav@sics.se>
To: Name-based Sockets List nbs <nbs@ietf.org>
In-Reply-To: <1291652833.2046.72.camel@bit>
References: <1291652833.2046.72.camel@bit>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+shvW3LNlS0tWygh9yPo"
Date: Tue, 07 Dec 2010 10:24:57 +0100
Message-ID: <1291713897.2046.121.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Cc: Erik Nordmark <erik.nordmark@oracle.com>, Christian Vogt <christian.vogt@ericsson.com>
Subject: [nbs] A suggestion for an "on-demand API".
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: Tue, 07 Dec 2010 09:24:01 -0000

At IETF79, at some point after the name-based sockets BoF.
Together with Erik Nordmark and Christian Vogt, we sat down, discussed a
bit about name-oriented APIs and gravitated towards this idea:

The cost for behavior and an API should be incremental and optional, in
the sense that; you should only pay the price for a feature if you
really want to have it.

E.g.

* A web-server only requires a session-handle, the web-server will reply
to any-one initiating a session. No "extras" are asked for.

* Some other application might require authenticity of name->IP binding,
and is also prepared to pay the cost for that authenticity (typically a
round-trip).



An example:

Host A (A.left.org) and host b (B.right.org).

* Host A.left.net resolves "B.right.net" to IP(B).

* The packet received by B contains only IP(A) & IP(B).

* The application at B receives only a session-handle.


* Now, B can simply accept the session-handle and respond with data.
This would be the typical behavior for a web-server.

* Or, if B wants to know more, e.g. the IP and/or the name of the sender
it needs to query the API asking for it.


Asking for the IP should be trivial.
Authenticating the name (with the IP) would most likely come with a
cost. Either a round-trip to A, or a round-trip to DNS verifying the
name->IP.


Of course, the initiator could also set requirements for the
communication.


This way, all elements become optional, and are only used if the
application is ready to pay the cost for them.
In the trivial case, an application is simply only using an API which is
friendly and not paying the cost for any of the "extra" features.

// Javier