On Thu, May 5, 2016 at 9:44 PM, Jonathan Morton <[email protected]> wrote: > >> On 6 May, 2016, at 07:35, Dave Taht <[email protected]> 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 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
