Margaret, This is old ground and I thought we had got past this two metings ago.
Margaret Wasserman wrote: > > Hi Brian, > > >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. > > 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. I didn't say "compatible." I said "co-exist," which is quite different. > > 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). 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.) > > 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? 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. > > 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. 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 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
