Re: [nbs] NBS and TCP connection identification

RJ Atkinson <rja.lists@gmail.com> Wed, 13 October 2010 12:29 UTC

Return-Path: <rja.lists@gmail.com>
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 9D40E3A6AF3 for <nbs@core3.amsl.com>; Wed, 13 Oct 2010 05:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 2CmgdiQsJP+y for <nbs@core3.amsl.com>; Wed, 13 Oct 2010 05:29:36 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id EDA8E3A6AC8 for <nbs@ietf.org>; Wed, 13 Oct 2010 05:29:30 -0700 (PDT)
Received: by gxk20 with SMTP id 20so2233104gxk.31 for <nbs@ietf.org>; Wed, 13 Oct 2010 05:30:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=vBXoiksu62Sn2jtGCbjLMEBr57Vt8ve1sSOQzXuHoSc=; b=sHWd/FQhuQFMSszCRjyjQm1J8WJR96VWwZJiJxd9JtPJEDQljlH7xBUa4hKwQWUW/V N+miBInq/TfheI+jvKBI3+OCFKxx6i86WHk+ngu8BfW2s5aDsl/7OXSaHBFTGFwn/Dcg Ea8YF25G/1eF5topGOZK8IZuB1A03jPKT68sc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=EvvR4pw5kZ9XNFPQpShDkMfOlu0V4cf4l1NyhmGvB4R+nh1NOpS4h+119mu5Wp3+dd dQ+Bscaa4VxXWlNKS4ep4TzaWaOVieHKPRyRTeQ5mPXhVGlKorrEBmSnxOPSfhNHMhd1 LqGn35Zop7h5QOTsUzMQiReFpajYjZzNP12GM=
Received: by 10.101.180.32 with SMTP id h32mr4766038anp.105.1286973045900; Wed, 13 Oct 2010 05:30:45 -0700 (PDT)
Received: from [172.16.1.28] (h-66-134-38-70.mclnva23.static.covad.net [66.134.38.70]) by mx.google.com with ESMTPS id g29sm12313515anh.16.2010.10.13.05.30.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Oct 2010 05:30:45 -0700 (PDT)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 13 Oct 2010 08:30:42 -0400
Message-Id: <1324C224-7C8E-4630-AAEB-A4F7DEBC6326@gmail.com>
To: <nbs@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: Re: [nbs] NBS and TCP connection identification
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, 13 Oct 2010 12:29:44 -0000

On 5th October, David Harrington wrote:
> If consensus is that this is the goal, then the BOF
> should have participation from OS vendors indicating
> an interest in taking on this burden. 

I agree that would be highly desirable.

It is at least conceivable to me that the proposed new 
C/C++ API could be implemented as a library, containing 
calls to existing POSIX APIs [e.g. getservbyname(), 
gethostbyname(), and existing Sockets APIs] internally 
within the library.

Such a library implementation likely would have visibly
worse performance than just calling the POSIX functions 
directly, for example due to the function call overhead, 
but the library might be helpful in making the API more 
widely available on diverse OS platforms.

My main concern is application portability, not only across
operating systems, but also across a range of Internet 
networking protocols underneath.

> The BOF will also need to explain why this work belongs in IETF,
> rather than in other SDOs.


1) C/C++ API work

C/C++ networking interfaces have been standardised by 
IEEE POSIX.  So it seems clear that IEEE POSIX is the 
appropriate SDO for networking interface standardisation.  

That said, the IETF does have a history of creating
non-standard Informational RFCs proposing networking 
interfaces.  

Examples of this practice include:
	RFC-5014
	RFC-4584
	RFC-3542

In my mind, any API document produced in this area should 
follow that model, and also should be offered as a contribution 
to IEEE POSIX.

(I'm unclear how active the IEEE POSIX effort is these days,
but certainly IEEE has a very active Standards activity.)	

I think 3 aspects of the proposed API work are important 
enough that they should be explicitly required by any WG Charter:

A) The API should support use of names for all objects in the API,
   as various folks (e.g. Dave Thaler) have already suggested.
   [This means that raw "magic numbers", IP addresses, and odd
   "Sockaddr" structures are all best avoided.]

B) The API should be so generic that it can be used without any 
   special hooks or extensions over the wide gamut of networking
   protocols.  For example, an application written to this API 
   ought to run without modification equally well over IPv4, IPv6, 
   SHIM6, HIP, and ILNP.  The choice of networking protocol(s)
   to use also ought to be left to the underlying OS, not signalled
   by the application.

C) A corollary to (B) is that the name-based API should be totally 
   decoupled from any proposed set of protocol extensions.  If the
   API requires those extensions or assumes the availability of
   those extensions, then the protocol-independence is lost --
   and protocol-independence is the biggest potential value-add here.


2) Java API work

  There is no IETF value-add with respect to Java.  Java already
  has standardised name-oriented and nicely abstracted APIs for 
  networking.  So no work on Java appears to be needed.

  In any event, other clearly active activities cover Java APIs,
  so proposals for Java extensions should be taken there.


> Christian's paper proposed changes to protocols,
> such as transport protocol handshakes.
> The BOF should explain in detail how the changes proposed
> would happen only on hosts, not on routers, switches, etc.

For protocols that have existing active IETF WGs, then it 
seems to me that proposal to change those protocols ought 
to be undertaken within those WGs.

For example, any proposal to change/enhance TCP ought 
to be handled within the existing IETF TCPM WG.  

Yours,

Ran