Subject: RE: Consensus on identifier/locator split?

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 7 Aug 2003 12:03:27 -0400

> From: "Christian Huitema" <[email-masked]>

    >> if you want to keep the existing TCP

    > I am not sure that I want to keep the existing TCP

Well, either ways has pros and cons. From my position (which these days is
purely architectural) I have no position on that particular question.
I suspect that others, who weigh practicalities more highly, may not agree,
but they should speak up for themselves.

    > create an identifier inside TCP, and then associate several
    > addresses/locators to the connection.

I'll be mildly irritating by first pointing out that you separating location
and identity there, too... :-)

On a more serious note, whether or not you make identity, and the bindings
from identity to location, a function of the transport layer (or perhaps even
higher, maybe at some sort of session layer - which is what HTML does with
cookies) is a good question.

The pros of doing it at the higher layers are that i) you can add it a
protocol at a time; and ii) that you can optimize each namespace/binding
mechanism to the protocol which uses it.

The cons of doing it at a higher layer are that i) you have to do over and
over again for each protocol; ii) protocols which don't make themselves more
complex by including these mechanisms lose those capabilities; iii) there is
more archiectural/engineering complexity since basically the same mechanism
will be repeated over and over again; iv) there is potentially more
operational overhead since when an endpoint moves, if there is more than one
protocol (or connection, if the mechanism's on a per-connection basis) to a
correspondent host, each protocol (or connection) will have to be moved
separately.

Looking at all that, it seems to me, from an architectural point of view, to
be wiser to put it somewhat lower down in the stack. YMMV if you take other
considerations more highly.

I don't know if MIPv6 made this kind of analysis, but they certainly wound up
putting the identification/location split, and the binding mechanisms, at a
low level, gaining the benefits listed above under "cons".

    > I actually like the fact that TCP can see and manage "locators",
    > because the transport is one of the best places to maintain short term
    > knowledge about the relative performance of a specific path, and thus
    > arbitrage between the various paths.

I concur that location does need to be *visible* to higher layers, and they
need the *ability* to manage it *if they chose*.

Of course, many applications may not care, and may not want the
responsibility, so some "default" behaviour needs to be provided for them.

    > The idea of an optional upgrade to TCP is interesting because it allows
    > hosts to "opt in" the new facility. I would expect that many hosts
    > would actually opt out, either because they only use short lived
    > sessions and thus don't care for an exceptional failure, or because
    > their applications know how to manage sessions and patch together
    > multiple connections.

Yes, but this is true whether one puts the identification/location split, and
the binding mechanisms, at a high layer, or a low one, no?

E.g. if you aren't mobile yourself, and don't care to talk to anyone who is,
you can leave out MIPv6.

    > Indeed, this is a generic requirement for any identifier scheme: hosts
    > that don't see the point should be able to opt-out and not bear the
    > burden associated with the "layer of indirection."

The problem with this attitude is revealed in my comment above about "don't
care to talk to anyone who is". *You* may not be multi-homed, and therefore
have no interest in implementing a multi-homing mechanism, but if the entity
you're talking to is, it loses the ability to make use of its multi-homing if
you don't play ball.

Of course, we could always (as previously discussed at length here) have
different levels of functionality, so that at the base layer of functionality
a host can be multi-homed, and can switch from one ISP to another for new TCP
connections, but existing TCP connections to it won't survive if it switches
ISP's - the advantage being that the former will work with *unmodified* hosts
on the far end, whilst the second is only available with *modified* hosts.

Actually, if you reuse MIPv6 mechanisms to handle the "existing TCP
connections" case, you might be able to get both levels of functionality
without any changes.

	Noel

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Aug 2003 19:09:53 +0200

On donderdag, aug 7, 2003, at 18:03 Europe/Amsterdam, J. Noel Chiappa 
wrote:

> Looking at all that, it seems to me, from an architectural point of 
> view, to be wiser to put it somewhat lower down in the stack. YMMV if 
> you take other considerations more highly.

I don't see how we could put the necessary information anywhere but in 
IP options/extension headers, if only because the TCP option space is 
too cramped and most other transport protocols don't have options at 
all.

On the other hand, TCP knows what's happening end-to-end.

So we probably want impementations to blur the layer boundaries a bit 
to take advantage of the opportunities at both the network and 
transport layers.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 07 Aug 2003 10:46:31 -0700

Noel and all,

How ought we (if at all) deal with the notion of a virtual end point 
such as a "content routed" service like CNN?  Particularly in the face 
of mobile nodes.  If we deal with it at all we don't want TCP 
connections breaking, and yet one wants to find the closest server 
hosting this identity (whatever that means).  I raise this because one 
way of looking at the answer would be to simply have a server appear 
with multiple agencies in the routing system.  That's inelegant and 
expensive.  DNS and anycast is incomplete due to mobility.

If CNN doesn't do it for you, think some sort of media gateway service 
(a 'la your long distance company or Vonage or some such).

Regards,

Eliot

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 7 Aug 2003 20:36:44 +0200

> Actually, if you reuse MIPv6 mechanisms to handle the 
> "existing TCP connections" case, you might be able to get 
> both levels of functionality without any changes.

Well this is not completelly accurate, according to my analysis, you
need to make some minnor changes (in the CN too), in order to preserve
the RR working.(i would like to be convinced otherwise)
Another issue is that the only solution that i could find to this relies
on icmp messages, which i am not sure that's acceptable.

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Aug 2003 22:40:37 +0200

On donderdag, aug 7, 2003, at 19:46 Europe/Amsterdam, Eliot Lear wrote:

> such as a "content routed" service like CNN?

First of all: is there a pressing need to do this below the application 
layer in the first place??? I know vendors make good money selling 
"layer 7 switches" but this looks an awful lot like asking for trouble 
to me. ("No, we can't IPv6-enable our website, the load balancers don't 
support it.")

If we want to, it should be possible to go from a single very high 
level identifier to one of several possible lower level identifiers 
(where we select the "best" lower level identifier, such as the closest 
or least busy one) and then to several locators for this lower level 
identifier.

To do this well we very likely need some kind of negotiation mechanism 
here, but this is something I haven't been able to convince everyone 
else we need yet.  :-)

> Particularly in the face of mobile nodes.

I guess that if you want to be really cool you should jump end-hosts in 
mid session if your idea of "best" changes... This would entail 
stopping whatever is happening, connecting to a new endpoint and 
starting the communication at a specific point. I guess this could work 
for things like file transfer and streaming, but hard to make it work 
without involving the app.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 07 Aug 2003 18:09:13 -0700

Iljitsch van Beijnum wrote:

> layer in the first place???

It's already done below the application layer in many cases, 
particularly when trying to determine the "closest" data center.  All 
I'm asking really is that we consider all the knobs that exist today, 
across a broad set of areas, when looking at architectural choices.  I'm 
not asking anything more specific.

Do I need to explain why I think this is related or is that glaringly 
obvious?

Eliot