Hi Tom, Tom Herbert <t...@herbertland.com> writes:
>> The problem is that you end up having two streams, one fragmented and >> one non-fragmented, but actually they belong to the same stream. It is >> known to break stuff, see: >> >> <https://patchwork.ozlabs.org/patch/59235/> >> >> I would agree with you, but we can't break existing setups, >> unfortunately. >> > I'm not sure what "existing setups" means here. If this is referring > to the Internet then out of order packets and fragments abound-- any > assumption of in order delivery for IP packets is useless there. Network cards don't know where traffic originates from, even on the same card. Clouds nowadays try to convince everyone to virtualize existing workloads. So I *assume* that at least for traffic that seems to be in one L2 domain out of order should not occur or things will break. Ethernet for a long time appeared to do very much in order delivery and guarantees that. Thus for people it appeared that UDP packets are also strictly in order. Encapsulating Ethernet inside UDP thus must preserve those properties, especially if used for virtualization. Unfortunately fragmentation happens and the stack has to deal with it somehow. I do know about some software that uses UDP in multicast that is prone to misbehave in case of OoO frames. It uses a small reassemble queue but if reordering gets too high, it will simply drop data. This might be acceptable up to a specific degree. I guess one application you could harm is plain old simple syslog, which often generated fragmented packets. Luckily one often has time stamps in there to reassemble the log lines but one had to do this manually. L2 domains are not bound to local networks anymore, thanks to vxlan etc. If you are in a controlled environment and you do know your software that runs perfectly well, certainly, no doubt, UDP hashing can be enabled. I would argue we can't do that generally. > Btw, TCP has exactly the same problem in this regard that UDP has with > regard to fragmentation. The reason that TCP isn't considered an issue > is the assumption that TCP will do PMTU discovery and set DF (I would > bet that devices don't actually check for DF and vendors don't test > when it's not set!). I don't know. For the application the stream will appear in order at the socket level and OoO or fragmentation won't break anything. End systems will have a harder time reassembling the stream and thus fast paths couldn't be used. Is that what you are referring to? Thanks, Hannes
