RE: Consensus on identifier/locator split?

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: "Christian Huitema" <huitema@windows.microsoft.com>

    >> 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