From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3A54F3B260 for ; Fri, 20 May 2016 10:42:54 -0400 (EDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id E205F401E843; Fri, 20 May 2016 07:42:52 -0700 (PDT) Received: from kmnimac.local (unknown [50.136.231.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id AA7DE401E841; Fri, 20 May 2016 07:42:52 -0700 (PDT) To: codel@lists.bufferbloat.net References: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> <991C8B50-192E-431A-819F-F1C5954FF64F@gmx.de> From: Kathleen Nichols Message-ID: <3f1756f2-2f8a-d9f7-76cc-0036ee182a94@pollere.com> Date: Fri, 20 May 2016 07:42:51 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Codel] [Cake] Proposing COBALT X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 14:42:54 -0000 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 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 > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel