Subject: Re: Flow label draft issues & new text

From: Erik Nordmark <[email-masked]>
Date: Tue, 10 Sep 2002 01:14:21 +0200 (CEST)

> Well yes, although I've not been sure from the start of this discussion
> why that is any business of *this* working group. Worrying about that
> really belongs to whatever WG standardizes a specific use of the label.
> All we need to do, imho, is establish the appropriate boundary
> conditions, and that is what the current text aims to do.

I'd personally like to see this working group standardize a use of the flow
label where, in the absense of something else using the flow label,
every new TCP connection gets a new flow label value so that routers
can use the flow label (or a hash therof) to perform load spreading
without risk of reordering a TCP connection.

My hope was that the current draft was going to do that.
If the current draft merely states the constraints for other, future work
to define a use of the flow label, then I don't see it being useful
for the more immediate utility of the flow label.

Does the mean we need an additional, short and simple "using the flow label
for load balancing" draft?

  Erik

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Sep 2002 16:42:31 +0200

below...

> for load balancing" draft?

IMHO the reason for getting the current draft on the standards track is
precisely to allow a set of drafts on specific usage scenarios to appear.
The draft is intended to allow several *simultaneous* usage scenarios to
coexist. Yours is one of them. Diffserv is another. RSVP, and potentially
NSIS and the recent RSVP2 proposals are others.

  Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 10 Sep 2002 11:17:17 -0400

Hi Brian,

>NSIS and the recent RSVP2 proposals are others.

I don't believe the draft achieves this goal, and I don't personally 
believe that we should even be trying to achieve this goal.

No amount of hand-waving or careful wording will make the load 
balancing and diffserv uses of the flow label compatible with one 
another.  

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 
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.
        - It makes the PMTU mechanism work better, since packets
                for a single connection will take a consistent
                path.

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).

Your proposal says that, instead of containing a flow label, the flow
label field may be used to hold a diffserv traffic class, or some sort
of NSIS value, or other yet-to-be-defined values...

If this is the case, how are the load balancing routers supposed to know 
whether or not the flow label actually contains a flow label?

Certainly, we don't want load balancing routers performing their balancing
operations based upon the traffic class of each packet, or whatever values
have been inserted in the field by other, yet-to-be-defined mechanisms.

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Sep 2002 11:08:52 +0200

Margaret,

This is old ground and I thought we had got past this two metings ago.

> balancing and diffserv uses of the flow label compatible with one

I didn't say "compatible." I said "co-exist," which is quite
different.

> (one direction of a TCP, UDP or SCTP connection).

They have to be able to rely on the fact that the flow label will
label a collection of packets that the source has decided require the
same treatment. If a source *chooses* to label coarser aggregates
than a single transport connection with the same label, they will all
get the same treatment. If a source *chooses* to label individual
transport connections, they will get individual treatments. It's a tradeoff
that the source can make - if it doesn't want to benefit from the kind
of load balancing you describe, it won't. (The same argument exactly
applies to load balancing at a destination server farm.)
> whether or not the flow label actually contains a flow label?

They don't need to know. In fact, they are too dumb to know. If the flow label 
is coarse, they simply won't do fine grain load balancing for that packet.

> have been inserted in the field by other, yet-to-be-defined mechanisms.

No, the traffic class is used to drive differentiated service, not load 
balancing. But the flow label can be used to drive a diffserv (or intserv)
classifier, if that happens to be your scenario rather than load balancing.

To summarise: a source that chooses to use coarser flow labels deprives
itself of downstream load balancing, but gains in downstream service
differentiation. The draft is intended to allow that tradeoff rather
than force one choice or the other.

   Brian