[EMAIL PROTECTED] wrote:
>
> Margaret,
>
> The flow label specification should define the default usage of the flow label, and
>allow for future specification of more specific usages. IPv6 WG needs to reach
>consensus on the default usage, document that in the flow label specification, and
>not set any unnecessary or ideological restrictions on the usages to be defined later.
>
> Enabling usage for "load balancing" is within default usage of the current draft. I
>think we need now have a discussion on what exactly this means for the spec.
[BC] IMHO, nothing. The spec as written allows load balancing.
>
> You wrote:
> > Load balancing routers want to make balancing decisions based on the
> > value of the flow label field, with no other signaling required. A
> > very simple mechanism (such as hashing the flow label field) will
>
> Does "load balancing" here mean selection of one of the parallel paths (with the
>same metric), or selection of one of parallel links to the next hop?
>
> In any case the source and destination addresses should be included in the hash.
>
> IMO the address fields alone would be enough for "core" routers, where it is
>unlikely that a single host pair can dominate the traffic.
[BC] Probably, but near the source or destination this is not necessarily
true. In a non-diffserv, non-intserv scenario, using the triplet
{source, dest, flow label} to split the traffic could be interesting.
> > allow load balancing routers to consistently send packets from a
> > single flow over the same path. This offers a couple of big
> > advantages:
> >
> > - It reduces packet reordering, potentially resulting in
> > significant performance increases.
>
> We need to understand how significant issue this is.
[BC] In terms of TCP performance, it is highly significant; anecdotally
at least a 50% throughput hit for systematic reordering.
>
> First, this may be an performance issue for the final destination only, as routers
>do not reassemble flows.
[BC] Yes, but it's the e2e throughput that matters.
>
> If the selection of the path can have a significant effect on the overall packet
>delivery time, the load balancing decision should not be based on a blind flow
>identity only.
>
> IP has never promised to not reorder packets. I do not think we need to build in any
>guarantees now either.
[BC] No guarantees, but we need to do our best. However, it's irrelevant to
the flow label draft.
>
> So, exactly when could we expect to get significant performance increases?
>
> > - It makes the PMTU mechanism work better, since packets
> > for a single connection will take a consistent
> > path.
> >
>
> In practice, is or will path load balancing be made over paths where the PMTU is
>different among the parallel paths?
[BC] Who knows?
>
> Is it forbidden for e.g. TCP to share PMTU information between different
>connections, if those connections are between same addresses?
[BC] It may not be forbidden, but it sounds very dangerous to me.
>
> > But, for this simple mechanism to work, load balancing routers have to
> > be able to rely on the fact that the flow label will label a _flow_
> > (one direction of a TCP, UDP or SCTP connection).
> >
>
> Also this is an issue to be discussed. For the load balancing to be effective, the
>bandwidth of the identified (and "balanced") unit should be of small enough portion
>of link/path capacity. There is no guarantee that a single TCP connection is "low
>bandwidth" compared to some other aggregate of packets between a pair of addresses.
>On the contrary, TCP tries to adapt to the path and get the maximum throughput (e.g.
>for a file transfer).
>
> It seems that if a given TCP connection is consistently mapped to the same flow
>identity, the simple path load balancing will work the same regardless the
>granularity of the aggregate from the source host. But note that a Flow Label alone
>does NOT identify the flow, you need to consider the source and destination addresses
>also (which is also very clearly spelled out in the current draft :-)
[BC] This argument is beside the point, which is getting the flow label
draft finished. Since the draft allows load balancing as Margaret
described it to co-exist with other usage, this WG simply shouldn't care.
Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
