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 7EAB73B260 for ; Fri, 6 May 2016 05:00:15 -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 u46902oK011846; Fri, 6 May 2016 02:00:02 -0700 Date: Fri, 6 May 2016 02:00:02 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: moeller0 cc: Jonathan Morton , cake@lists.bufferbloat.net In-Reply-To: <8F329CCB-038C-4EF4-A01D-DB8C093AE6B2@gmx.de> Message-ID: References: <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <2D83E4F6-03DD-4421-AAE0-DD3C6A8AFCE0@gmail.com> <1577AB06-3C14-43D1-92AD-E37CEDCB8E11@gmail.com> <8F329CCB-038C-4EF4-A01D-DB8C093AE6B2@gmx.de> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-109893893-1462525202=:3021" Subject: Re: [Cake] Fwd: [Codel] fq_codel_drop vs a udp flood 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, 06 May 2016 09:00:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-109893893-1462525202=:3021 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 6 May 2016, moeller0 wrote: > Hi Jonathan, > >> On May 6, 2016, at 06:44 , Jonathan Morton wrote: >> >> >>> On 6 May, 2016, at 07:35, Dave Taht wrote: >>> >>> this would be a pretty nifty feature for cake to have in this hostile universe. >> >> Yes, but difficult to implement since the trailing fragments lose the proto/port information, and thus get sorted into a different queue than the leading fragment. We would essentially need to implement the same tracking mechanisms as for actual reassembly. > > But the receiver needs to be able to re-segment the fragments so all required information needs to be there; what about looking at src and dst address and the MF flag in the header as well as the fragment offset and scrape proto/port from the leading fragment and “virtually” apply it to all following fragments, that way cake will do the right thing. All of this might be too costly in implementation and computation to be feasible… wait a minute here. If the fragments are going to go over the network as separate packets, each fragment must include source/dest ip and source/dest port, otherwise the recipient isn't going to be able to figure out what to do with it. David Lang --680960-109893893-1462525202=:3021--