Re: Draft of updated WG charter

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Jay Ford <jay-ford@uiowa.edu>

    > I'll go further out on that limb & say that any multi-homing solution
    > which requires substantially more intelligence in end systems than is
    > currently required for multi-homed IPv4 is bound to fail ..

I've heard this argument before, and I'm sorry but it's totally incorrect.

If your basic concept (smart network, stupid endsystems) was true, we'd never
have made the jump from NCP to TCP - because in that jump, congestion
avoidance functionality was moved from the network to the end-systems - and
trust me, congestion avoidance is a much more complex technical problem than
path selection.

Heck, every day a large cross-section of average humans tackle complex path
selection problems - to get to work. And I'll remind you that half the
population has an IQ of less than 100...

Picking an end-system address is a troublesome problem for this WG only
because the architectural environment in which it is currently operating is
so impoverished. IPv4, for understandable reasons, started out with a
extremely cartoonish routing architecture, one totally unsuited to use in a
global uniqiuitous network. IPv6, for reasons which pass my understanding,
elected not to tackle this problem. However, Rome wasn't built in a day, and
you have to start somewhere.


    > This is really the heart of the IPv6 scalability issue. I've never
    > understood the argument that multi-homing for IPv6 ought not be done
    > the way it's done for IPv4 (single address per end system, multi-path
    > routing) on the basis that the network can't tolerate the increase in
    > routing table size/complexity.

This argument is done and over with. The proposed WG charter correctly
captures the rough consensus worked out on this WG mailing list a long time
ago.

Also, if you think about it a little bit, this is exactly the same issue as
"why do people have to have connectivity-dependant addresses". [The
politically-focussed continue to call them "provider dependent", but I prefer
to use a term which bring the underlying technical point to the fore.] And the
viewpoint which preferred user ease over routing viability lost that one too.


    > My objection is that the alternative (shoving the complexity to the end
    > systems) is much worse because:
    > as evidenced by worm attacks..., the end systems are the worst managed
    > pieces in the whole puzzle run by users who don't (& I'd say shouldn't
    > be expected to) understand the workings of the network;  predicating
    > routing-type functionality on that platform is asking for trouble

See comments above. Also, DoS attacks are causing problems for end-system
based congestion control, but we're not proposing getting rid of end-system
based congestion control because of it.

    > there are at least 3 (4? 5?) orders of magnitude more end systems than
    > there are routers, so embedding significant pieces of networking
    > functionality in end systems greatly increases the likelihood of
    > trouble & even more greatly decreases the chance of consistent
    > operation over time

If this argument was valid, it would equally apply to congestion control.
Clearly, it doesn't, so there's something wrong with it.


    > Consider the current difficulty in deploying changes to other
    > technologies due to system-level inertia ... Moving routing-type burden
    > to the end systems creates such inertia for basic packet delivery,
    > making the network as a whole even less upgradable than it is now.

On the contrary - if we had a decent routing architecture, one in which path
selection had been moved into the end-systems (which I concede we don't,
efforts to the contrary over the last 15 years notwithstanding) *as it ought
to be*, a lot of routing functionality problems we are suffering with would be
far easier to solve *because we'd have a lot more flexibility, and the ability
to easily upgrade path selection algorithms*.

Path selection is basically *not* upgradeable *at all* at the moment precisely
*because* the current system does centralize it in the routers.


    > I advocate keeping the end systems as simple as possible & dealing with
    > the routing support required to make multi-homing work close to the way
    > it works for IPv4.

Lots of people would disagree with your claim that it "works" in IPv4. And as
for simplicity, you can maximize simplicity by using a dial phone.

	Noel