From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B76E63B25E for ; Fri, 6 May 2016 11:31:03 -0400 (EDT) Received: by mail-pf0-x235.google.com with SMTP id 77so50790131pfv.2 for ; Fri, 06 May 2016 08:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=nOuH2UIECcpmeOjygZfYBjlDSlaanzPRoElAJUWY6dk=; b=jWqWRcAfK2wCcBpgbZemK+HLthQA+odHGgq9AmBqAROjEXYwJfenNzfOHgNH9lcWA/ ptQQ4fy/KmK+ul5+/xtBjHPmnkAI/21VWUwgskbwyDTfX6U/6CjJbQVgTDrrZymbPHf/ dbOKV9Hb9STq+6jx57EwqstDCmk0jJMyw5wY53v92bqugf7zFXntYWT6VIVAI7ufTYLX dCbnIJDjT1AvU8VuDeHei+veZ2dHWpBBBjCeCsiZkOzxSYRVo8wmnXlygTcWtQUk3JKA +2cqvb6UwaMHousvkevWwBxE/rcr96jBBpQTFaOIccjeo3+I4mqtbSu58Mh7Qzr50l8Z x28Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=nOuH2UIECcpmeOjygZfYBjlDSlaanzPRoElAJUWY6dk=; b=exdTvglbCxYwPUzAWa1k2evcod5P0nFfkQKMikj3Hg3YpcTmT1Pszc0MLY0FevEHN6 2FE+Zcgt9mj3eES7xJHaOE6FzEf0/8W8RqoKFFTCqDxkbaku3edNfxKjLHh3p7JivuUS Hx+bMgmnzHghHLrSEqlHUEm9LzbQR6D8WjHlXhRRJ3nMGszio8IhsmrXWsThCuuXnsfC EOHqigRSQqQ3QJ5NUh2xQoDgUlZEgo/VBb9sTlRz5ETEzoHyVnIWLLAfzCSc0k4YaZ51 0/hXJZGK7yzmuB+pU825xsEGbRVlHMojxgI5wRf8Pyhphs+SgIHOsvP05Q0U7i91MUL2 3O6g== X-Gm-Message-State: AOPr4FUPfomW6pJiQvkBl9rlOJIkBbgpSg9gF3grsBbfJPaFssOC0MzrWpFom/fJ3GV6Uw== X-Received: by 10.98.2.79 with SMTP id 76mr28284136pfc.147.1462548662889; Fri, 06 May 2016 08:31:02 -0700 (PDT) Received: from xeon-e3 (static-50-53-72-186.bvtn.or.frontiernet.net. [50.53.72.186]) by smtp.gmail.com with ESMTPSA id m184sm21916576pfb.22.2016.05.06.08.31.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 May 2016 08:31:02 -0700 (PDT) Date: Fri, 6 May 2016 08:31:14 -0700 From: Stephen Hemminger To: David Lang Cc: moeller0 , cake@lists.bufferbloat.net Message-ID: <20160506083114.0730d9f1@xeon-e3> In-Reply-To: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 15:31:03 -0000 On Fri, 6 May 2016 02:00:02 -0700 (PDT) David Lang wrote: > On Fri, 6 May 2016, moeller0 wrote: >=20 > > Hi Jonathan, > > > >> On May 6, 2016, at 06:44 , Jonathan Morton wro= te: > >>=20 > >>=20 > >>> On 6 May, 2016, at 07:35, Dave Taht wrote: > >>>=20 > >>> this would be a pretty nifty feature for cake to have in this hostile= universe. > >>=20 > >> 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 trackin= g mechanisms as for actual reassembly. > > > > But the receiver needs to be able to re-segment the fragments so all r= equired information needs to be there; what about looking at src and dst ad= dress and the MF flag in the header as well as the fragment offset and scra= pe proto/port from the leading fragment and =E2=80=9Cvirtually=E2=80=9D app= ly it to all following fragments, that way cake will do the right thing. Al= l of this might be too costly in implementation and computation to be feasi= ble=E2=80=A6 >=20 > wait a minute here. If the fragments are going to go over the network as= =20 > separate packets, each fragment must include source/dest ip and source/de= st=20 > port, otherwise the recipient isn't going to be able to figure out what t= o do=20 > with it. >=20 > David Lang Fragments are reassembled by IP id, not src/dest port. Only the first fragment has the L4 header with src/dest port, all the rest are just data. That is why most firewalls reassemble all packets (and then refragment as n= eeded) to allow matching on port values. For several cases where flow information is necessary most code does: flowid =3D is_fragementd(ip) ? ip->id : hash(ip + tcp)