On 03/05/16 03:26, Dave Taht wrote:
> On Sun, May 1, 2016 at 11:20 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>>> On 1 May, 2016, at 20:59, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>
>>> fq_codel_drop() could drop _all_ packets of the fat flow, instead of a
>>> single one.
>> Unfortunately, that could have bad consequences if the “fat flow” happens to be a TCP in slow-start on a long-RTT path.  Such a flow is responsive, but on an order-magnitude longer timescale than may have been configured as optimum.
>>
>> The real problem is that fq_codel_drop() performs the same (excessive) amount of work to cope with a single unresponsive flow as it would for a true DDoS.  Optimising the search function is sufficient.
> Don't think so.
>
> I did some tests today,  (not the fq_codel batch drop patch yet)
>
>
> As for cake struggling to cope:
>
> root@apu2:/home/d/git/tc-adv/tc# ./tc -s qdisc show dev enp2s0
>
> qdisc cake 8018: root refcnt 9 bandwidth 100Mbit diffserv4 flows rtt 100.0ms raw
>  Sent 219736818 bytes 157121 pkt (dropped 989289, overlimits 1152272 requeues 0)
>  backlog 449646b 319p requeues 0
>  memory used: 2658432b of 5000000b
>  capacity estimate: 100Mbit
>              Bulk    Best Effort     Video       Voice
>   thresh       100Mbit   93750Kbit      75Mbit      25Mbit
>   target         5.0ms       5.0ms       5.0ms       5.0ms
>   interval     100.0ms     100.0ms     100.0ms     100.0ms
>   pk_delay         0us       5.2ms        92us        48us
>   av_delay         0us       5.1ms         4us         2us
>   sp_delay         0us       5.0ms         4us         2us
>   pkts               0     1146649          31          49
>   bytes              0  1607004053        2258        8779
>   way_inds           0           0           0           0
>   way_miss           0          15           2           1
>   way_cols           0           0           0           0
>   drops              0      989289           0           0
>   marks              0           0           0           0
>   sp_flows           0           0           0           0
>   bk_flows           0           1           0           0
>   last_len           0        1514          66         138
>   max_len            0        1514         110         487
I think it's interesting that the memory used is only a little of 55% of
the autoconfigured max buffer size, so cake_enqueue won't have gone into
its 'buffer full' cake_drop routine - I do wonder if should it ever get
there that it should 'use a shovel' of 64 packets rather than teaspoon
of iterating dropping single packets.

The above also suggests that cake is spending time dropping packets over
the target threshold individually.  Does/could cake codel drop do
something like 'drop sufficient bytes (in packet lumps) to get that flow
back under target threshold- after ECN signalling' in one go, up to some
packet number limit (64)?  Again the idea is to really jump on the
naughty flow!



>
> ...
>
> But I am very puzzled as to why flow isolation would fail in the face
> of this overload.
>
>>  - Jonathan Morton
>>
>
>