Just to be crystal clear:
Fernando's algorithm is strictly compatible with RFC3697 and with the future
RFC3697bis (based on today's WG discussion). But it is compatible
with a policy that says "all simultaneous and overlapping
sessions between the same two IP addresses are treated as a single flow."
If you want to treat each new pair of sockets between those two
hosts as a separate flow, even when they overlap in time, you
need to include the whole 5-tuple. Or equivalently, generate a new
label with Fernando's algorithm each time there is a socket open() call.
If, in accordance with the draft we adopted today, the label is
created by a router, the only way to satisfy Shane's requirement
is to use the whole 5-tuple.
Regards
Brian Carpenter
On 2010-11-09 21:16, Shane Amante wrote:
> 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
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
