RE: Fwd: Minutes / Notes

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

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

    >> If you have two separate multi-homing mechanisms, then the cost, in
    >> system complexity, implementation size, amount of protocol
    >> specification work needed, etc, etc just seems to me out of all
    >> proportion to the benefit. .. Pick one.

    > Frankly, I am not sure about the "pick one". It supposes that we know
    > exactly what we want to design, and that we can commit to one right
    > now.

That's the job of an architect - to see things at a deeper level than just
today's requirements, to see past them to the fundamental basics and create
structures with lasting utility.

    > a fundamental design choice) is the layer at which identifiers are
    > maintain. Is it IP, transport or session? .. It is very unclear to me
    > that IP would in fact be the right layer for the job.

This is an interesting point, because I've often thought that with a blank
slate, perhaps a better allocation of mechanism to layers of functional
abstraction might be possible. E.g. when I think about maintaining a
connection to something like a pool of servers, you might move functions
around to different layers.

However, we have to live with the system we've got, and it still seems to me
that as long as we have an end-end reliable stream level which is fairly
ubiquitous (i.e. TCP), and we have the routing architecture we've got, and we
want the system overall to have certain capabilities (e.g. mobility, switching
to a different multi-homed inbound link), then that layer needs names for the
entities.


    > Another quite important design choice is the scope of the identifier.
    > .. The scope of an identifier system, by definition, has to be wider.
    > Yet, we don't really know how wide. Is it a host? .. Consider clusters
    > on one hand, multi-user systems on the other. Would you have an
    > identifier per node in the cluster, or one per user in a multi-user
    > system? What about process mobility?

One of the fundamental concepts of the end-end reliable stream layer is the
notion of fate-sharing. So I have said, for many years now, that the thing
that needs to be named by an end-end RSL name is a fate-sharing region.

E.g. if you have two machines in a pool, and one is (temporarily) handling a
TCP connection, and the other doesn't have all the latest TCP state
information to take over the connection if the first one fails, then the two
are not a fate-sharing region, and cannot share an end-end RSL name.


    > I heard many say during the multi6 debate that applications cannot
    > possibly handle multiple addresses well. To disprove that, I suggest
    > you take a look at the variations of "swarmcast" implemented by P2P
    > systems .. Such a system would handle multi-addressing beautifully.

By definition, if we do multi-homing with multiple addresses, *something* is
going to have to handle multiple addresses. It may be the application (some
will no doubt care), it may be some other layer.

But you only have a need for a separate name for the end-end entity *if you
wish to provide certain functionalities*, e.g. mobility, or multi-homing, or
anything that (in general) requires the ability to switch to a different
address while the connection to that end-end entity is active. (And don't
forget, a set of addresses is an end-end name, too... viz SCTP.)


    > But my real point when bringing up the P2P example is that innovation
    > happens. .. Office automation systems use transaction processing. The
    > list goes on. What we are observing is a distributed innovation process
    > arbitraged by the market place. I trust that much more than a
    > identifier/location split designed by committee.

Yes, and they all are working within an architectural framework that was
thought out in advance to provide the kind of flexibility needed to do this,
by providing certain key fundamentals, and leaving the rest open.

What we need to do here is identify the key architectural fundamentals, and
provide them.

	Noel