Subject: grow: draft-ietf-grow-anycast-03

From: Joe Abley <[email-masked]>
Date: Wed, 19 Oct 2005 14:03:55 -0400

Hi,

I just submitted the attached document; it should appear in the usual  
repository in due course.

The principal changes are in section 4.4.3, the full content of which  
can be found below; the rest of the document is substantially unchanged.

Feedback would be gratefully received.

Joe

4.4.3  Equal-Cost Paths

    Some routing systems support equal-cost paths to the same
    destination.  Where multiple, equal-cost paths exist and lead to
    different anycast nodes, there is a risk that different request
    packets associated with a single transaction might be delivered to
    more than one node.  Services provided over TCP [RFC0793]  
necessarily
    involve transactions with multiple request packets, due to the TCP
    setup handshake.

    For services which are distributed across the global Internet using
    BGP, equal-cost paths are normally not a consideration: BGP's exit
    selection algorithm usually selects a single, consistent exit for a
    single destination regardless of whether multiple candidate paths
    exist.  Implementations of BGP exist that support multi-path exit
    selection, however.

    Equal cost paths are commonly supported in IGPs.  Multi-node
    selection for a single transaction can be avoided in most cases by
    careful consideration of IGP link metrics, or by applying equal-cost
    multi-path (ECMP) selection algorithms which cause a single node to
    be selected for a single multi-packet transaction.  For an  
example of
    the use of hash-based ECMP selection in anycast service  
distribution,
    see [ISC-TN-2004-1].

    Other ECMP selection algorithms are commonly available, including
    those in which packets from the same flow are not guaranteed to be
    routed towards the same destination.  ECMP algorithms which select a
    route on a per-packet basis rather than per-flow are commonly
    referred to as performing "Per Packet Load Balancing" (PPLB).

    With respect to anycast service distribution, some uses of PPLB may
    cause different packets from a single multi-packet transaction sent
    by a client to be delivered to different anycast nodes, effectively
    making the anycast service unavailable.  Whether this affects
    specific anycast services will depend on how and where anycast nodes
    are deployed within the routing system, and on where the PPLB is
    being performed:

    1.  PPLB across multiple, parallel links between the same pair of
        routers should cause no node selection problems;

    2.  PPLB across diverse paths within a single autonomous system  
(AS),
        where the paths converge to a single exit as they leave the AS,
        should cause no node selection problems;

    3.  PPLB across links to different neighbour ASes where where the
        neighbour ASes have selected different nodes for a particular
        anycast destination will, in general, cause request packets  
to be
        distributed across multiple anycast nodes.  This will have the
        effect that the anycast service is unavailable to clients
        downstream of the router performing PPLB.

    The uses of PPLB which have the potential to interact badly with
    anycast service distribution can also cause persistent packet
    reordering.  A network path that persistently reorders segments will
    degrade the performance of traffic carried by TCP [Allman2000].   
TCP,
    according to several documented measurements, accounts for the bulk
    of traffic carried on the Internet ([McCreary2000], [Fomenkov2004]).
    Consequently, in many cases it is reasonable to consider networks
    making such use of PPLB to be pathological.

---

From: Joe Abley <[email-masked]>
Date: Fri, 21 Oct 2005 09:52:36 -0400

On 19-Oct-2005, at 14:03, Joe Abley wrote:

> I just submitted the attached document; it should appear in the  
> usual repository in due course.
>
> The principal changes are in section 4.4.3, the full content of  
> which can be found below; the rest of the document is substantially  
> unchanged.
>

Turns out I was confused. -02 was never submitted, and so the  
document I attached a couple of days ago (named -03) was correctly  
sent back for edits.

I have made those changes, and the revised -02 draft I just submitted  
is attached. The text below is still the only substantial change  
since the last document discussed in this mailing list.

Joe

---

From: Alan Barrett <[email-masked]>
Date: Sun, 23 Oct 2005 14:16:24 +0200

> >Feedback would be gratefully received.

The new section 4.4.3 addresses all my concerns.

--apb (Alan Barrett)
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/