From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mediaspot.net (mail.mediaspot.net [109.73.92.181]) by huchra.bufferbloat.net (Postfix) with ESMTP id 6192C21F175 for ; Mon, 24 Dec 2012 02:17:38 -0800 (PST) X-Spam-Status: No, hits=4.0 required=6.5 tests=BAYES_99: 4.07, HTML_MESSAGE: 0.001, TOTAL_SCORE: 4.071, autolearn=no X-Spam-Level: **** X-Footer: bWVkaWFzcG90Lm5ldA== Received: from exchange.mediaspot.net ([192.168.0.22]) by mail.mediaspot.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for Codel@lists.bufferbloat.net; Mon, 24 Dec 2012 11:17:33 +0100 Received: from EXCHANGE.mediaspot.local ([fe80::59f7:a31d:de3f:869b]) by EXCHANGE.mediaspot.local ([fe80::59f7:a31d:de3f:869b%26]) with mapi id 14.02.0328.009; Mon, 24 Dec 2012 11:17:33 +0100 From: Alessandro Bolletta To: "Codel@lists.bufferbloat.net" Thread-Topic: fq_codel and 802.11n packet aggregation Thread-Index: Ac3hvTfMlk/Jf0FoRG6HUhVZ7NoZ6w== Date: Mon, 24 Dec 2012 10:17:33 +0000 Message-ID: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.79] Content-Type: multipart/alternative; boundary="_000_F52F175DFC537F48A43937B50B44BCA276D0D9A5EXCHANGEmediasp_" MIME-Version: 1.0 Subject: [Codel] fq_codel and 802.11n packet aggregation 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: Mon, 24 Dec 2012 10:17:39 -0000 --_000_F52F175DFC537F48A43937B50B44BCA276D0D9A5EXCHANGEmediasp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everybody, thanks to Dave, I just learned that fq_codel suffers from every type of que= uing technique made on underlaying layers (as in device drivers, for exampl= e), and one of these queuing techniques are 802.11n/ac packet aggregation a= nd 802.11e QoS. David said that, at this time, the problem isn't going to be solved shortly= , even if it seems that there are already some ideas in order to solve this= problem. In my specific case, I would like to run fq_codel in a new (and very extend= ed) mesh network that doesn't match with some limitations; for example, if = it will occur that a link bandwidth falls below 4Mbit/s, mesh net will cons= ider that link not available to carry traffic, because I surely know that i= t will not be sufficient to suit bandwidth requirements of my network. Also, I could increase target and interval values whenever i'll need to adj= ust settings that I can't expect now. So, i was thinking that, maybe, if i increase target and interval values to= include packet aggregation delay times in the overall delay, I could just = overall the problem, waiting for a fix in the future. What do you think about? Is it a good compromise or there are other aspects= that i'm leaving behind? Thanks so much for your help! Alessandro --_000_F52F175DFC537F48A43937B50B44BCA276D0D9A5EXCHANGEmediasp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everybody,

thanks to Dave, I just learned that fq_codel suffers= from every type of queuing technique made on underlaying layers (as in dev= ice drivers, for example), and one of these queuing techniques are 802.11n/= ac packet aggregation and 802.11e QoS.

David said that, at this time, the problem isn’= ;t going to be solved shortly, even if it seems that there are already some= ideas in order to solve this problem.

 

In my specific case, I would like to run fq_codel in= a new (and very extended) mesh network that doesn’t match with some = limitations; for example, if it will occur that a link bandwidth falls belo= w 4Mbit/s, mesh net will consider that link not available to carry traffic, because I surely know that it will not be = sufficient to suit bandwidth requirements of my network.

Also, I could increase target and interval values wh= enever i’ll need to adjust settings that I can’t expect now.

 

So, i was thinking that, maybe, if i increase target= and interval values to include packet aggregation delay times in the overa= ll delay, I could just overall the problem, waiting for a fix in the future= .

What do you think about? Is it a good compromise or = there are other aspects that i’m leaving behind?

 

Thanks so much for your help!

 

Alessandro

--_000_F52F175DFC537F48A43937B50B44BCA276D0D9A5EXCHANGEmediasp_--