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

sowmini.varadhan@oracle.com Tue, 21 December 2010 21:06 UTC

Return-Path: <sowmini.varadhan@oracle.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 267463A68A4 for <nbs@core3.amsl.com>; Tue, 21 Dec 2010 13:06:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level:
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 Kc89RfSEi0Ob for <nbs@core3.amsl.com>; Tue, 21 Dec 2010 13:06:14 -0800 (PST)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 494E23A6888 for <nbs@ietf.org>; Tue, 21 Dec 2010 13:06:14 -0800 (PST)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBLL87d6017448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Dec 2010 21:08:08 GMT
Received: from quasimodo.us.oracle.com (quasimodo.us.oracle.com [10.152.12.37]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBLL86eA020402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Dec 2010 21:08:07 GMT
Received: from quasimodo.us.oracle.com (localhost [127.0.0.1]) by quasimodo.us.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id oBLKwKT7024076; Tue, 21 Dec 2010 15:58:20 -0500 (EST)
Received: (from sowmini@localhost) by quasimodo.us.oracle.com (8.14.4+Sun/8.14.4/Submit) id oBLKwIRu024075; Tue, 21 Dec 2010 15:58:18 -0500 (EST)
X-Authentication-Warning: quasimodo.us.oracle.com: sowmini set sender to sowmini.varadhan@oracle.com using -f
Date: Tue, 21 Dec 2010 15:58:18 -0500
From: sowmini.varadhan@oracle.com
To: Javier Ubillos <jav@sics.se>
Message-ID: <20101221205818.GG23421@quasimodo.us.oracle.com>
References: <20101214144734.GC12378@quasimodo.us.oracle.com> <1292401029.4804.30.camel@bit> <20101215154556.GE16665@quasimodo.us.oracle.com> <1292500103.4804.1313.camel@bit> <20101217231322.GB20694@quasimodo.us.oracle.com> <1292949711.4804.8474.camel@bit>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1292949711.4804.8474.camel@bit>
User-Agent: Mutt/1.5.14 (2007-03-31)
X-Source-IP: quasimodo.us.oracle.com [10.152.12.37]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4D111737.00DD,ss=1,fgs=0
Cc: nbs@ietf.org, christian.vogt@ericsson.com
Subject: Re: [nbs] (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: Tue, 21 Dec 2010 21:06:15 -0000

On (12/21/10 17:41), Javier Ubillos wrote:
> Good question!
> 
> I'm not sure, can one assume that UDP might not be _able_ to have a
> two-way communication?

UDP was just one example of a connectionless protocol that I suggested,
but I think the more critical thing (which is what I thought was
discussed in the meeting with Erik, perhaps he can clarify..) is that
you shouldn't (can't?) try to enforce name exchange/authentication at
the initial packet exchange, but rather let the application drive
this..

> If so, then there would be a clear incompatibility between using UDP and
> flow-requirements on the receiving host.
> 
> However, if that is the case, that we cannot send _any_ replies to the
> UDP stream, then:
> a. It becomes impossible to check for bi-lateral support (unless some
> other channel is used).
> b. It becomes impossible to exchange names and/or preferences.

not impossible.. in the udp example, the application that consumes
the udp packet can trigger (b) at its discretion (the actual mechanics
of how it will be done are TBD, but hopefully it would not be ULP-specific).

> 
> Assuming that we _can_ have a bi-directional communication. The
> UDP-version could very well include some kind of feedback mechanism
> where names & preferences are sent back to the initiator.
> 
> Is it a crazy idea to subdivide the data-gram domain into truly
> uni-directional flows and flows where we can have a bi-directional flow?
>