[nbs] NBS assumptions: What can change?(was: Re: NBS and TCP connection identification)

[Javier Ubillos <[e-mail]>]

Sorry for the delayed answer.
I'll reply in two different e-mails.

On Fri, 2010-10-01 at 09:37 -0700, Erik Nordmark wrote:
<snip>
> > I am hesitant to solutions that infer delays in the connection setup.
> 
> Some perspective on this might be useful.
> Depending on who you ask you find that the community has thought about 
> or worked on id/locator separation for 30 years, or merely 15 years.
> 
> As we've discussed this radical change to the architecture, much of the 
> feedback is around "you can't change X", where different folks are 
> concerned about different values of X. The result is that we haven't 
> changed anything, and as a result we've made no progress.
> 
> It is pretty clear to me that if we want some form of id/locator 
> separation architecture, then some things will change. We definitely 
> have to be cognizant of this and understand the tradeoffs, but starting 
> off with "we can't change X" for any value of X isn't likely to be a 
> good approach.

I'm not saying that this way is better (we'll actually I am, but a
healthy approach is to presume that I'm wrong ;).

There are a lot of preexisting solutions to ID/Locator split.

What we do have so far however is this either splits further down in the
stack as shimming layer at the network layer of the stack (e.g. HIP), or
in the network (e.g. LISP).

What we are suggesting is a different deployment approach.

Doing stuff in the network requires that we change the network.
Doing stuff in a shimming layer is fine, but how does the application
know what it gets?
Doing stuff in a higher layer allows us to 
a. Explicitly declare what you want/assume
b. Be able to deploy the solution in the OS _or_ in user-space.

Option b here I think is what makes NBS very different.
(I'm now representing a very personal opinion, there is no consensus
about this)
We may very well have a scenario where name-based sockets are
distributed as a library, which gives preference to OS implementations.
This way, applications will for sure know what they are getting, and may
be distributed without concern about which OS-version they will be
deployed on. Historically, user-space libraries tend to gravitate
towards becoming part of the OS:es.

So, why am I hesitant to delays in the connection setup?
Because, for an ID/Loc split to be deployed, it has to make stuff
better.
E.g. logging on to g-mail, you have several of "first packets".
These are sometimes also sequential, so that one connection has to
finish before the next can start.

What I envision is something that _starts_ as a legacy communication,
and then builds up surrounding features, very much as shim6 does when it
waits for 50 packets to be exchanged before it kicks-in.

Note that this is orthogonal to name-based sockets being or not.
It is just the way I would like to see things happen.
I want it to be good _and_ deployable :)

>  From what I understand from folks at Google a significant part of the 
> "connection setup" is actually the DNS lookup, and for the case of a web 
> browser doing lots of connections there are approaches to 'prefetch' and 
> parallelize that part. Potentially similar approaches can be applied if 
> there is a need to do some validation or other exchanges in an 
> id/locator system.

Intresting.
I have so far presumed that if an application uses DNS-resolution
anyway, that name-based sockets would be equal.
Perhaps some method of pre-feeding resolutions would be nice?
E.g. where name-based sockets can provide applications with a
local /etc/hosts or dns-proxy which can be fed with good assumptions
(such as prefetches).

Optimizing this now is a bit premature, but what kind of nerds would we
be if we abstained?

// Javier