Subject: [nbs] Preparing for a BoF about name-based sockets.

From: Javier Ubillos <[email-masked]>
Date: Tue, 14 Sep 2010 21:17:02 +0200

Hi everyone.

We think we got some good feedback after the two presentation at
Maastricht, so we've decided to move towards a BoF.

We are writing to you to ask for some input and feedback.

We would like to talk some about ID/Loc (names & locators) in general
and explore if there is more room within the IETF for it.
The short version is: Today we have ID/Loc splits at different levels,
however we think that are some advantages to this one.

Relevant documents:
BoF Proposal: https://www.sics.se/nbs/bof/Proposal%20for%20Name-Based%
20Sockets%20BoF.pdf
Draft: http://www.ietf.org/id/draft-ubillos-name-based-sockets-02.txt

About the draft: Please note, the draft _will_ be divided into two
different documents, one about name based sockets, and one about how
shim6 can be improved with name-based sockets.
We have been a bit unclear earlier, name-based sockets is about the
naming layer & mechanisms. The described shim6 improvements are an
example on solutions that can be improved and integrated using
name-based sockets.

// Christan Vogt and Javier Ubillos

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Sep 2010 13:59:20 +1200

Maybe you need to discuss this on the shim6 list, where the current
plan is probably to have no meeting in Beijing since the main work
is finished.

Regards
   Brian Carpenter

---

From: Dave Thaler <[email-masked]>
Date: Wed, 15 Sep 2010 02:07:06 +0000

> > // Christan Vogt and Javier Ubillos

I support having a BOF on this topic.

I think splitting the draft is a good thing, and I have feedback on at least the
API portion.  Specifically, the API needs to use service names, not integer
port numbers.   getaddrinfo() already does so, and section 7.2 of
draft-ietf-tsvwg-iana-ports-06 will only make this more important.

Don't make the mistake of using integer port numbers in an API that
claims to be "name-based".

-Dave Thaler

---

From: Christian Vogt <[email-masked]>
Date: Wed, 15 Sep 2010 01:08:13 -0400

> plan is probably to have no meeting in Beijing since the main work

Oh yes, good point, we need to involve the Shim6 folks in the discussion.  Javier, could you add Geoff Huston, Kurt Lindqvist, and Marcelo Bagnulo to this list, please?  Thank you!

- Christian

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Sep 2010 10:14:35 +0200

Le 15 sept. 2010 à 04:07, Dave Thaler a écrit :
> ...
> Specifically, the API needs to use service names, not integer

+1
RD

> 
> -Dave Thaler
> _______________________________________________
> nbs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nbs

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 15 Sep 2010 10:30:50 +0200

> claims to be "name-based".

This is "in the pipe line".
The current prototype _does_ use port numbers, however, the aim is to
move to service names in some incarnation.

I have tried to be cautious in talking about it, trying not to
complicate matters too early.
I'll make sure it is covered in the next version of the draft.

It is mentioned in Christians 2008 article "Towards A Hostname-Oriented
Network Protocol Stack for Flexible Addressing in a Dynamic Internet".
http://christianvogt.mailup.net/pub/vogt-2008-hostname-oriented-stack.pdf

// Javier

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 15 Sep 2010 14:20:02 +0200

On Wed, 2010-09-15 at 07:46 -0400, Ran Atkinson wrote:
> On 14  Sep 2010, at 22:07 , Dave Thaler wrote:
> > I think splitting the draft is a good thing,
> > and I have feedback on at least the API portion.  
> > Specifically, the API needs to use service names,
> > not integer port numbers.   getaddrinfo() already does so,
> > and section 7.2 of draft-ietf-tsvwg-iana-ports-06
> > will only make this more important.
> 
> Agreed.  
> 
> One hopes that any new API will be entirely name-based 
> (i.e. no "magic numbers").  One hopes the I-D will be 
> updated soon to reflect this.
> 
> Offering some entirely name-based APIs, as some programming
> languages (e.g. Java) already have done, enables well-behaved
> applications to work equally well not only over IPv4 and IPv6, 
> but also over SHIM6, LISP, MP/TCP, ILNP, or whatever else 
> might appear in future.
> 
> Yours,
> 
> Ran

That is exactly the plan! :)

To provide a thin naming convention, allowing arbitrary fun things
beneath it. Things that provide cool features I need not know about.
It also allows higher abstractions, as the Java one, to just pass the
name down to the socket layer, and reap the benefits of the available
features.

I'm also playing with a thought for the future:
Some form of "feature-negotiation" between two nodes. Where they e.g.
agree to use MP/TCP and/or ILNP.
This might be something for the BoF.

Out of scope for the BoF, but this might lead to some
"feature-arbitration framework". Perhaps as a part of larger "name-based
stack"-architecture. But, we will eventually need a way of having
different features play nicely with each other. For example the case
where we have Shim6, ILNP and MPTCP available, it wouldn't make sense to
stack INLP & Shim6 for each MPTCP (sub) flow.

// Javier

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 15 Sep 2010 21:44:41 +0200

(sorry for sending double copies, I messed up the recipient list on the
previous one).

On Wed, 2010-09-15 at 10:24 -0700, Dan Wing wrote:
> Here's the problem I see to get this going:  the only applications
> that have referral problems are applications that do referrals.  This
> is not a general problem for HTTP.  It is a general problem for 
> SIP/XMPP/RTSP, which have a separate signaling channel from their
> data channel.  The problem I see is how does "Grandma's computer"
> get a name?
> 
> All the APIs to *use* that name are neat, and absolutely necessary.  
> But if the computer doesn't have a way to get a name...  aren't
> we missing the important bootstrapping function? 

The way I see it, the lookup substrate is still undefined, and there is
not a single solution.

Today, in the draft we have:

"
   Names can be provided in any of three ways.

   o  FQDN.  The Fully Qualified Domain Name of the host.  This will
      allow e.g.  DNSsec to provide authenticity of the name.

   o  ip6.arpa.  Using one of the hosts interfaces addresses as a name.

   o  Nonce.  A one-use only session identifier.
"

This might very well be extended to include

   o  "Naming convention of your own choice."

The API can include a field indicating what kind of name this is (and
hopefully also have some sensible default).

This way, an application can choose lookup its substrate from a palette
of solutions.

Granma's computer can either be referred to by FQDN, IP, your favorite
lookup system and so on. Pick your favorite.

Method of NAT penetration would be coupled with this.
A naive example:
Let name-based sockets include Teredo, insert your name + teredo-address
into Kademlia. 
Without making any claims about performance, there's a recipe for
arbitrary name + NA(P)T transparency.

I don't think we'll have a silver-bullet solution that works for all.
We need to provide a set of solutions.

// Javier

---

From: Javier Ubillos <[email-masked]>
Date: Fri, 17 Sep 2010 16:11:15 +0200

<snip>
> claims to be "name-based".

The draft is now split into two.
draft-ubillos-name-based-sockets-03
draft-xu-name-shim6-00

The part about port numbers has been updated.

// Javier