[e2e] e2e principle..where??....

[J. Noel Chiappa]

    > From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>

    > putting source routing into the end system requires end systems to
    > build topology maps

Not necessarily (in terms of actual engineering, as opposed to basic
architecture - not sure which you're speaking of here). You could build a
system in which end-systems have the abilty to create paths of their own,
but most systems don't bother, and get them from path servers.

    > this .. does reduce the responsiveness since you ONLY get to react
    > edge-to-edge to local outages instead of having local recovery

Not so. People have designed explicit-routing systems which allowed local
repair. The trick is to have intermediate entities advertise higher-level
topology abstractions. If one component which is being used to provide
that abstraction fails, as long as the entity can reconstitute an
equivalent "implementation" of the abstraction from other resources,
nobody needs to know. The process can recurse, of course.

    > having the ability to put route _hints_ into packets would be very
    > fine if ... we had a mechanism to do it without burdening everyone
    > with hint processing...

TANSTAAFL. If your system is already meeting de Exupery's Law ("Perfection
is attained, not when there is nothing left to add, but when there is
nothing left to take away."), then you don't get better funtionality with
equivalent/lower cost.

If you want stateless forwarding, and you want the user to have more
"control" over that forwarding (think more complex user-accessible
semantics), then you have to accept that the packet header (which are the
user's instructions to the network on what it wants done) is going to be
more complex too (to indicate what the user wants from those richer
semantics).

Of course, if it's a long-lived flow, you can move some of the information
into the switches - but let's not go down that rathole!

	Noel