From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C5EA73CB35 for ; Thu, 24 Oct 2019 05:34:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571909674; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PWf/o1YQNZ9ZzK6UprIm4870Xv4TKCFWa9ILzkzBg1Y=; b=NM9D1PfamP0/NlVIAToKo9eNumwvxF9kY3PUaEDj974IQ93yhxPEMK4kzaMT1PJJnOMHco 7jPgeb0cHxtulOh4Ni3i2F1jQQgwcyooXqGkvG29DeqaFJryK/BpVoQjsjuW9JfLiW4GFd oIcZOorcHwn3JuWtIAqSy5o5k6Tpltg= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-146-lJjn_PLTO7-09B2b-Up7dA-1; Thu, 24 Oct 2019 05:34:32 -0400 Received: by mail-lf1-f71.google.com with SMTP id y188so3455201lfc.6 for ; Thu, 24 Oct 2019 02:34:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=PWf/o1YQNZ9ZzK6UprIm4870Xv4TKCFWa9ILzkzBg1Y=; b=LsPnkLdwQlC6g4QQ1FCWUSCCj0iFR7ItcBo934kcTIzRkwXTV1G4Fy3n36Y/urwSvU rd6HF6QwV2FI3f0x00+4J5ZPv05JKkQ1N53NGoah8/VOYcTZ66D+EoelUhDO7m/5tn8O F1/eicxwdEQjekJ1LdK/B/F+eeK+1orPNbAf56v6UPu/gVQPUgkndPa94PRm29VDIiSY uXv0I0xW1H965g0dP1FQDAVJ3JNaASYaivU5m7bMzqHcNI1azaH2qU8LdOIuyZ6ewuDh Ji0ZJz4ZyQBZ7ML09zYO5vM1ov6c4ouUlfkzrC+xg8OHbqEcvVAXa3oixGDcp1hpiiuh jFSA== X-Gm-Message-State: APjAAAV1GBKr50tTzjPIK3+7CUJ3OMu71OWwzWsUn1ef4D3kmTHsPjne sRtBQFs1gUtw2piFa1g0fNg8i75qhWho5XuuFvM5pks9+PYpdC42D09cjB2Nj7S7sgJMX7HfsUw IK2N7uSK3FKWbEo+B/UsQbys= X-Received: by 2002:a19:40c7:: with SMTP id n190mr26126449lfa.37.1571909671327; Thu, 24 Oct 2019 02:34:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqyimqphxk0n4XdYOH7g3iAjcL06XmH0pRx07WVl6J4i9Bkb/Ql8jEnd8mSy7+84L+w+dBIQZg== X-Received: by 2002:a19:40c7:: with SMTP id n190mr26126435lfa.37.1571909671092; Thu, 24 Oct 2019 02:34:31 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id t10sm5378308lfq.13.2019.10.24.02.34.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Oct 2019 02:34:30 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 280FC1804B1; Thu, 24 Oct 2019 11:34:29 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Luca Muscariello Cc: Rich Brown , bloat In-Reply-To: References: <0876C235-C6D3-42B0-9D93-114DB75D4204@gmail.com> <87d0enmyty.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 24 Oct 2019 11:34:29 +0200 Message-ID: <87y2xalc62.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: lJjn_PLTO7-09B2b-Up7dA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 09:34:34 -0000 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 the >> > use of AQL (Airtime Queue Limit) maps better onto the vagaries of >> > 4G/5G radio transmissions than BQL. Specifically, having a measurement >> > of the actual time it takes to transmit a packet might give additional >> > 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 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 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 easily >> because they are centralised and own the license band); airtime fairness >> is about getting the same benefits into WiFi that LTE has been enjoying >> 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 condition. > 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 logarithmical= ly) > as the scheduler surfs across radio quality peaks and not the average rad= io > 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 :( > 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... -Toke