<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div><br>
<br>
I agree with Dave,
<div><br>
</div>
<div>any active flow list used by a per-flow scheduler must store</div>
<div>as much state as the maximum number of distinct flows</div>
<div>active at the same time in the buffer memory, i.e. flows having</div>
<div>at least one packet in the total available buffering.</div>
<div><br>
</div>
<div>This max number is bounded and the test described by Eric</div>
<div>is the worst case. In such case, however, the same configuration</div>
<div>would be observed in a FIFO queue with as much buffer memory</div>
<div>than the fqcodel system. In that configuration the service order</div>
<div>of the packets from the queue is meaningless, and the has either.</div>
<div><br>
</div>
<div><br>
</div>
<div>Luca</div>
<div><br>
<br>
<span style="font-size:100%">--<br>
France Telecom R&D - Orange Labs<br>
MUSCARIELLO Luca - OLN/NMP<br>
38 - 40 rue du General Leclerc<br>
92794 Issy Les Moulineaux Cedex 9 - France<br>
http://perso.rd.francetelecom.fr/muscariello</span></div>
<br>
Dave Taht <dave.taht@gmail.com> wrote:<br>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Fri, Jul 12, 2013 at 12:50 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:<br>
> On Fri, 2013-07-12 at 12:37 -0400, Dave Taht wrote:<br>
><br>
>> This is not strictly true, as the hash is permuted by a secret random<br>
>> number, any level of dumb attack as an attempt to fill all available queues<br>
>> will need to vastly exceed the packet limit rather than the number of queues,<br>
>> thus yielding the same behavior as a normal attack against pfifo_fast, and<br>
>> in the general case an attack that would overwhelm pfifo_fast won't be<br>
>> anywhere near as damaging against fq_codel.<br>
><br>
> I can give you a program doing a flood on random destination IP, and I<br>
> will tell you it will fill your fq_codel buckets. All of them. secret<br>
> random number wont help at all.<br>
<br>
My point was that same program would be just as damaging against<br>
pfifo_fast.<br>
<br>
> Or just think of SYN flood attack.<br>
<br>
For which other defenses exist.<br>
><br>
><br>
><br>
<br>
<br>
<br>
-- <br>
Dave Täht<br>
<br>
Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html">
http://www.teklibre.com/cerowrt/subscribe.html</a><br>
_______________________________________________<br>
Codel mailing list<br>
Codel@lists.bufferbloat.net<br>
<a href="https://lists.bufferbloat.net/listinfo/codel">https://lists.bufferbloat.net/listinfo/codel</a><br>
</div>
</span></font>
<PRE>_________________________________________________________________________________________________________________________
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.
</PRE></body>
</html>