Subject: Re: Draft of updated WG charter

From: [email-masked] (Noel Chiappa)
Date: Fri, 9 Jan 2004 16:43:20 -0500 (EST)

> From: Jay Ford <[email-masked]>

    > 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

---

From: Jay Ford <[email-masked]>
Date: Fri, 9 Jan 2004 16:30:31 -0600 (CST)

> trust me, congestion avoidance is a much more complex technical problem than

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

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

> you have to start somewhere.

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

> captures the rough consensus worked out on this WG mailing list a long time

Bummer.

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

> Clearly, it doesn't, so there's something wrong with it.

See end-to-end & layer comments above.

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

> 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: [email-masked], phone: 319-335-5555, fax: 319-335-2951

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 10 Jan 2004 00:46:53 +0100

On 9-jan-04, at 23:30, Jay Ford wrote:

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

> filtering, routing policy...).

I'm not sure what you mean by "path" if you say that a host only has 
one. I think for the purpose of discussing multiaddress multihoming, a 
good definition of a path would be a combination of source and 
destination addresses.

The good part is that as soon as we implement mechanisms that allow 
transport sessions to jump addresses, the address selection problem 
isn't really a huge deal anymore: if you find yourself using 
unfortunate addresses, you simply jump to something more suitable.

> causes every end system in every multi-homed network to do those jobs 

So what about having special boxes that sit between the hosts and the 
routers and handle multihoming? Obviously anything that can be 
implemented in an external box can also be integrated into a host when 
desired, so unless the drawbacks of allowing this functionality to be 
implemented in an external box are huge, this shouldn't take anything 
away from the people who actually like their hosts to handle this 
autonomously.

---

From: Jay Ford <[email-masked]>
Date: Fri, 9 Jan 2004 23:39:19 -0600 (CST)

On Sat, 10 Jan 2004, Iljitsch van Beijnum wrote:
> > 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...).
>

From the host perspective, I mean "next hop", which is usually a single
router to which all packets get sent.  I shudder at the notion of host
address selection dictating an end-to-end path.

> unfortunate addresses, you simply jump to something more suitable.

More shuddering...

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

That sounds dangerously close to NAT, which I think most people would like to
avoid & eradicate.

For me, almost the entire IPv6 thing boils down to the issue of hosts having
multiple addresses.  That decision precipitated the rest of this mess.