From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F224B3B25E; Sat, 15 Oct 2016 03:59:52 -0400 (EDT) Received: by mail-yb0-x234.google.com with SMTP id e20so49992877ybb.0; Sat, 15 Oct 2016 00:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CEP4U30fuUqYESBfuyAWeSRqQOJ4y2MZFXL3YtA0sxA=; b=Wp9moz/01VkEIKtqGUge6kCdQqWm3Vwzkln/zL/6p/4LCUsu2ab6vgDV2t3+V/oWEB b6GnKPIvEPrNm8EVASb5qSoczP/9Syq1LAzfiS4qwsQZO6ba5xSTuINJ04y7XXgxhXqK 0tG3aqRq1zcuOpBDlo4fUOsxZ/de4It5fEbhYztiIyWsALqBb3lNJJLYTQxrMKJneBfk O4YXmUVv9JrGvE+L3yiiID56gutrwlgJCRNfaWgahphiUMFPG3128jJBkXcpBucPx2hy c/n9Ou6Gj4tWon3kW/JY57H1b/NhYJJKWs4vck0sW5HqEy0NuGQpVLdPI4h/FQKw3ifX 0vUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CEP4U30fuUqYESBfuyAWeSRqQOJ4y2MZFXL3YtA0sxA=; b=KQLxVnoAtmQ6kewC54L+bzdtTPbC1cOPyzkuS7w11j8e5KzFsvm5XEY3bTI1zRBotU JoYM/fMiZMqtgD8spRtxZM4QXBHVUHLp0yjpfjd2FwAk67f8rPRBvnXQfrDHsaQ1FEVN 6X+AffDq4Ti/VQQ9VwgDC34CJz/3c9HrSdV9cThvYX5d2qwdawYSZlATojX8l2AaXNVl bJnJpn8wxeZ6SwnRNcOno3e7jMC8tanpBFgYJ3ge75k91jDK6C1TRyZrZcCWFrS7cNRU 1Ac3SbS01uVHcfeDj4o1fhuNO4yh6F6pbcFZJ3C4q7DG1ErIyxA+q+WBmGSE34iaFP+V 9PzA== X-Gm-Message-State: AA6/9RnH4iUOtDwf2J2aAT0vg2CINuS19l3+dsn1+f3eOmtAlV6Dqcvatmnhq4fVE1Y+etMMsuu17R9S6wqugA== X-Received: by 10.37.170.178 with SMTP id t47mr14401357ybi.22.1476518392502; Sat, 15 Oct 2016 00:59:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.98.86 with HTTP; Sat, 15 Oct 2016 00:59:52 -0700 (PDT) In-Reply-To: References: From: Luca Muscariello Date: Sat, 15 Oct 2016 09:59:52 +0200 Message-ID: To: Mikael Abrahamsson Cc: Dave Taht , "make-wifi-fast@lists.bufferbloat.net" , bloat Content-Type: multipart/alternative; boundary=94eb2c0894144a20b7053ee2baa3 Subject: Re: [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 07:59:53 -0000 --94eb2c0894144a20b7053ee2baa3 Content-Type: text/plain; charset=UTF-8 Air time fairness has a strong theoretical foundation. So I should cite Newton and say that Toke is sitting on giants' schoulders :) In multi rate systems in a shared channel, time is the right resource to share. Then one could discuss about which fairness criterion to use, but that's secondary. The criterion used by toke is max-min in time. I guess this is the best you can do in wifi. This turns out to be proportional fairness in throughput. In LTE the shared channel is time shared (slotted) and fairness is slightly different to max-min in time. In LTE thanks to the feedback channel, multi user diversity can be used to schedule transmissions towards the UE with best radio conditions at a given time. David Tse showed that this is proportional fairness with multi user diversity gain. The cell throughout increases logarithmically with the number of users. And this is the best criterion for many reasons that I skip here. This is out of target for wifi but what Toke is doing is really solid. Luca On Saturday, 15 October 2016, Mikael Abrahamsson wrote: > On Wed, 12 Oct 2016, Dave Taht wrote: > > http://openwrtsummit.org/#quick-details >> > > I've had the discussion with "radio guys" before regarding "fairness" of > radio resources. They kept talking about "optimising the cell for > throughput". I told them "then we should give the speaker with the highest > bitrate and demand for bits as much radio resources as possible, and starve > everybody else". This is of course not good for general customer > satisfaction. > > After a lot of discussions back and forth, we came to the same conclusion > as you seem to have come to (if I understood Tokes talk correctly), in that > "radio time" is the most fair resource. If someone has bad radio conditions > then they get lower total throughput than the one with good radio > conditions, so the fairness is "equal air time". This means everybody get > equal part of the shared resource, and gives people an incentive to try to > improve radio reception if they have trouble, and doesn't starve everybody > else of airtime just because one device is having a bad radio day. > > So full support for this approach from me, good job! > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast > --94eb2c0894144a20b7053ee2baa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Air time fairness has a strong theoretical foundation.
So I should cite= Newton and say that Toke is sitting on giants' schoulders :)

In multi rate systems=C2=A0=C2=A0in a shared channel,=C2=A0= time is the right resource to share.

Then one coul= d discuss about which fairness criterion to use, but that's secondary.<= /div>

The criterion used by toke is max-min in time.
I guess this is the best you can do in wifi.
This turns out to = be proportional fairness in throughput.

In LTE the shared channel is time shared (slotted)=C2=A0
= and fairness is slightly different to max-min in time.

=
In LTE thanks to the feedback channel,=C2=A0multi user diversity can b= e used to schedule transmissions towards the UE with best radio conditions = at a given time.=C2=A0
David Tse showed that this is proportional= fairness
with multi user diversity gain. The cell throughout inc= reases logarithmically=C2=A0with the number of users.
And this is= the best criterion for many reasons that I skip here.

=
This is out of target for wifi but what Toke is doing is really solid.=

Luca


=C2=A0

On Saturday, 15 October 2016, Mikael Abrahamsson <= ;swmike@swm.pp.se> wrote:
On Wed, 12 Oct 2016, Dave Taht wrote:

http:= //openwrtsummit.org/#quick-details

I've had the discussion with "radio guys" before regarding &q= uot;fairness" of radio resources. They kept talking about "optimi= sing the cell for throughput". I told them "then we should give t= he speaker with the highest bitrate and demand for bits as much radio resou= rces as possible, and starve everybody else". This is of course not go= od for general customer satisfaction.

After a lot of discussions back and forth, we came to the same conclusion a= s you seem to have come to (if I understood Tokes talk correctly), in that = "radio time" is the most fair resource. If someone has bad radio = conditions then they get lower total throughput than the one with good radi= o conditions, so the fairness is "equal air time". This means eve= rybody get equal part of the shared resource, and gives people an incentive= to try to improve radio reception if they have trouble, and doesn't st= arve everybody else of airtime just because one device is having a bad radi= o day.

So full support for this approach from me, good job!

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wifi-fast
--94eb2c0894144a20b7053ee2baa3--