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

Denis Martin <martin@kit.edu> Wed, 02 February 2011 17:16 UTC

Return-Path: <martin@kit.edu>
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 5C1E43A6C0B for <nbs@core3.amsl.com>; Wed, 2 Feb 2011 09:16:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 OC+HW+LsxE6a for <nbs@core3.amsl.com>; Wed, 2 Feb 2011 09:16:56 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 976123A6BC0 for <nbs@ietf.org>; Wed, 2 Feb 2011 09:16:54 -0800 (PST)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PkgND-0000aU-VG; Wed, 02 Feb 2011 18:20:13 +0100
Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1PkgND-000133-Q8; Wed, 02 Feb 2011 18:20:07 +0100
Received: from [IPv6:2001:638:204:6:21f:16ff:fe28:b05c] (unknown [IPv6:2001:638:204:6:21f:16ff:fe28:b05c]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTPSA id B69DA2FC024; Wed, 2 Feb 2011 18:20:07 +0100 (CET)
Message-ID: <4D499246.5080903@kit.edu>
Date: Wed, 02 Feb 2011 18:20:06 +0100
From: Denis Martin <martin@kit.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Javier Ubillos <jav@sics.se>
References: <1294943649.3346.104.camel@bit> <4D47DCC9.8030601@kit.edu> <1296663844.2155.226.camel@dab>
In-Reply-To: <1296663844.2155.226.camel@dab>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1296667213.807490000
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 17:16:58 -0000

On 02/02/11 17:24, Javier Ubillos wrote:
> On Tue, 2011-02-01 at 11:13 +0100, Denis Martin wrote:
> <snip>
>>> |        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?

Could be an option, though I wasn't thinking about how to actually
select the "right" transport protocol. These might be two different
problems:

 1) Specifying the transport requirements, eg.:
      stream-based, datagram-based, unreliable, reliable,
      with flow-control, without flow-control,
      authenticated, encrypted, etc.
    The application could select any combination, eg.
    "datagram-based with flow-control but not necessarily with ARQ".
    This could even be augmented with QoS requirements such as minimum
    guaranteed bandwidth.

 2) Selection of an actual (combination) of protocols.
    The hardest part ;) In case there is only UDP and TCP, it could be
    hard-coded, of course. If there is a huge number of protocols to
    choose from, happy-eyeballs probably won't scale.

With a new socket interface, maybe 1) can be considered. 2) adds too
much complexity - but it might also not be necessary to solve it right
now, is it?

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

Not really. A general service registry (à la DNS - which is already used
as such if you look at MX records or SIP entries) could be an option. Or
a standardized end-to-end signalling protocol for protocol and service
negotiation. That's also something which needs to be solved, but is not
directly bound to the socket interface as seen by the application, right?

> Why not check the official IANA list if we hit an unknown service name?
> And of course, also accept "raw" port-numbers.

Agree.

> 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");

So, you mean that such application interfaces would be on a higher level
anyway?

And if we introduced namespaces? Eg.

  DESTINATION_NAME( fd, "ccn:/mystuff.org/things/somefile.txt" );

Regards,
Denis

-- 
Dipl.-Inform. Denis Martin

Institut für Telematik,  KIT   Tel +49 721 608 46420
Zirkel 2,  D-76131 Karlsruhe   Fax +49 721 608 46789
http://telematics.tm.kit.edu   Geb. 20.20,  Raum 371