Hi Fernando,

On 11/9/2010 1:45 AM, Fernando Gont wrote:
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}.

No. "counter" will be different for each of the flows!

Please take a look at the table I referenced in my previous e-mail. It
clearly shows that in the scenario you're describing, the Flow Label
corresponding to each of the flows (FTP&  WWW) would be different.



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),

Yes. This is what the document proposes.


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.

This is exactly what this document is proposing. Is there any particular
wording that is causing confusion?

The part that is confusing to me is *when* does an implementation run your pseudocode to fetch a new flow-label value? If I look at the following pseudocode in the draft:
---snip---
        do {
            flowlabel = (offset + counter) % 1048576;
            counter++;

            if(three-tuple is unique)
                return flowlabel;

           count--;

        } while (count > 0);
---snip---
... the way I read the above, when it runs it /will/ return a unique 3-tuple of {src_ip, dst_ip, flow_label}. However, it's /not/ clear *when* an implementation MUST execute the above pseudocode.

Based on the following text:
---snip---
   Considering that the Flow Label is a 20-bit field, and that Flow
   Label values must be unique for each (Source Address, Destination
   Address) pair at any given time, it might make sense to simply
   randomize the Flow Label value for each new flow.
---snip---
... in particular, the part that says: "Flow Label values must be unique for each (Source Address, Destination Address) pair", implementations would most definitely would read that as saying they only need to execute your pseudocode when they detect the existence of a new {src_ip, dst_ip} tuple. IOW, they would /not/ run your pseudocode when the same {src_ip, dst_ip} tuple opens up several different sockets at the same time, where each socket connection would have a unique 5-tuple.

-shane
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to