From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A48593B260; Fri, 20 May 2016 10:04:59 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u4KE4mbG028417; Fri, 20 May 2016 07:04:48 -0700 Date: Fri, 20 May 2016 07:04:48 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: moeller0 cc: Jonathan Morton , cake@lists.bufferbloat.net, codel@lists.bufferbloat.net In-Reply-To: <991C8B50-192E-431A-819F-F1C5954FF64F@gmx.de> Message-ID: References: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> <991C8B50-192E-431A-819F-F1C5954FF64F@gmx.de> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Cake] Proposing COBALT X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 14:04:59 -0000 On Fri, 20 May 2016, moeller0 wrote: >> On May 20, 2016, at 15:41 , David Lang 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