Subject: Re: [rrg] Multiple critiques, choice of single proposal, consensus on constraints due to voluntary adoption?

From: [email-masked] (Noel Chiappa)
Date: Mon, 1 Feb 2010 10:59:22 -0500 (EST)

> From: "Joel M. Halpern" <[email-masked]>

    > the value of ID / Locator separation

There's a reason that I always phrase it 'separation of location and
identity', i.e. describe the architectural goal at a high level, in terms of
abstract properties, not in terms of specific naming mechanisms.

Alas, it doesn't seem to be catching...

    > even within this limited community, there have been significant
    > differences is when the term "identifier" should be used.

I agree. "Identifier" is an _existing_ term which _already_ has meaning(s),
and trying to use it for yet another (ill-defined) thing is to virtually
_invite_ confusion.

There's a reason that I introduced a new term ('EID'); which I defined to
have the following semantic/syntactic properties: 'globally-unique,
location-insensitive, fixed-length (and relatively short, i.e. < 128 bits or
so), binary (i.e. not-human friendly)'. (See Section 10.2 of the 'Endpoints
and Endpoint Names' document.) I.e. it has a fairly well-defined set of
semantic and semantic properties.

If people wanted a term for, say, 'an identifier which names an endpoint in a
way which is globally-unique and location-insenstitive', a _unique_, _new_
term should have been created - not reuse an existing one, a step which is
virtually _guaranteed_ to _increase_ confusion.

    > In my book, an IEEE MAC address is an identifier. 

True - but it also names an _interface_, not an _endpoint_ - and that's
_another_, very distinct axis along which the classic 'IP address' is
confused/ambiguous.

    > In a true MP-TCP environment, one might well want to view the
    > identifier as being above the TCP flows. .. in a regular TCP
    > environment, placing the identifier below TCP so that TCP picks up a
    > significant degree of locator invariance without needing MP-TCP is also
    > valuable.
    > ...
    > I do not want to get tied up in the question of which layer should hold
    > the identifier.

A very interesting and powerful observation.

After brief thought, I don't think the issue is that we have too few
namespaces at hand (e.g. we are lacking sessions, or something). I think in
this case the problem is that we are trying to have 'TCP' work with only
_one_ namespace. (I put 'TCP' in quotes for a reason - see below.)

In fact to really do some of the things MP-TCP is trying to do (e.g. make use
of host multi-homing for multiple, parallel sub-streams), it does in fact
need to know about _two_ separate ones - the identity of the endpoint which
it is talking to, and the locations of the interfaces through which it can be
reached.

So uni-cast TCP and MP-TCP do occupy slightly (and significantly) different
places in the architectural 'stack', which is why the endpoint->interface
binding ideally happens _below_ 'classic' TCP, and _in_ MP-TCP.

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 01 Feb 2010 11:41:31 -0500

A clarification on something I have debated, but not resolved, with some 
of the MP-TCP folks...

Noel Chiappa wrote:
...
> binding ideally happens _below_ 'classic' TCP, and _in_ MP-TCP.

As far as I can tell, the MP-TCP thing works without having such an 
end-point identifier.  Their view, as I understand it, is that they 
establish communication based on some location pair.  They then use that 
communication to establish enough shared sessions tate that they can 
relate other communication streams (TCP connections) to the initial one, 
to form the full session.
Thus, the location independent identifier is a dynamic value determined 
once communication is established.

It seems to me that having a stable long term location independent name 
for the communicating entities would be helpful, but I have not done a 
good job of articulating why.

Yours,
Joel

PS: While I agree with the points I elided, I do wonder if we really 
need a different term for the location insensitive, stable name when we 
use a short binary string vs when we use a thing that looks like a DNS name.

---

From: Scott Brim <[email-masked]>
Date: Mon, 01 Feb 2010 11:48:56 -0500

> _one_ namespace. (I put 'TCP' in quotes for a reason - see below.)

I can't find the "see below".  Do you mean where you distinguish between
single subflow and multiple subflows (MPTCP)?

> it is talking to, and the locations of the interfaces through which it can be

... for certain definitions of "endpoint" :-).  That is, MPTCP does not
need to know an identity for a whole node, anymore than current TCP
does.  Other functions might, but MPTCP doesn't care what box or VM it's
talking to, it only cares about the other higher-layer endpoint.  What
it needs for identification is something at the level of a "connection"
or "session".

> places in the architectural 'stack', which is why the
> endpoint->interface binding ideally happens _below_ 'classic' TCP,
> and _in_ MP-TCP.

Only because in the classic non-mobile uni-subflow TCP case the
separation of "endpoint" (the top of the transport layer, sometimes
called session) from "location of endpoint" is not necessary -- they are
always bound.  The difference is still there, even if the conceptual
separation isn't, and architecturally what TCP of any sort needs for
identification is the same, but classic TCP's mistake is that it uses
lower-layer, location-dependent information in its identification function.

If you are going to change the endpoint stack to support mobility and
multihoming, it's nice to only have one function doing a particular task
(e2e argument invoked here).  But I think that might be outside the
scope of RRG.

Scott

---

From: Scott Brim <[email-masked]>
Date: Mon, 01 Feb 2010 11:55:35 -0500

> once communication is established.

Yes, although I wouldn't call them TCP connections.

> use a short binary string vs when we use a thing that looks like a DNS

I never named them, but here's my list.  I think you're talking about #2
and #3.

    * identifiers for access, to use a visited network at all.

    * identifiers for initially finding something you want to talk to.
      Examples would be domain names and SIP URIs.

    * identifiers used for initial contact, in order to establish
      sessions.

    * identifiers used for session control: initial authentication and
      association of locators with sessions, as well as
      re-authentication when locators change.

    * identifiers used in referrals, whereby one endpoint tells another
      about yet a third.

---

From: Mark Handley <[email-masked]>
Date: Mon, 1 Feb 2010 17:08:53 +0000

> it needs for identification is something at the level of a "connection"

That's exactly right.  Also, much of the time MP-TCP will be working
with one (and perhaps both) ends NATed.  So MP-TCP really doesn't want
to make any assumptions that any identifier that works for one
connection will work for another.  All MP-TCP connections are
independent from the point of view of the TCP part of the stack, even
if they happen to share IP addresses.

What we've tried to do, at least for now, is to uncouple MP-TCP from
other possible enhancements to the stack.  Deployed, it would work
right now on smart phones and so forth without any other changes to
how anything is addressed.  Indeed we were testing our implementation
last week over WiFi and 3G simultaneously from a mobile host to an
upgraded but single-homed server, and it worked very nicely and coped
well when either the WiFi or the 3G lost signal.

In the long run though, it would be great to have a way for an
end-host to have some visibility into network attachment points and/or
paths, even if they were several IP hops away.  For outgoing traffic,
that's the one part in the MP-TCP deployment story that could do with
help from the network.

 - Mark