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

Dave Taht dave.taht at gmail.com
Fri May 6 00:57:30 EDT 2016


On Thu, May 5, 2016 at 9:44 PM, Jonathan Morton <chromatix99 at gmail.com> wrote:
>
>> On 6 May, 2016, at 07:35, Dave Taht <dave.taht at 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.

No. At least in the iperf3 case you end up with 3 trailing fragments
in their own queue for every first fragment in another queue. Nuking
everything once in drop mode with "more fragments" set or a non-zero
fragment offset field will do some good.

https://en.wikipedia.org/wiki/IPv4#Fragmentation_and_reassembly

In the netperf case (which does 64k fragments), even better. And
against your typical fragmentation attack, dunno, but all and all it
strikes me as a measurable win.

>
>  - Jonathan Morton
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


More information about the Cake mailing list