From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x230.google.com (mail-vn0-x230.google.com [IPv6:2607:f8b0:400c:c0f::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CEBAB208A7C for ; Fri, 29 May 2015 06:02:21 -0700 (PDT) Received: by vnbg129 with SMTP id g129so8008468vnb.9 for ; Fri, 29 May 2015 06:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rqyWQPvGTIyxIYQmer2Pqt119buryYGNm9cfIzpaxeg=; b=FHEndnCNJXTjlfR0JrbnswkmAVNDVVhedkkKUT/CcHo83tLblI7mNVJ3YkcoygJ/41 gUTVIxiBftj/9/sK0U5F3hXLKkKVftGSV22E/42U71Ktet/UwhhkMgakSh+CC2+6bbHg 1dgbSb8NhWLQTuH3VCv7RDciC3CE2xORtADpFfJZiCS1dZuYcbn6gv8b3hUHRu+Uk0i7 ulRNh3r9Mh+lpe7pRGt0J7vUOOT/frq0cdm1bUwkSwaQEiN+QOHB6yTO7ZEDe8ETPNkf MPKwvcE2OV9wa7tISecEVdG4FlR9MMxp59bYaRnC8JnybVwvaUmr0PqrUHpLKWQJ3SgL iC8A== MIME-Version: 1.0 X-Received: by 10.52.137.112 with SMTP id qh16mr7083607vdb.44.1432904537472; Fri, 29 May 2015 06:02:17 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Fri, 29 May 2015 06:02:17 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Fri, 29 May 2015 06:02:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 May 2015 16:02:17 +0300 Message-ID: From: Jonathan Morton To: Dave Taht Content-Type: multipart/alternative; boundary=bcaec52d599ff40815051738154f Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] cake byte limits too high by 10x X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 13:03:12 -0000 --bcaec52d599ff40815051738154f Content-Type: text/plain; charset=UTF-8 > > What wifi needs is a bit different: > > > > (hosts/aggregates?) -> (shapers/minstrel?) -> priority -> flows -> signalling -> queues > Yep. > I don't see a huge need for "shaping" on wifi. I do see a huge need - as a starting point - an airtime fair per station queue that is aggregation aware, and slightly higher up, something that is aware of the overall workload on the AP. Which is basically what I'm thinking of. "Airtime fair" is also known as "proportional fair". You need to know the data rate to each station for that. But knowing the data rate via minstrel, and the average expected time between transit opportunities to each station (which could probably be calculated rather than measured), would allow inferring certain things that I currently do using the shaper in cake, such as the appropriate size for the aggregate, and the amount of bandwidth that we can allow priority in. The only reason I can't reliably do that in cake with the shaper disabled is because I can't sense the hardware link rate, which is exactly what minstrel is in charge of. Incidentally, I suspect that aggregates of equal temporal length are valuable for multi station MIMO. It's also pretty obvious that selective link layer acks need to be acted on, and aggregates reformed for each transmit opportunity, whether a retry or not. I'm very disappointed to hear that those things often aren't already done, but it's probably a consequence of leaving that functionality to the hardware vendors so far. It's even possible that the current mess of binary blobs is a consequence of the weak support for aggregation in the kernel. Probably not so much raw code (which autocorrected to coffee TWICE) can be reused from cake, not least due to simply operating at a different layer of the stack, but I think a lot of the conceptual advances can. - Jonathan Morton --bcaec52d599ff40815051738154f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> > What wifi needs is a bit different:
> >
> > (hosts/aggregates?) -> (shapers/minstrel?) -> priority ->= ; flows -> signalling -> queues

> Yep.

> I don't see a huge need for "shaping" on = wifi. I do see a huge need - as a starting point - an airtime fair per stat= ion queue that is aggregation aware, and slightly higher up, something that= is aware of the overall workload on the AP.

Which is basically what I'm thinking of. "Airtime f= air" is also known as "proportional fair". You need to know = the data rate to each station for that.

But knowing the data rate via minstrel, and the average expe= cted time between transit opportunities to each station (which could probab= ly be calculated rather than measured), would allow inferring certain thing= s that I currently do using the shaper in cake, such as the appropriate siz= e for the aggregate, and the amount of bandwidth that we can allow priority= in. The only reason I can't reliably do that in cake with the shaper d= isabled is because I can't sense the hardware link rate, which is exact= ly what minstrel is in charge of.

Incidentally, I suspect that aggregates of equal temporal le= ngth are valuable for multi station MIMO.

It's also pretty obvious that selective link layer acks = need to be acted on, and aggregates reformed for each transmit opportunity,= whether a retry or not. I'm very disappointed to hear that those thing= s often aren't already done, but it's probably a consequence of lea= ving that functionality to the hardware vendors so far. It's even possi= ble that the current mess of binary blobs is a consequence of the weak supp= ort for aggregation in the kernel.

Probably not so much raw code (which autocorrected to coffee= TWICE) can be reused from cake, not least due to simply operating at a dif= ferent layer of the stack, but I think a lot of the conceptual advances can= .

- Jonathan Morton

--bcaec52d599ff40815051738154f--