Fernando,
On 11/9/2010 12:55 AM, Fernando Gont wrote:
The text you quoted says "[counter] is initialized to some arbitrary
value, and is incremented once for each flow label value that is
selected.". That means that right after a "Flow Label" is selected
for each of your dozen flows, "counter" will be incremented.
FWIW, "protocol" doesn't matter -- the "Flow Label" needs to be
unique on a (src IP, dst IP basis).
But, this *reduces* the amount of entropy I get today by looking at the
whole 5-tuple. And, it means that I can't just use the 3-tuple of
{src_ip, dst_ip, flow_label} as input-keys for LAG/ECMP. Specifically,
at time t1 if I have two flows that start up between the same 2-tuple:
1) FTP: 9 Gbps
2) WWW: 9 Gbps
... both of the above flows will have identical {src_ip, dst_ip,
flow-label}. When they arrive at my router, if that 3-tuple are the
only input keys they *will* end up on the same 10 Gbps component-link in
a LAG and result in congestion of that component-link.
OTOH, if you're proposed algorithm said that 'counter' was incremented
once when the FTP flow was started and incremented a second time when
the WWW flow was started (or, a similar mechanism), then that would
provide unique flow-label values for the two flows and, consequently, a
unique 3-tuple of {src_ip, dst_ip, flow_label} to be used by
intermediate routers. As a result there is a high probability that
intermediate routers would hash them onto different component-links in a
LAG/ECMP and there is little risk of congestion.
-shane
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
