Re: ECMP and flow label

[Brian E Carpenter <brian.e.carpenter at gmail.com>]

Gorry,

On 2009-11-11 02:42, Gorry Fairhurst wrote:
> Brian,
> 
> I agree the draft should be updated on this point (and will reference
> RFC 3997).
> 
> I have two comments/questions:
> 
> 1) The draft speaks about tunnel encapsulations, and therefore, the
> intention (as I recall - others please do chime in) was that a tunnel
> ingress performing encapsulating could use a non-zero FL (as you note to
> be COMBINED (hashed) with the address information, etc), to assist the
> network in directing the encpasulated packet/datagram to the correct
> tunnel egress/destination - i.e. load balancing?  I'm looking for good
> text.

I was talking off-line with Joel Halpern, and I think we concluded that
the issue is general enough that it may even need a small draft of its
own. No promises, but watch this space.

> 
> 2) IMHO, something like this seems preferable to recommending the IETF
> design a new transport protocol variant/mechanism to solve this
> particular problem. Does this seem within the spirit of RFC ?

Yes, especially the spirit of RFC1958 ;-)

   Brian

> 
> Best wishes,
> 
> Gorry
> 
> P.S. I now have a marker in the draft to update this in the next rev.
> 
> Brian E Carpenter wrote:
>> I may have not quite understood the comments about ECMP
>> and the flow label in 6man today. But here goes:
>>
>> The flow label spec in RFC3697 says, very carefully and
>> precisely:
>>
>>    IPv6 nodes MUST NOT assume any mathematical or other properties of
>>    the Flow Label values assigned by source nodes.  Router performance
>>    SHOULD NOT be dependent on the distribution of the Flow Label values.
>>    Especially, the Flow Label bits alone make poor material for a hash
>>    key.
>>
>> This seems to be frightening people. The point is that, although we'd
>> like the flow labels to be widely scattered across the 2^20 possible
>> values, we can't be certain that arbitrary sources will generate that
>> with adequate randomness. Since we didn't know when we wrote RFC3697,
>> and don't know today, which end-to-end use cases for the flow label
>> will emerge, we can't make any mathematical assumptions about the
>> actual randomness. In fact, today, the average value of the flow label
>> is essentially indistinguishable from zero.
>>
>> The key word in the above extract is "alone". If you want use a hash
>> to drive ECMP, don't just hash the flow label, because you'll very
>> likely always get the same answer.
>>
>> If you currently use a 5-tuple for an ECMP hash, expand it to a
>> 6-tuple by adding the flow label.
>>
>> Section 1.2.5 of draft-fairhurst-tsvwg-6man-udpzero-00 says:
>>
>>    An alternate method could utilise the IPv6 Flow Label to perform load
>>    balancing.  This would release IPv6 load-balancing devices from the
>>    need to assume semantics for the use of the transport port field.
>>    This use of the flow-label is consistent with the intended use,
>>    although further clarity may be needed to ensure the field can be
>>    consistently used for this purpose.  Router vendors could be
>>    encouraged to start using the IPv6 Flow Label as a part of the flow
>>    hash.
>>
>> I think the fact is that you can usefully *add* it to the hash, in the
>> expectation that non-zero flow labels will appear in future, but
>> initially it will do nothing to improve the distribution of the
>> hash. So I think that the ports cannot be removed; the second sentence
>> above is wrong.
>>
>>     Brian
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6 at ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
> 
>