From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1178B3B2A4 for ; Thu, 24 Oct 2019 10:02:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571925742; 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=SJOP73nrMnfnbqzhyG21GFCzA5Vs65jnPEriAGDN2iQ=; b=jAMoUmiPmVruJTg+vqKIE+VJZg/2J1JtCjSGZ9lhXT2vzJYmYRku7idyLjgIBm95DhaIzz /nE+LmHRM4jJWQv+MW3D9qDJQmGhfHRc77eQTrD9R6VdSwPqn1QeRuhRa6/9yV5kYTgSnE P0h0F1f3vhR+wiR94IPDPQKbIZb/vuc= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-30-2xzNWCxeMRa1r_9c2BWlNQ-1; Thu, 24 Oct 2019 10:02:13 -0400 Received: by mail-wr1-f72.google.com with SMTP id j14so12622582wrm.6 for ; Thu, 24 Oct 2019 07:02:13 -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=oDvggFnxYk12VIv622ykhEumiPfsNguGjJ45jhA1w1A=; b=LcHEygZLrVHSX9XNtm99fzz9ea3kGiR0aEwm3PM7w5IwntSbrbizNz5Vp3LobNEx7A uXp4fH4/LHNpO1RB3ZL/K8YiT28GPHEVf0HFzvg0jAx4BmxjeJo0aR7o16+DUwoAN/Tm IKClgkiaWwm0U+Hrl8T6l9+OgyabkyzagDOT0YvIju0EHfZwiRXvNgNTJPTRERS/5Zzz oN+pJKFZrIPBTapmBDTAxIBqAfInTNTv4tYTNPT3qqcikPeJMM4rIUkWQWj6eKpiq3f9 fC8j7aAE8tY0UsMZnJD6N26yvrVfP+tq4YgfRXgKerHzBHH2wBdrFIK6gqiOOh4y8iFd iTUA== X-Gm-Message-State: APjAAAVZ2OdFEUtG/Ke8053DZDVnLxZEj3R8P+5L+R4EKwRguQv2T5me kbc+l6HNBu04vf0s5ULFZTJne7GxHnPKg7S1vmtaf8Xb1RpP6w/5oNMCF05ulDMsJp0PO/tkNY/ zb546MzXpoVPpAEQuQTbrh2A= X-Received: by 2002:a5d:53c1:: with SMTP id a1mr3892306wrw.243.1571925732135; Thu, 24 Oct 2019 07:02:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqxXFkv+rL+qIP/YZR4I5/8Rjhz68TaIZUNNL3kIAijN2bjAU26KHnqs/n2stdnSl2KB2GS+wA== X-Received: by 2002:a5d:53c1:: with SMTP id a1mr3892273wrw.243.1571925731837; Thu, 24 Oct 2019 07:02:11 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id o18sm28913256wrm.11.2019.10.24.07.02.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Oct 2019 07:02:11 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 5D9B61804B1; Thu, 24 Oct 2019 16:02:10 +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> <87y2xalc62.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 24 Oct 2019 16:02:10 +0200 Message-ID: <87blu6kzrx.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: 2xzNWCxeMRa1r_9c2BWlNQ-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 14:02:23 -0000 Luca Muscariello writes: > 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 goin= g >> >> > 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 measurem= ent >> >> > of the actual time it takes to transmit a packet might give additio= nal >> >> > 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 t= he >> >> right level; think this might need to be in the firmware (which in tu= rn >> >> 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 manufacturer= s >> >> > chose to get into the game. >> >> >> >> LTE base stations already does TDMA scheduling (which they can do eas= ily >> >> because they are centralised and own the license band); airtime fairn= ess >> >> is about getting the same benefits into WiFi that LTE has been enjoyi= ng >> >> 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 >> 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 :) Hehe, yeah, funny how that works. IMO the LTE people went a little bit overboard on the complexity, though... ;) -Toke