>>>>> "Fred" == Fred Baker <f...@cisco.com> writes:
Fred> I would find that surprising. There are ample cases where the
Fred> originator of a high data rate flow (sensor data from a radio
Fred> telescope to a number cruncher, to pick one example) might
Fred> want to use the flow label to send data from one session down
Fred> multiple paths. Multi-path TCP would be another example. I
Fred> suppose you could argue that consistently alternating among N
Fred> flow labels can be thought of as N separate flows, but if it's
Fred> TCP there are other ramifications.
I did write:
>> 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.
I don't mean to say that the FL has to be a single value: I guess it
could be from a set of values if one wants to do multi-path.
Fred> In any event, the requirement of the load balancer is not that
Fred> the originator gives things a tag; we can develop such tags
Fred> from a hash of the source and destination address quite well,
Fred> thanks. The important thing is that things are tagged in a
Well... if FL is unique per sender's concept of flow, that's 128+20 bits
for the tcam vs 256+8+32 bits if you use the 5-tuple. (why use a tcam
for this... I don't know... there are no wildcard bits. A cam or
patricia-tree would be as good...)
Fred> manner that helps the load balancer. There are two major uses
Fred> of load balancers. In data centers, we balance sessions
Fred> to/from sets of servers, and the question when a new session
Fred> comes up is which server is most likely to be able to
Fred> effectively serve it (has the necessary resources including
Fred> access to the right disks, CPU cycles, etc). In bandwidth
Fred> allocation uses (spreading load across multiple
Fred> otherwise-equivalent paths), the question is how to use each
Fred> of the paths most effectively - we want some traffic on each
Fred> of them and we want none of the paths to be overloaded or
Fred> introducing more delay or loss than others. Everyone's
Fred> instinctive knee-jerk response to the question seems to be
Fred> "hash something and depend on the law of large numbers to
Fred> serve the need", and the observation of numerous operators is
Fred> that the law of large numbers is a good start but is not an
Fred> adequate solution. You really want the load balancer to be
Fred> able to be smarter than that.
Fred> Which is why people that build load balancers frequently do so
Fred> using NAT technology or some other way of tagging individual
Fred> sessions. And why they are looking for mutable flow labels in
Fred> this thread.
So, they want to mutate all flow labels, or just non-zero ones?
>>>>>>> "Rémi" == Rémi Després <remi.desp...@free.fr> 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.
mcr> okay, so what you are saying is that load balancing uses of the FL are
mcr> only upset when they see zero. So for instance, if layer-4s (i.e. end
mcr> points) were mandated that they must now always set a FL consistently
on
mcr> a flow, and set it to a non-zero value, that this would satisfy the
mcr> requirements of load balancers.
mcr>
mcr> In this context, permission would be given to set zero FL to a non-zero
mcr> value.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
