On Tue, 16 Aug 2005, Alan Barrett wrote:
> On Tue, 16 Aug 2005, Dean Anderson wrote:
> > the current draft doesn't even contain the word 'balancing' or
> > 'balance' except to talk about the balancing of load between
> > anycast nodes. It doesn't address AT ALL the impact of fine grained
> > load balancing of packets on routers, an issue that seems pretty
> > well-suited to GROW.
>
> I believe that the above part of Dean's criticism is valid, and I think
> that it would be worthwhile for a section on per-packet load balancing
> to be added to the draft. This section could point out the places where
> PPLB is or is not likely to interact badly with anycast services that
> require multiple packets. For example:
>
> per-packet load balancing across multiple parallel links between the
> same pair of routers is almost always safe;
>
> per-packet load balancing across diverse paths within your own AS,
> but where the paths converge before exiting your own AS, is likely to
> cause performance problems traceable to packet re-ordering, but these
> problems are unlikely to be any worse with anycast services than with
> non-anycast services;
>
> per-packet load balancing across links to different neighbouring
> ASes (such as different upstream providers) may cause serious
> problems with anycast services that are implemented according to the
> suggestions in this draft, because the different links might lead to
> different instances of the anycast service;
Exactly right. However, these situations are not always explicitly
chosen. For example, Av8 Internet offers redundant service connections
via T1 and DSL. The T1 and DSL services are handled at different sites,
and outgoing packets from those sites will be sent through different
upstreams. If customers turn on fine-grained load balancing at their CPE,
we have no knowledge, nor any control over this. Customers are _very_
interested in having this ability. Nearly every customer wants to do load
balancing. We also use equal cost static egress routes on our interior
multiply connected routers, load balancing our exiting packets to the
several upstreams. This is coarsely balanced with flow caches (mostly
Cisco 7500 and 3600 series equipment). To enable fine grained load
balancing, one just configures the flow cache off. Newer routers don't
have flow caches, I don't know how they keep flows together, or if they
do.
Further, as pointed out, in principle, fine grained load balancing may
occur for reasons other than by explicit configuration goal: Simply
because there are no flow-tracking structures in the router to enforce
flow-based routing. For example, the Cisco GSR has no route/flow
cache--but I don't know what its load balancing behavior is. I know of no
IETF document that prohibits fine grained load balancing. Just the
opposite: RFC1546 (at least) indicates that you must be prepared for the
case when two successive packets to the same source address follow
different paths.
But in principle, anyway, such a router starts fine grained load balancing
anytime it sees equal cost routes to the same destination. It doesn't
matter how those routes were entered into the routers route table. For
example, if such a router is used as a BGP core router, then anytime a
structure exists from two or more peer AS through to a single end AS, and
the BGP costs are equal, then fine grained load balancing would begin.
And for example, equal cost static routes would have the same effect. And
many sites use equal cost static default egress routes on their multiply
connected interior routers. This would have to change.
> I suggest that the draft could recommend "don't do the problematic types
> of load balancing", and could observe that hardly anybody does the
> problematic type of load balancing anyway. This is opposed to Dean's
> apparent preference for recommending "don't do anycast for services that
> use TCP".
There is only one problem with this (at least for services that have
global usage such as DNS Root Server services): such a declaration means
that you have imposed _on the entire Internet_ an additional requirement
that:
Any two successive packets MUST be delivered to the same host over
exactly the same path.
Practically, this means that all routers MUST have a flow cache or
equivalent mechanism. Or else not allow multiple routes to the same
destination prefix in the route table. I think this is a rather draconian
demand on the entire Internet.
Making this demand on explicitly cooperating ASs might be more reasonable.
However, in that case, I suggest that, at minimum, the draft has to
indicate that this extension can ONLY be used for those protocols that use
TCP and Large UDP and fragments where use is LIMITED to use exclusively
within the explicitly cooperating AS's, and that those AS' have verified
that they don't have any possibility for fine grained load balancing over
diverse paths. In other words, this extension can't be used for globally
used Root DNS services.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive: http://darkwing.uoregon.edu/~llynch/grow/
