From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 150B43B260 for ; Fri, 6 May 2016 05:36:21 -0400 (EDT) Received: from [172.17.3.79] ([134.76.241.253]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MHH3P-1av1YT3ohP-00E3ms; Fri, 06 May 2016 11:36:06 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Fri, 6 May 2016 11:36:02 +0200 Cc: Jonathan Morton , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <5AC664B7-6D4C-45A4-8C6B-46D6DA2CB019@gmx.de> 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> To: David Lang X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:bctfVBZo2jY/4mutml+mzanR6PVx+izlYzppMAH7v7an20XhM7r CT4/DaacXmaDlcsZuHfCwAuvfn5u7nOicWPlcp/+R08shKyfg6zukjeFgdbqNffaRcGYJmE 8/hoXxh4Y9MDoxJmK3jaG3KwaWVxEDd0mjViiK6y17e7kucK3dWsn2zjf6ir2DHVKGzDftx v143hYG4TmkVo3mpSmwVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:306ZRuNyyuM=:nSfkyLWllkGZ+AGwW0unMd 1h+cPuUiHzJguXBFgFIYRL/HhDS1OG1SLizSk7MFAaExciPCTPOpGNt6pLYe5LU0GVOBL80bk W8VpeZtfUWTbtxmEWSDP0MmneJUtFwneVfw1+l4smseVWjHc/3xNCQB4mMWIw+Ye3OLcWe7Dw +jIqx58wy/S4kXiuQu10lCV0nWGkBvRmER2M9mzhZSmmV8DSkztGGsfdMm0OaZHC2fZ/XTBfW PtrV08RkqluVPbzB3AsJc691GrWYKaztBBUVEjguklfzewNR13tqdmPes6on9Z7FAijtzi/VE CQCHwehXT7MCC4S/TNj1NO6XQNw0Bb6WhsunMPVoHmAmDO3UKV+PkfNnjvw8mmY7rPPJ7+qo1 Fom60ekihOcfUxyirMO4tDspouekVK+K77Ks5gCAaC1DLUeP/7gtMX0LHoEcl2xGscz9nh9a7 T9Xw5t58OEIVXXVNQxYjdcPwF3u7l0u0873eP4HWfltVyf0XJyGkrXEgbJFJNA97BAGZEdZqO VNVfVLXbhJVOmT7MVfL8CdMoBEvH4Pz2oYSl6SBVtZ9ONUJbcOTSxHTeCWdhB9klJ3Pt1aCcG 4Uqc7ZGH1qTUurniR+kDnMGjDcwShqfpuZERQNUVDRzKRm893o75tYFXs1h635jBpH/sYVz1i ygTmxyfGvgozJM9p9u/oQbhXIeg/XmgRObPvMD8/MR8SVk1mKf9jjNMkvdtSemjvF1Ei9NTD7 GKQkcZ6BmYcIVItm5m9Jfkrb5xtwrkF//+I3OCn2Yy1jVEXl97i1QyZEbkuXg+sV1sr+PJDBN BCNFYDh 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:36:22 -0000 > On May 6, 2016, at 11:00 , David Lang wrote: >=20 > On Fri, 6 May 2016, moeller0 wrote: >=20 >> Hi Jonathan, >>=20 >>> 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. >>=20 >> 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 = =E2=80=9Cvirtually=E2=80=9D 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=E2=80=A6 >=20 > 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=E2=80=99t going to be able = to figure out what to do with it. That is what I thought as well, but as I understand now = fragmentation happens on the IP level independent of the =E2=80=9Cpayload=E2= =80=9D so fragmentation is all the same for UDP/TCP/ICMP. According to = https://en.wikipedia.org/wiki/IPv4#Fragmentation_and_reassembly all = packets in a fragment group should have the same IP identification = value, so matching fragmented packets should be even easier, just use = the SRCIP, DSTIP PROTOCOL IDENTIFICATION quadruple (all values that live = in the IP header, or use these values to find the matching port from the = first fragments protocol header=E2=80=A6 For sanity checking one might = even require for all but the last packet to have the MF flag set and the = fragment offsets to be monotonically increasing. But this will require = to at least look at the MF flag to notice fragments at all=E2=80=A6 But = I guess https://tools.ietf.org/html/rfc6864 says all of this more = distinctively=E2=80=A6 Best Regards Sebastian >=20 > David Lang