Subject: Re: Draft of updated WG charter

From: Jay Ford <[email-masked]>
Date: Fri, 9 Jan 2004 14:35:20 -0600 (CST)

On Fri, 9 Jan 2004, vijay gill wrote:
> Routing update validation should be orthogonal to the multihoming
> solution.  Also, I am going out on a limb here and say that any
> m-homing solution that requires end-host updates is a non-starter
> from the get-go.

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, even if you somehow get it
deployed.

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.  My objection is that the alternative (shoving the
complexity to the end systems) is much worse because:
   o  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
   o  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

Consider the current difficulty in deploying changes to other technologies
due to system-level inertia (e.g., ASM->SSM for multicast).  Those are
relatively upper-level things which for the most part don't affect the basic
ability to get packets delivered.  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.

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.

________________________________________________________________________
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: Dave Crocker <[email-masked]>
Date: Fri, 9 Jan 2004 15:31:09 -0800

Jay,

>  required for multi-homed IPv4 is bound to fail, even if you somehow get it

These two forays into limb-walking seem important enough to warrant explicit 
descriptions of their baseline references.  If I missed these on the list, 
please point me to them.

For example, by "end host updates" do you mean that end hosts should hold no 
state about multihoming but that, instead, it must be done entirely in the 
routing infrastructure?

This is not a small point.  There is a line of thinking which suggests that the 
routing/router infrastructure should not be changed at all -- the basic packet 
transfer service works too well to mess up -- so that multihoming is strictly a 
value-added function done strictly in the end hosts. (Small concession:  
organization gateway routers, for site multihoming, are certainly distinct from 
end hosts, but they are also distinct from the general infrastructure.  Yet they 
are a good candidate for implementing multihoming.

And what is the summary description of the intelligence currently required for 
v4 multihoming?

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

Well, one argument is that it requires an entirely new type of addressing, since 
pure topology no longer dictates the address.  And that level of change to the 
infrastructure is one worth trying to avoid except under extreme duress.

>  My objection is that the alternative (shoving the

It depends on the nature and degree of the routing work done by the end host, 
and how much administration is required for it.

>  trouble 

And requiring the infrastructure to change before a function is useful tends to 
require 3 (4? 5?) orders of magnitude more delay.

>  routing support required to make multi-homing work close to the way it 

Hmmm.  Simple end system components, complex network components.  

Isn't that the phone system approach, and rather pointedly divergent from the 
historical Internet approach?

d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <http://brandenburg.com>

---

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

> state about multihoming but that, instead, it must be done entirely in the

Pretty much.  If hosts have a single address (as most do in IPv4), they don't
need to even know that they're multi-homed.

I view *sites* as multi-homed, not hosts.  Therefore, I view the problem of
how to make multi-homing work at the site (usually AS) boundary with other
entities (ASes), not how to make the individual hosts do it.

(Granted, some individual hosts are multi-homed, within a single site or even
among multiple sites, but I suspect that they are the exception & could be
handled as one-off cases.  Such hosts already have to be aware of networking
to choose the next IPv4 hop, so they could choose the next IPv6 hop in a
similar fashion.  Regardless, they are not the vast majority which are
single-homed within a single site.)

> are a good candidate for implementing multihoming.

I guess I'm closer to the other end of the spectrum.  The routing
infrastructure should deal with most of the burden of getting packets to
destinations as efficiently as possible.  The hosts shouldn't be expected to
do that job, because they are ill-equipped to do so.  They should focus on
layer 4 & up.

> And what is the summary description of the intelligence currently required for

In the common case where the site (not the host) is multi-homed, the host
needs to know very little.  It usually has a single source address & a single
next hop router to which it sends all packets.  The destination address is
chosen by some means (DNS...), but the host doesn't try to figure out which
destination address is "best".  It also doesn't have to choose a source
address because it has only 1.

> infrastructure is one worth trying to avoid except under extreme duress.

For many sites, topology doesn't dictate the address in IPv4.  I have 2 /16s
which I announce to those with whom I connect.  The topology is dictated by
the links & the routing announced on them, not by the numeric value of my
addresses.

I realize that cranking the dial up from 32 to 128 raises serious concerns
about the ability of the routing infrastructure to handle
non-connectivity-dependent or non-provider-based addressing.  However the
discussions I've seen about IPv6 address usage lead me to believe that there
won't be anywhere near 2^128 routed prefixes.  With common prefixes of /64 &
shorter for "sites" (university campus nets, corporate nets, ISP clouds...) &
the loss of a few "formatting" bits, we're probably talking 2^60 as an upper
bound.  I'm not saying that 2^60 isn't a huge number, but it's closer to
surmountable than 2^128, and with gradual roll out we probably wouldn't see
more than a small fraction of those for a long time.  I'd prefer to try to
tackle routing for 2^60 prefixes than to predicate the operation of the IPv6
Internet on how well hosts choose source/destination addresses => paths
through the network.

> and how much administration is required for it.

Based on what I've seen of how poorly hosts are defaulted & administered, any
increase in complexity & responsibility placed there is a bad thing.

> require 3 (4? 5?) orders of magnitude more delay.

Really?  It seems that I could upgrade my O(10) routers before any
significant fraction of the O(10k) hosts on my campus could get upgraded.

> historical Internet approach?

I think it depends on where you divide the responsibility.  My division is
that the complexity of layer 3 (IPv4 & IPv6) ought to be in the network, &
the complexity of layer 4 & up ought to be in the hosts.  Sliding that line
down to make the hosts responsible for layer 3 seems like a recipe for
disaster.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Jan 2004 12:02:18 -0800

Jay,

>  entities (ASes), not how to make the individual hosts do it.

Certainly your are right about the _placement_ of additional connectivity.  
However, this does not automatically mean that the mechanism to integrate _use_ 
of the alternative connections must be implemented at the site gateway.   Of 
course, we need to know the type of multiaddressing use that is desired, to be 
able to figure out the tradeoffs for where to place the mechanism.

In the most simple, failover use of multiple access links, the additional links 
would go unused.  To do any sort of load-balancing requires either blind 
round-robin or quite a bit of knowledge about the traffic flows. None of these 
choices strike me as a very good idea.

On the other hand, how will an endpoint know that it has multiple locators, if 
the attachments are at site gateways?  There needs to be a way to propagate the 
information back to the endpoints.

As tempting as it is to make the paradigm choice immediately, and based on one 
or another core principal, the existence of quite a few interestingly different, 
detailed proposals suggests that the choice is not at all obvious.  This is 
clearly something that has significant trade-offs in utility, design complexity 
and operations costs.

>   The routing
>  destinations as efficiently as possible.  

I completely agree.  It should deliver packets.  It does this quite well.  The 
effort to get it to that point of performance has been considerable.  For all 
that, the capabilities of the basic delivery service are pretty limited.  (QOS 
comes to mind as the major example of an enhancement that certainly cannot be 
done elsewhere in the architecture, and still has a long way to go.)

So I believe this means that focusing on the delivery of individual packets is 
what the infrastructure should do.  Integrating alternatives across a stream of 
packets should be done in endpoints or, perhaps, site gateways, so that the rest 
of the net infrastructure does not have to incur the cost of that integration.

It also happens that this permits treating mobility and multihoming together, 
with a single mechanism.

>  The hosts shouldn't be expected to

Oh.  So I guess we should not have hosts distinguish between the hosts on the 
local net versus remote destinations?  I suspect there are a few other functions 
we need to remove from the current Host IP layer.  Certainly IPsec needs to be 
deprecated.

In other words, perhaps this topic is a tad more complicated?

> >  And what is the summary description of the intelligence currently 
> >  required for  v4 multihoming?
>  
>  needs to know very little.  

OK.  Now I understand.  And there is no arguing that that sounds very appealing. 

There is one small problem.  You are talking about taking a model that has been 
worked on for what?  10 years?  Yet has gained virtually no adoption.  And let's 
impose that model on the future architecture?

(Sorry.  I know that's harsh, but this topic needs to take note of realities.)

>  won't be anywhere near 2^128 routed prefixes. 

The IETF has done an impressively bad job of predicting the future.  (To be 
fair, so has pretty much everyone else.)  

For example, note that during the CIDR work, efforts to predict when we would 
reach a serious crunch on IP Address allocation were confidently offered as 
being roughly around the year 2020, or maybe 2015.  At any rate they also 
completely dismissed all concerns about the effect of multihoming on the routing 
tables, because it was not particularly popular at the time.  Tony chaired the 
CIDR Deployment wg and might remember these discussions.

So a different view of your prediction is that you want to rely on a theoretical 
prediction to ensure the safety of what is probably the most critical, most 
fragile and most problematic architectural component of the Internet.  

I'd rather not do that.

> >  It depends on the nature and degree of the routing work done by the end 
> >  host, and how much administration is required for it.
>  
>  Based on what I've seen of how poorly hosts are defaulted & administered, 
>  any increase in complexity & responsibility placed there is a bad thing.

As correct as your assessment of the history, it leads to the thinking that says 
a salesman's (or customer service representative's) job would be far easier if 
it weren't for those pesky customers.  Besides, the history of the 
infrastructure has had its own downsides.

> >  And requiring the infrastructure to change before a function is useful 
> >  tends to  require 3 (4? 5?) orders of magnitude more delay.
>  

Ahh.  This probably gets to the nugget of the difference in perspective. 

You said "my".  However a change to the infrastructure requires coordinated 
effort by lots of independent "my"s.  Adoption of features that have multi-hop 
dependencies across independent administrations has proved to have a rather high 
latency before reaching a critical mass of utility.

> >  Isn't that the phone system approach, and rather pointedly divergent 
> >  from the historical Internet approach?
>  
>  the complexity of layer 4 & up ought to be in the hosts.  

Too late.  Host Layer 3 already has some pretty interesting complexity.

However it happens that my personal view is towards agreeing with you, somewhat. 
The difference is that I believe we are creating other need for a layer between 
3 and 4, which I'm tending to call Endpoint IP, distinct from Relay IP.  

This is a generalization of the shim/wedge model that some multiaddressing 
proposals are pursuing.

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jan 2004 15:19:35 +0100

This was discussed during the work on RFC 3582 and our goal in this
area is stated in that RFC. Please do not re-open old debates; we are
trying to make progress, not repeat previous work.

  Brian
  co-chair

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Jay Ford <[email-masked]>
Date: Sun, 11 Jan 2004 13:01:00 -0600 (CST)

> choices strike me as a very good idea.

There is another type of load balancing which occurs.  c a large variety of
(src,dst) tuples results in traffic for some of these interactions traversing
some links & traffic for others traversing other links.  For some routing
arrangements, this results in balancing of the load, although perhaps with
less determinism than some would like.

> information back to the endpoints.

I think a similar question arises for host-based address/path selection.
That is, how will hosts know how to intelligently choose among the matrix of
(src,dst) tuples it has?  I've read some of the work on that topic, but it
seems that more effort is required to get a sustainable solution.  Clearly,
that's one of the major points of this WG.

> clearly something that has significant trade-offs in utility, design complexity

No argument there.

> It also happens that this permits treating mobility and multihoming together,

OK.

> we need to remove from the current Host IP layer.  Certainly IPsec needs to be

OK, I made a (slight ;^) over-generalization.  Obviously hosts have a layer-3
implementation.  I'm just questioning whether the host should have full
Internet-scope responsibility as opposed to mainly first-hop responsibility.
But as I said in another note a few minutes ago, I'm prepared to go forward
on the former premise & see where it leads.

> In other words, perhaps this topic is a tad more complicated?

Indeed.  If I didn't think it was complicated I wouldn't be concerned about
implementing it in hosts.

> (Sorry.  I know that's harsh, but this topic needs to take note of realities.)

It's realities which cause me to question the viability of host-based
multi-homing, but, onward...

> fragile and most problematic architectural component of the Internet.

Very good points.

> infrastructure has had its own downsides.

The local version is that it would be a lot easier to run things around here
(at the university) without all those pesky students.  ;^)

> latency before reaching a critical mass of utility.

True, but the interaction & interdependency chain of the n router sets
(something like O(10^^n)?) seems easier to deal with than that for the host
sets (O(10k^^n)?).  My orders are probably bogus, but you get the idea.

> This is a generalization of the shim/wedge model that some multiaddressing

OK.  Let's see where this leads.

Jay

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 12 Jan 2004 10:13:36 +0100

> that's one of the major points of this WG.

Be careful here. Most (many) of the proposals around id/loc separation 
introduces a shim layer. For the ULPs there is still the possibility 
for a address-selection problem, but that is not different from what we 
already have and that problem does not really belong here. That issue 
has been beaten to death in the scoping discussions. As for how a 
"locator" is chosen, and verified to be working - that is what this 
entire WG is here for. But I would not call that address selection (for 
the risk of confusion). And how that is handled, is for each proposal 
to come up with.

There are proposals that work differently as well.

- - kurtis -