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 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. It will depend on various factors... Setting the Flow Label using only the 2-typle for all packets would prevent this reording. (It would have other undesirable effects of having the load balancing not work ideally, but that is a different issue.) 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. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
