From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4803221F1C1 for ; Fri, 12 Jul 2013 10:33:01 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A8EF732531D; Fri, 12 Jul 2013 19:32:58 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8A1BC4C015; Fri, 12 Jul 2013 19:32:58 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 19:32:58 +0200 From: To: "dave.taht@gmail.com" , "eric.dumazet@gmail.com" Thread-Topic: [Codel] hardware multiqueue in fq_codel? Thread-Index: AQHOfllyuupSivZrW06Przg8bCRnoplfnmCAgAAGRACAAA0tAIAAKFeAgADNjoCAAF7AgIAAF3oAgAADuQCAAAEmAIAALDBP Date: Fri, 12 Jul 2013 17:32:57 +0000 Message-ID: <28095_1373650378_51E03DCA_28095_5538_1_1krbrqls2gs19ybtlbq37amd.1373650371597@email.android.com> References: <1373564673.4600.55.camel@edumazet-glaptop> <1373568848.4600.66.camel@edumazet-glaptop> <20130712113413.4b601800@redhat.com> <1373642001.10804.18.camel@edumazet-glaptop> <1373647842.10804.28.camel@edumazet-glaptop>, In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1krbrqls2gs19ybtlbq37amd1373650371597emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.12.161222 Cc: "codel@lists.bufferbloat.net" , "jbrouer@redhat.com" Subject: Re: [Codel] hardware multiqueue in fq_codel? X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:33:01 -0000 --_000_1krbrqls2gs19ybtlbq37amd1373650371597emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 wrote: On Fri, Jul 12, 2013 at 12:50 PM, Eric Dumazet wro= te: > 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 que= ues >> will need to vastly exceed the packet limit rather than the number of qu= eues, >> thus yielding the same behavior as a normal attack against pfifo_fast, a= nd >> 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=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html _______________________________________________ Codel mailing list Codel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/codel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_1krbrqls2gs19ybtlbq37amd1373650371597emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


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@gmail.com> wrote:
On Fri, Jul 12, 2013 at 12:50 PM, Eric Dumazet <= ;eric.dumazet@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 ran= dom
>> number, any level of dumb attack as an attempt to fill all availab= le 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_f= ast, 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<= br> > 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=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.buff= erbloat.net/listinfo/codel
 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_1krbrqls2gs19ybtlbq37amd1373650371597emailandroidcom_--