OK. We'll revise draft-fairhurst-tsvwg-6man-udpzero accordingly.
Do let us know if you are inspired to progress with an I-D on this topic
- to me this seems like a more general network issue, rather than being
transport-related, so a separate I-D could be a good idea.
Gorry
Brian E Carpenter wrote:
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 encapsulated 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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
