From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 E8FA63B2A4 for ; Thu, 24 Oct 2019 08:55:28 -0400 (EDT) Received: by mail-wm1-x331.google.com with SMTP id q130so2332303wme.2 for ; Thu, 24 Oct 2019 05:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wGV+4/x/tYK1J5rBN9F7WSLBDr/MmUU8KEGpNggrh8g=; b=Dv1ymZxvr6SBJ9fOvFi/l1XfPVKHhULLlO8LJu6T9HlrtgfCEYSrfcq3ht0D1UyNwy kRiONNMSWUQtMOJgMwOKEwSuZS4au4GvDjjlhO9C40oSKVBgHozzBOqkfEHsXkvNCTVw IYeCx9x7I647D9Iwv3V5M7nm+5q0ucaxmJHMA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wGV+4/x/tYK1J5rBN9F7WSLBDr/MmUU8KEGpNggrh8g=; b=qStSIVS7qmB9CXBNrf9tDhJtZXupNpuqqkExfQtGvybOwrHq6qz8PIU9oYLsxo+3Jo apCPFfEeGAhK5Ij0ecuhfgWev0gfuH28AaGuvV7Sfv6Dly6Xq48w5jie4oxQoVHmNcSr wCdnVf4BypmmTp4WR3TSh8o455F1R5jLfppAuQjOyTDLqtnlOkBiJN7Ux8Kxdfkjmk71 es3eO3EG0az1orlEyVIF/bf3CDXBYUdV4iD60sKWKJOOQKMTxAfN8YUZq8ZNFmB8POi2 xo6TdyllVfLXp9KCrpLvOOg+dm5GL9SDNxDYhxhFaSbjkChJyJe8lUh6gUvzZth5Qt5D hHjg== X-Gm-Message-State: APjAAAWVTt6ZC91ydxQ3rWhMy+XHqSQt2mUSvf/11JVQ4ul0x6VDN7El UmnpE460sJs4D7n7eBKN7PgnGtGkH6rLfXn5STorhg== X-Google-Smtp-Source: APXvYqwki0ni/LF8gQgidxVoKkYoxa38jafkOypEIfQ3hj8Qcum7Ro5isLuCUxzScIDEZG+cbcMqf9MoPNTWwFNkdOI= X-Received: by 2002:a1c:5587:: with SMTP id j129mr4812150wmb.15.1571921727948; Thu, 24 Oct 2019 05:55:27 -0700 (PDT) MIME-Version: 1.0 References: <0876C235-C6D3-42B0-9D93-114DB75D4204@gmail.com> <87d0enmyty.fsf@toke.dk> <87y2xalc62.fsf@toke.dk> In-Reply-To: <87y2xalc62.fsf@toke.dk> From: Luca Muscariello Date: Thu, 24 Oct 2019 14:55:16 +0200 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Rich Brown , bloat Content-Type: multipart/alternative; boundary="00000000000035a95d0595a78cab" Subject: Re: [Bloat] Bufferbloat on 4G Connexion X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 12:55:29 -0000 --00000000000035a95d0595a78cab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 24, 2019 at 11:34 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Luca Muscariello writes: > > > On Wed, Oct 23, 2019 at 2:27 PM Toke H=C3=B8iland-J=C3=B8rgensen > > wrote: > > > >> Rich Brown writes: > >> > >> >> On Oct 23, 2019, at 5:54 AM, >> erik.taraldsen@telenor.com>> wrote: > >> >> > >> >> If you could influence the 4G vendors to de-bloat their equipment, > >> >> would you recommend BQL, L4S or codel/cake? > >> > > >> > I've been enjoying this discussion and wonder whether the work going > >> > on in the make-wifi-fast > >> > (https://lists.bufferbloat.net/pipermail/make-wifi-fast/) is > relevant. > >> > > >> > I only have a 30,000 foot understanding of this work, but it seems t= he > >> > use of AQL (Airtime Queue Limit) maps better onto the vagaries of > >> > 4G/5G radio transmissions than BQL. Specifically, having a measureme= nt > >> > of the actual time it takes to transmit a packet might give addition= al > >> > information about the current link speed, with the potential for > >> > adjusting the codel target, etc. > >> > >> Indeed, I suspect something like AQL would work for LTE as well. At th= e > >> right level; think this might need to be in the firmware (which in tur= n > >> could push back on the host). > >> > >> > Separately, I also wonder whether the Air Time Fairness algorithm > >> > might provide a benefit if the cellphone tower station manufacturers > >> > chose to get into the game. > >> > >> LTE base stations already does TDMA scheduling (which they can do easi= ly > >> because they are centralised and own the license band); airtime fairne= ss > >> is about getting the same benefits into WiFi that LTE has been enjoyin= g > >> from the get-go :) > >> > > > > There is one main difference between ATF and the kind of TDMA > > realized by an LTE scheduler (but also HSDPA/HSUPA). > > Toke correct me if I'm wrong. > > > > The current ATF scheduler for WiFi does airtime-DRR based on the > > current PHY rates, is that right? Side question, how do you measure > > current? > > s/current/last/. The ATF scheduler does everything after-the-fact, by > accounting the actual TX time of a transmission after it has completed. > So no fancy scheduling or prediction tricks are needed; with the > tradeoff being coarser granularity of the fairness achieved (i.e., there > can be unfairness on short timescales). > > In the airtime queue limit work that's ongoing, we do ahead-of-time > airtime estimation to limit queueing in firmware. But this still just > uses the last TX rate recorded for the given station to calculate the > estimate. > > > In LTE TDMA makes use of what is called multi-user diversity gain > > by scheduling users when they are at their relative best radio conditio= n. > > Typically the user with the best current radio condition NORMALIZED > > over the average radio conditions. The average can be based on a > > moving average or a sliding window. This is the case of the widely used > > David Tse's proportional fair scheduler. > > > > This means that TDMA is still in place to share air-time fairly but the > > scheduler will tend to avoid bad radio conditions. > > > > From a theoretical point of view if you do that the total capacity > > of the AP can increase with the number of stations (I think > logarithmically) > > as the scheduler surfs across radio quality peaks and not the average > radio > > quality. Very smart. > > > > In LTE this is doable as the scheduling time slot is 1ms and the > > feedback channel is as fast. Not all TDMAs are equal. > > Yeah, the LTE MAC is pretty cool. Just a shame that the equipment is so > expensive :( > It looks like there is a positive correlation between the size of the specifications and the cost to build the associated product :) > > > Maybe the current scheduler in WiFi can be improved to do that. Maybe. > > I think 802.11ax is going in that direction. Nothing nearly as advanced, > but at least there's the possibility of a dedicated back channel... > That's right. ax does much better. > > -Toke > > --00000000000035a95d0595a78cab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 24, 2019 at 11:34= AM Toke H=C3=B8iland-J=C3=B8rgensen <toke@redhat.com> wrote:
Luca Muscariello <muscariello@ieee.org> writes:

> On Wed, Oct 23, 2019 at 2:27 PM Toke H=C3=B8iland-J=C3=B8rgensen <<= a href=3D"mailto:toke@redhat.com" target=3D"_blank">toke@redhat.com>=
> wrote:
>
>> Rich Brown <richb.hanover@gmail.com> writes:
>>
>> >> On Oct 23, 2019, at 5:54 AM,<erik.taraldsen@telenor.com <m= ailto:
>> er= ik.taraldsen@telenor.com>> wrote:
>> >>
>> >> If you could influence the 4G vendors to de-bloat their e= quipment,
>> >> would you recommend BQL, L4S or codel/cake?
>> >
>> > I've been enjoying this discussion and wonder whether the= work going
>> > on in the make-wifi-fast
>> > (https://lists.bufferbloat.net/= pipermail/make-wifi-fast/) is relevant.
>> >
>> > I only have a 30,000 foot understanding of this work, but it = seems the
>> > use of AQL (Airtime Queue Limit) maps better onto the vagarie= s of
>> > 4G/5G radio transmissions than BQL. Specifically, having a me= asurement
>> > of the actual time it takes to transmit a packet might give a= dditional
>> > information about the current link speed, with the potential = for
>> > adjusting the codel target, etc.
>>
>> Indeed, I suspect something like AQL would work for LTE as well. A= t the
>> right level; think this might need to be in the firmware (which in= turn
>> could push back on the host).
>>
>> > Separately, I also wonder whether the Air Time Fairness algor= ithm
>> > might provide a benefit if the cellphone tower station manufa= cturers
>> > chose to get into the game.
>>
>> LTE base stations already does TDMA scheduling (which they can do = easily
>> because they are centralised and own the license band); airtime fa= irness
>> is about getting the same benefits into WiFi that LTE has been enj= oying
>> from the get-go :)
>>
>
> There is one main difference between ATF and the kind of TDMA
> realized by an LTE scheduler (but also HSDPA/HSUPA).
> Toke correct me if I'm wrong.
>
> The current ATF scheduler for WiFi does airtime-DRR based on the
> current PHY rates, is that right? Side question, how do you measure > current?

s/current/last/. The ATF scheduler does everything after-the-fact, by
accounting the actual TX time of a transmission after it has completed.
So no fancy scheduling or prediction tricks are needed; with the
tradeoff being coarser granularity of the fairness achieved (i.e., there can be unfairness on short timescales).

In the airtime queue limit work that's ongoing, we do ahead-of-time
airtime estimation to limit queueing in firmware. But this still just
uses the last TX rate recorded for the given station to calculate the
estimate.

> In LTE TDMA makes use of what is called multi-user diversity gain
> by scheduling users when they are at their relative best radio conditi= on.
> Typically the user with the best current radio condition NORMALIZED > over the average radio conditions. The average can be based on a
> moving average or a sliding window. This is the case of the widely use= d
> David Tse's proportional fair scheduler.
>
> This means that TDMA is still in place to share air-time fairly but th= e
> scheduler will tend to avoid bad radio conditions.
>
> From a theoretical point of view if you do that the total capacity
> of the AP can increase with the number of stations (I think logarithmi= cally)
> as the scheduler surfs across radio quality peaks and not the average = radio
> quality. Very smart.
>
> In LTE this is doable as the scheduling time slot is 1ms and the
> feedback channel is as fast. Not all TDMAs are equal.

Yeah, the LTE MAC is pretty cool. Just a shame that the equipment is so
expensive :(

It looks like there is a= positive correlation between the size
of the specifications and the= cost to build the associated product :)


=C2=A0

> Maybe the current scheduler in WiFi can be improved to do that. Maybe.=

I think 802.11ax is going in that direction. Nothing nearly as advanced, but at least there's the possibility of a dedicated back channel...
=

That's right. ax does much better.
=C2=A0

-Toke

--00000000000035a95d0595a78cab--