Re: [nbs] Scenarios (Was: Re: A suggestion for an "on-demand API".

Javier Ubillos <jav@sics.se> Wed, 02 February 2011 16:20 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 C387C3A6D6D for <nbs@core3.amsl.com>; Wed, 2 Feb 2011 08:20:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, 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 JpZZaQAAjnkh for <nbs@core3.amsl.com>; Wed, 2 Feb 2011 08:20:54 -0800 (PST)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 46A0E3A6D65 for <nbs@ietf.org>; Wed, 2 Feb 2011 08:20:54 -0800 (PST)
Received: from [193.10.66.199] (dab.sics.se [193.10.66.199]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 087A4402D8; Wed, 2 Feb 2011 17:24:13 +0100 (CET)
From: Javier Ubillos <jav@sics.se>
To: Denis Martin <martin@kit.edu>
In-Reply-To: <4D47DCC9.8030601@kit.edu>
References: <1294943649.3346.104.camel@bit> <4D47DCC9.8030601@kit.edu>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 02 Feb 2011 17:24:04 +0100
Message-ID: <1296663844.2155.226.camel@dab>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Cc: Name-based Sockets List nbs <nbs@ietf.org>
Subject: Re: [nbs] Scenarios (Was: Re: 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: Wed, 02 Feb 2011 16:20:56 -0000

On Tue, 2011-02-01 at 11:13 +0100, Denis Martin wrote:
<snip>
> > +----------------------------------------------------------------------+
> > | * One to one                                                         |
> > | * Bi-directional (e.g. TCP)                                          |
> > | * Bi-lateral support (Name-based sockets on both ends)               |
> > | * Requiring authentication of name->locator binding                  |
> > +----------------------------------------------------------------------+
> > |
> > |    -- Initiator:
> > |        CONNECTION *my_conn = ALLOC_SOCKET();
> > |
> > |        /* LOCAL_NAME() binds a local name. Unless some name-type is
> > |           chosen it defaults to FQDN */
> > |        LOCAL_NAME( my_conn, "initiator.name" ); 
> > |
> > |        DESTINATION_NAME( my_conn, "recipient.name" ); 
> > |        TRANSPORT( my_conn, TCP );
> > |        SERVICE( my_conn, HTTP ); // equivalent to htons(80)
> 
> Why mentioning the transport protocol explicitly? Isn't that a step
> backwards compared to, e.g., SOCK_STREAM where I just state that I want
> a reliable, stream-based transport? In the end, it should not matter to
> the application if it is TCP or SCTP or any future transport protocol as
> long as connectivity is provided.

Good point!
Any suggestions on how that choice should be made?
Perhaps happy-eyeballs style?

> > [...]
> > |        // equivalent to htons(12333), my imaginary service :)
> > |        SERVICE( my_conn, MY_VIDEO ); 
> 
> A global service registry would be necessary in this case. Or a
> namespace for user-defined services. So it probably will result in the
> use of today's port numbers. In this case, the interface should allow
> more than 65k for future extensibility.
> 
> A general thought about a new socket interface: We have to modify
> applications anyway, so we could even more augment that interface. We
> not only should get rid of addresses, but also of a concrete protocol
> selection done by the application. Regarding the scenarios, it could
> even be worth looking at new paradigms such as CCN. Admittedly, it might
> be a bit more distant in the future, but if we change that interface
> now, there might be the necessity of changing it again in a couple of
> years ;)

About service/ports:
I'm having a hard time marrying ports and service-names.
I don't know where to turn, in particular if we are not defining the
transport. If we use regular TCP, we need to reach a numeric port at
some point. If we are using some cool futuristic protocol, we might use
strings. But how do we get both?
I think the only way is to distribute a list somehow. Do you have any
suggestions on alternatives?
Why not check the official IANA list if we hit an unknown service name?
And of course, also accept "raw" port-numbers.

CCN:
I think this is a natural evolution, where we go down the path to
address in "higher resolution". Where we either address a serivce on a
specific host, or "just" the service/content. 
It makes sense to "open" an identifier which is some content and e.g.
get a file descriptor to it.

e.g. fd = open("/mystuff.org/things/somefile.txt/_v3/_s1")_s1");

// Javier