On 5/20/16 7:04 AM, David Lang wrote: > > How big a problem is this in the real world? ARe we working on a > theoretical problem, or something that is actually hurting people? >
The above seems like it should be the FIRST thing to consider. The entire thread: > On Fri, 20 May 2016, moeller0 wrote: > >>> On May 20, 2016, at 15:41 , David Lang <[email protected]> wrote: >>> >>> On Fri, 20 May 2016, Jonathan Morton wrote: >>> >>>> Normal traffic does not include large numbers of fragmented packets >>>> (I would expect a mere handful from certain one-shot >>>> request-response protocols which can produce large responses), so it >>>> is better to shunt them to a single queue per host-pair. >>> >>> I don't agree with this. >>> >>> Normal traffic on a well setup network should not include large >>> numbers of fragmented packets. But I have seen too many networks that >>> fragment almost everything as a result of there being a hop that goes >>> through one or more tunneling layers that lower the effective MTU >>> (and no, path mtu discovery does not always work) >> >> True, do you have a cheaper idea of getting the flow identity >> cheaply from fragmented packets, short of ressembly ;) ? > > How big a problem is this in the real world? ARe we working on a > theoretical problem, or something that is actually hurting people? > > by default (and it's a fairly hard default to disable in OpenWRT), the > kernel is doing connection tracking so that NAT (masq) and stateful > firewalling can work. That process has to solve this problem. The days > of allowing fragments through the firewall ended over a decade ago, and > if you don't NAT the fragments correctly, things break. > > So, assuming that we can do as well as conntrack (or ideally use the > work that it's already doing), then the only case where this starts to > matter is in places that have a custom kernel with conntrack disabled > and are still seeing enough fragments to matter. > > I strongly suspect that in the real world, grouping those fragments by > source/dest IP will spread them into enough buckets to keep them from > hurting any other systems, while still keeping them concentrated enough > to keep fragmentation from being a backdoor around limits. > > Remember, perfect is the enemy of good enough. A broken network that is > fragmenting a lot of traffic is going to have other problems (especially > if it's the typical "fragment due to tunnel overhead" where you have a > full packate and minimum size packet pair that you fragment into). Our > main goal needs to be to keep such systems from hurting others. Keeping > it from hurting other traffic on the same broken host is a secondary goal. > > Is it possible to get speed testing software to detect that it's > receiving fragments and warn about that? > > David Lang > _______________________________________________ > Codel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/codel _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
