Re: Draft of updated WG charter

[Jay Ford <jay-ford@uiowa.edu>]

On Fri, 9 Jan 2004, Noel Chiappa wrote:
>     > 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.

I'm not sure I accept the analogy:
   o  IP source address selection... is a layer lower than TCP, so you're
      making the host responsible for more detailed network functionality
   o  TCP congestion avoidance is end-to-end, so the end systems should be
      involved; address & path selection are single-end or per-hop, so
      shouldn't necessarily require end system intelligence

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

Path selection is only part of the multi-homing problem, & perhaps the easier
one.  In my realm of experience, most end systems have only a single path
out, so there is no path selection required.

The nastier problem is source & destination address selection.  In the case
of multiple addresses per host, the host is forced to make the selection but
the implications have to be handled in the rest of the network (anti-spoof
filtering, routing policy...).

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

You lost me there, but then, I've never been to Rome.  ;^)

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

Bummer.

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

I like the "connectivity-dependent" term.

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

See end-to-end & layer comments above.

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

As I said, I don't think path selection is a big issue for the end systems.
It's address selection, which doesn't exist for most end systems for IPv4.
It's a new thing which IPv6 brings which the end systems are not up to
dealing with in a sustainable way.

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

Yeah, I figured I'd get that answer.  IPv4 works for my net, though, & it's a
bit more complicated than a dial phone.

I'm not claiming that end systems should be completely stupid & the network
should do everything.  We might just disagree on where the functionality
dividing line should be.  I think address selection & path selection
shouldn't be on the end system side of the line, so an architecture which
causes every end system in every multi-homed network to do those jobs seems
broken to me.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951