Hi Dean,
Thanks for the technical issues you raised. Comments below.
On 4-Nov-2005, at 19:40, Dean Anderson wrote:
First, the TCP performance issues listed at the very end also apply
to PPLB
(load splitting) over parallel links. For some reason, you don't
think this
makes PPLB over parallel links "pathological".
I don't have a good reference to cite, but it is my experience that
per-packet load balancing over parallel circuits leads to levels of
packet reordering which are low enough that serious TCP performance
degradation does not result. It may also be that the relative
adjacency of out-of-order segments (e.g. reliably within a window)
allows common TCP implementations to cope well, whereas topologies
which result in greater dispersion of segments cause the pipeline to
stall more frequently.
This would be an interesting subject for detailed examination. I
don't think this level of detail is required in the document at hand,
however, whose topic is differently-focussed.
Second, the TCP performance issue noted is minor, not severe.
I have operational experience of the case in hand, and I stand by my
description. Perhaps we differ in our interpretation of the word
"severe".
[...] Further, completely omitted is any mention of the
benefits of diverse load-splitting, which are substantial as
previously
explained.
Those are out-of-scope for this document, which aims to discuss
anycast service distribution, not per-packet load balancing.
Third, the use of Equal cost paths is not limited to BGP nor does
is it
dependent on BGP exit selection algorithm.
Indeed, the section on PPLB specifically does not refer to BGP.
Fourth, there seems to be an assumption that PPLB over diverse
paths is not
presently used in the Internet. This assumption is false.
There are examples of almost every kind of pathology deployed on the
Internet. This is a sufficiently well-known truism that I don't think
it needs to be spelt out.
Fifth, the references to an internal company specification, (ISC-
TN-2004-1)
should be removed.
ISC-TN-2004-1 is a public document published by ISC. Since it is
included as an informative (and not normative) reference, I don't
believe this presents any problems.
RFC2991 includes a list of methods to obtain course-grained
load-balancing. These methods are well understood by router
vendors, and rather
extraneous to the Anycast Extension with respect to fine-grained
load-splitting.
RFC 2991 describes equal-cost path selection algorithms which aim to
isolate packets associated with a single flow to a single next-hop.
These algorithms facilitate anycast distribution of TCP-based services.
I don't exactly understand what point you're making here, but I would
not object to the idea of including a reference to RFC 2991 to
strengthen the point that naive per-packet load balancing is poor
practice, and can be considered pathological.
Sixth, the notion of remote anycast "node selection" still
permeates the
document, (and the section below). These references should be removed.
The phrase "node selection" is intended in this document to indicate
a selected path through one or more interconnected routing systems to
a particular anycast node. It is certainly not a description of some
mechanism by which a client can select a particular node for service.
I think the document is quite clear on this point, but if you have
specific examples of ambiguous text I would be happy to review them.
Seventh, the "PPLB" terms should generally be replaced with the term
"load-splitting", which is the term used in RFC1812. The term
"PPLB" appears to
be Cisco-specific. RFC language should be vendor-neutral.
I do not believe that "PPLB" is a cisco term. The term "load-
splitting" is not an appropriate replacement for "PPLB" as used in
this document, since it is too general.
Eighth, by describing fine-grained load splitting as
"pathological", this draft
seems to update and alter RFC1812 without explicit discussion on
the merits of
that alteration.
The document does not describe fine-grained load splitting as
pathological; it describes specific topologies which are likely to
break TCP as pathological. This is an operational consideration.
[*] Not only is there no "node selection", it is not even possible
to know with
certainty what remote anycast node a packet sent by a source node will
ultimately arrive at, even without load-splitting.
Correct. I believe the document describes this quite clearly, but if
you care to illustrate specific text you find ambiguous, I would be
glad to review it.
Joe
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive: http://darkwing.uoregon.edu/~llynch/grow/
