From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 46F8D3B25E for ; Fri, 6 May 2016 19:14:54 -0400 (EDT) Received: by mail-ob0-x234.google.com with SMTP id n10so59285045obb.2 for ; Fri, 06 May 2016 16:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=I8jMqj4zzBWxikRUNmAZgm3QZIlrE/jqdKOyCYU174k=; b=WyzEbrsugC/erSNVtbp9d8cDp5QF4X1U8RdLmpg5stYz+CudRqUR/VDOOkzfW8W0vL iqXw8+rA+UsLs2W8uJ+MO1HGo5pzOSU93HMY5KlU563VpE0g7/Nh00Bbrnjz0YRGe0p6 hK1fi2hGS8ImeYa1xh5mihuSLUA5e8w85EAJJHmIZ/3tlLbS5PGRg08DPDArEobl1+cC vnFE45f/sleOKSw0RhmzSvAEt1Lkyi/3UqdXezz0VgXd+9uLxKvsNLx6bChQDfnng5vi 1yAtrbgdXedqgs2BrVQ8yDC2fC6HrK/0gH8CFzExFWvnN0/ZHciZhFkkQs/qcobDq1Xx oSow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=I8jMqj4zzBWxikRUNmAZgm3QZIlrE/jqdKOyCYU174k=; b=IrLECjbra64PbMcdodAO5Z6LnmBQ/ZFU7CftV4Gs6AoVH5Lo0OrLuZQMIaxjg3jAHa Pli+A6PTx+Fq8EDoL0FRkifWhdThB9vRNjOXyhGrpZTpK+etLkW1wo8ssHbEQ/soaePn JTjGih077bN5f5HeFKz2hw0JLVx1qwy1uI0V3H0bQaiNaIkVvPoOM+3TwArpp3TmdMd3 2OmdeqDDEpC0X4Nu91o9ZOmRfe+3XhnDruLZrniYr6q7zNDQlsF23vDHpIvfOIfnO/rB XW/1348RToyvcktQQEjH1Tp2RoGFi+BFC4WseCsXyY6rw0aZmsPEZlTNq+v/4T2AuAwi 6JXQ== X-Gm-Message-State: AOPr4FWcJMr1SGr9hJpln9v+hEUAQm/3cn8a4Vp7UIfFRhrnwWg6Fr7qqGVWB2y4RO0fU+yTfyS3UJLnaTdplA== MIME-Version: 1.0 X-Received: by 10.182.159.69 with SMTP id xa5mr11434578obb.75.1462576493549; Fri, 06 May 2016 16:14:53 -0700 (PDT) Received: by 10.157.5.215 with HTTP; Fri, 6 May 2016 16:14:53 -0700 (PDT) In-Reply-To: References: <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> <20160506083114.0730d9f1@xeon-e3> Date: Fri, 6 May 2016 18:14:53 -0500 Message-ID: From: Benjamin Cronce To: David Lang Cc: Stephen Hemminger , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=14dae939976d5ae1fa053234a055 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 23:14:54 -0000 --14dae939976d5ae1fa053234a055 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The good ones do. You need to reassemble the packets if you want to enforce proper stateful TCP. I wonder how those new network stacks that use MSS to send packets directly to a specific core will handle fragments, since they need all packets for a flow to get assigned to the same core, which means L3/L4 must hash to the same value, and no L4 for later fragments. Unless all fragmented packets get handled on a specific core, like ICMP. On Fri, May 6, 2016 at 1:50 PM, David Lang wrote: > On Fri, 6 May 2016, Stephen Hemminger wrote: > > On Fri, 6 May 2016 02:00:02 -0700 (PDT) >> David Lang wrote: >> >> 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 hostil= e >>>>>> universe. >>>>>> >>>>> >>>>> Yes, but difficult to implement since the trailing fragments lose the >>>>> proto/port information, and thus get sorted into a different queue th= an the >>>>> leading fragment. We would essentially need to implement the same tr= acking >>>>> 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 s= rc >>>> 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=9Cvi= rtually=E2=80=9D >>>> apply it to all following fragments, that way cake will do the right t= hing. >>>> All of this might be too costly in implementation and computation to b= e >>>> feasible=E2=80=A6 >>>> >>> >>> wait a minute here. If the fragments are going to go over the network a= s >>> 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 >>> >> >> 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 a= s >> needed) >> to allow matching on port values. >> > > actually, many firewalls do not reassemble packets, they pass packets > through without reassembly. > > what IP id are you referring to? I don't remember any such field in the > packet header. > > David Lang > > > For several cases where flow information is necessary most code does: >> flowid =3D is_fragementd(ip) ? ip->id : hash(ip + tcp) >> >> > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > > --14dae939976d5ae1fa053234a055 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The good ones do. You need to reassemble the packets if yo= u want to enforce proper stateful TCP. I wonder how those new network stack= s that use MSS to send packets directly to a specific core will handle frag= ments, since they need all packets for a flow to get assigned to the same c= ore, which means L3/L4 must hash to the same value, and no L4 for later fra= gments. Unless all fragmented packets get handled on a specific core, like = ICMP.

On Fri= , May 6, 2016 at 1:50 PM, David Lang <david@lang.hm> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Fri, 6 May 2016, Stephen = Hemminger wrote:

On Fri, 6 May 2016 02:00:02 -0700 (PDT)
David Lang <david@lan= g.hm> wrote:

On Fri, 6 May 2016, moeller0 wrote:

Hi Jonathan,

On May 6, 2016, at 06:44 , Jonathan Morton <chromatix99@gmail.com> wrote:


On 6 May, 2016, at 07:35, Dave Taht <dave.taht@gmail.com> wrote:

this would be a pretty nifty feature for cake to have in this hostile unive= rse.

Yes, but difficult to implement since the trailing fragments lose the proto= /port information, and thus get sorted into a different queue than the lead= ing fragment.=C2=A0 We would essentially need to implement the same trackin= g mechanisms as for actual reassembly.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 But the receiver needs to be able to re-segment= the fragments so all required information needs to be there; what about lo= oking at src and dst address and the MF flag in the header as well as the f= ragment 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 wi= ll do the right thing. All of this might be too costly in implementation an= d computation to be feasible=E2=80=A6

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

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.

 actually, many firewalls do not reassemble packets, they pass packets throu= gh without reassembly.

what IP id are you referring to? I don't remember any such field in the= packet header.

David Lang


For several cases where flow information is necessary most code does:
=C2=A0flowid =3D is_fragementd(ip) ? ip->id : hash(ip + tcp)


_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake


--14dae939976d5ae1fa053234a055--