[Codel] hardware multiqueue in fq_codel?

[luca.muscariello at orange.com]

I agree with Dave,

any active flow list used by a per-flow scheduler must store
as much state as the maximum number of distinct flows
active at the same time in the buffer memory, i.e. flows having
at least one packet in the total available buffering.

This max number is bounded and the test described by Eric
is the worst case. In such case, however, the same configuration
would be observed in a FIFO queue with as much buffer memory
than the fqcodel system. In that configuration the service order
of the packets from the queue is meaningless, and the has either.


Luca


--
France Telecom R&D - Orange Labs
MUSCARIELLO Luca - OLN/NMP
38 - 40 rue du General Leclerc
92794 Issy Les Moulineaux Cedex 9 - France
http://perso.rd.francetelecom.fr/muscariello

Dave Taht <dave.taht at gmail.com> wrote:
On Fri, Jul 12, 2013 at 12:50 PM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> On Fri, 2013-07-12 at 12:37 -0400, Dave Taht wrote:
>
>> This is not strictly true, as the hash is permuted by a secret random
>> number, any level of dumb attack as an attempt to fill all available queues
>> will need to vastly exceed the packet limit rather than the number of queues,
>> thus yielding the same behavior as a normal attack against pfifo_fast, and
>> in the general case an attack that would overwhelm pfifo_fast won't be
>> anywhere near as damaging against fq_codel.
>
> I can give you a program doing a flood on random destination IP, and I
> will tell you it will fill your fq_codel buckets. All of them. secret
> random number wont help at all.

My point was that same program would be just as damaging against
pfifo_fast.

> Or just think of SYN flood attack.

For which other defenses exist.
>
>
>



--
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
Codel mailing list
Codel at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/codel/attachments/20130712/0f4d6117/attachment-0002.html>