Re: [Cake] Fwd: [Codel] fq_codel_drop vs a udp flood

[Benjamin Cronce <bcronce@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2923 bytes --]

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 <david@lang.hm> wrote:

> On Fri, 6 May 2016, Stephen Hemminger wrote:
>
> On Fri, 6 May 2016 02:00:02 -0700 (PDT)
>> David Lang <david@lang.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
>>>>>> 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
>>>
>>
>> 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
>> 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 = is_fragementd(ip) ? ip->id : hash(ip + tcp)
>>
>>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
>

[-- Attachment #2: Type: text/html, Size: 4297 bytes --]