layering wrt hosts & routers (was: Draft of updated WG charter)

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

On Sat, 10 Jan 2004, Dave Crocker wrote:
> >  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.
>
> 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.

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.

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

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.

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

No argument there.

> >   The routing
> >  infrastructure should deal with most of the burden of getting packets to
> >  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.

OK.

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

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.

> > >  And what is the summary description of the intelligence currently
> > >  required for  v4 multihoming?
> >
> >  In the common case where the site (not the host) is multi-homed, the host
> >  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.)

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

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

Very good points.

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

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

> > >  And requiring the infrastructure to change before a function is useful
> > >  tends to  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.
>
> 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.

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.

> > >  Hmmm.  Simple end system components, complex network components.
> > >
> > >  Isn't that the phone system approach, and rather pointedly divergent
> > >  from the 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.
>
> 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.

OK.  Let's see where this leads.

Jay