Just for the record...
On 5 nov 2005, at 03.36, Joe Abley wrote:
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.
Agreed.
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".
Agreed.
[...] 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
Agreed. And at least to me "load-spltting" can be done in several
ways for various protocols and this is a protocol agnostic document
on how to do anycast...
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.
Agreed.
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.
Agreed.
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.
For Informational and non-normative documents you can AFAIK reference
anything you want. I am pretty sure I have seen ISBN numbers, web-
links, other SDO documents etc.
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.
Ok with me.
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.
Agree.
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.
I agree with Joe. Load-splitting is to me something completely
different than PPLB.
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.
Agreed.
- kurtis -
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive: http://darkwing.uoregon.edu/~llynch/grow/
