I would find that surprising. There are ample cases where the originator of a high data rate flow (sensor data from a radio telescope to a number cruncher, to pick one example) might want to use the flow label to send data from one session down multiple paths. Multi-path TCP would be another example. I suppose you could argue that consistently alternating among N flow labels can be thought of as N separate flows, but if it's TCP there are other ramifications.
In any event, the requirement of the load balancer is not that the originator gives things a tag; we can develop such tags from a hash of the source and destination address quite well, thanks. The important thing is that things are tagged in a manner that helps the load balancer. There are two major uses of load balancers. In data centers, we balance sessions to/from sets of servers, and the question when a new session comes up is which server is most likely to be able to effectively serve it (has the necessary resources including access to the right disks, CPU cycles, etc). In bandwidth allocation uses (spreading load across multiple otherwise-equivalent paths), the question is how to use each of the paths most effectively - we want some traffic on each of them and we want none of the paths to be overloaded or introducing more delay or loss than others. Everyone's instinctive knee-jerk response to the question seems to be "hash something and depend on the law of large numbers to serve the need", and the observation of numerous operators is that the law of large numbers is a good start but is not an adequate solution. You really want the load balancer to be able to be smarter than that. Which is why people that build load balancers frequently do so using NAT technology or some other way of tagging individual sessions. And why they are looking for mutable flow labels in this thread. On Aug 10, 2010, at 9:09 AM, Michael Richardson wrote: > >>>>>> "Rémi" == Rémi Després <[email protected]> writes: > Rémi> RFC 3697 isn't concerned with ASes, and doesn't need to be. > Rémi> The proposal is only that, where load balancing is performed, > Rémi> 0 FLs MAY be replaced by meaningful values for this purpose. > Rémi> A FL, once set to a non 0 value, never needs to be reset. > > okay, so what you are saying is that load balancing uses of the FL are > only upset when they see zero. So for instance, if layer-4s (i.e. end > points) were mandated that they must now always set a FL consistently on > a flow, and set it to a non-zero value, that this would satisfy the > requirements of load balancers. > > In this context, permission would be given to set zero FL to a non-zero > value. > > -- > ] He who is tired of Weird Al is tired of life! | firewalls > [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] [email protected] http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE> > then sign the petition. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- http://www.ipinc.net/IPv4.GIF -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
