On 27 Jun 2011, at 15:49 , Thomas Narten wrote: > RJ Atkinson <rja.li...@gmail.com> writes: >> In the approach I outlined, for some given flow where the >> originating node did not set a Flow Label value, the >> non-fragmented packets all will have some Flow Label value A, >> while fragmented packets all will have some Flow Label value B. >> With high probability, (A != B). Still, this outcome is not >> obviously worse than having all of those packets with a Flow Label >> value of zero. > > IMO, it is worse. It means that packets with the different Flow Labels > may take different paths, and thus arrive at the destination out of > order relative to each other.
This is ALSO true for packets containing an all-zero Flow Label. Existing deployed routers typically go read the transport-protocol and transport-layer ports, and load-balance based on all 5 values (IP addresses, transport protocol, plus transport-layer port numbers). If not all 5 values are accesssible, for example due to presence of a Fragmentation Header, then existing deployed routers typically use the 2 values available (i.e. IP addresses). For the case where the Flow Label is zero, I fully expect that routers will use the currently deployed behaviour. So having 2 different Flow Label values in the case I describe at top yields **identical** behaviour as today -- therefore "not obviously worse" in the quote at top. > This is known to cause problems with TCP. Sure, implementations > may (generally) be able to handle this better today than in the past, > it is not the case that reordering packets has no impact. Historically, back in the days of 4.3 BSD TCP performance was seriously harmed by packet reordering. Modern TCP implementations, however, are more robust. So the performance impact of small amounts of packet reordering (which is the case here) ranges between minor and ignorable. > Setting the Flow Label using only the 2-typle for all packets > would prevent this reordering. No. It would not. Packet reordering will still occur from time to time in the deployed Internet -- no matter what the Flow Label values might be. > That said, I agree that there is no easy way to end up with the same > flow label value for both fragmented and unfragmented packets (unless > set by the source). I also agree that having routers reassemble > packets in order to generate proper Flow Ids would be a silly > requirement (or suggestion) and no router would implement that. > > I think we are stuck with having different flow ids being generated > for fragmented vs. unfragmented packets. I'm glad we ended up the same place, although we clearly followed different reasoning to get there. :-) Cheers, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
