Le 10 août 2010 à 21:06, Fred Baker a écrit : > 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. Packets that are expected to go down multiple paths should be identified as belonging to different flows as far as FLs are concerned. In the case of multi-path TCP, where "one or both peers are expected to have multiple addresses", this is already the case: different paths are taken by packets of different MPTCP "subflows", i.e. packets having different 5-tuples. > > 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. Originators of TCP and UDP connections should clearly hash 5-tuples when they exist (not 2-tuples in this case as you seem to assume). > The important thing is that things are tagged in a manner that helps the load > balancer. Agreed. > 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. "Hash something" (and possibly a 2-tuple even when a 5-tuple is available) is clearly not as good as "hash 5 tuples if available", which I propose to become a SHOULD. Taking a "good start" as starting point, and trying to improve from there, is what I try to propose. > 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. Are you arguing in favor of NATs in IPv6, adding load balancing as a reason to use them :-(? As a convinced promoter of IPv6, and of its restored e2e transparency, I find that IPv6 load balancing solutions that don't need NATs are worth specifying. > And why they are looking for mutable flow labels in this thread. I don't see why 0-FL mutability wouldn't be sufficient for them (provided new values must statistically different for different flows, including subflows, micro-flows, whatever can be identified). But more data on what would be their problem are most welcome. Regards, RD > > 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 --------------------------------------------------------------------
