From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 0D5473CB38; Wed, 11 Dec 2019 15:10:58 -0500 (EST) Received: by mail-il1-x143.google.com with SMTP id g12so20618034ild.2; Wed, 11 Dec 2019 12:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JN1BoZCJz7yjX073tgs0X+pyAkaSugq8KzGndfUT5SQ=; b=DDVFfvwtLltD3NN+quViYt7O8NuiQiAwhZrYNySN4+EsYlqUvEyoGY1BhDVgowt0zJ dr+x9kIH766N38NjzejGcVjircyCGdYs07fC6+mjg7jG5Vz4DWQvS4mXWEqogs5FBghY ry0PjRbY5uRT0LcdOm4QwC+21GSROq685UkwYv0wM7Ik3+xAjeub85CvbhpmyvJXpofk Xg3N8Xyoa5onU4LN+XP4LQIaWVvsrhzLDPhTUtO/PpfT16Pu8FE9SeJTtmxjltlkgG8z FtEfh16ASm+pfE6SHCmvXSkGdD7ZfHK00IQC+WnbjGye5flf+K66LtfbEhmJ/eiJzJrp SA9A== 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:content-transfer-encoding; bh=JN1BoZCJz7yjX073tgs0X+pyAkaSugq8KzGndfUT5SQ=; b=pcGKJv1IRkZSkdW4DtNuhgy9tS0T1KwDRTAuQGvvpAdVTQ8dH5kPZLVYQi+aV9+v+g 00IEddgvFV6GIy/l7b2JISzzBQw3vGLD1cdOkxitLAc1Gr0MqJym/Dygrkuakx360OOk yotOTyisLnNlNR8JBkdTmB50DkmrEqLDz9ZIDcTPKFXyTtKppk68RdeuSfKQZT0BgUVD BACRcDMJtFOqY0Rnk3qrHZInjFvudj0biW9D8Ad7XUvuIfjjGW99NYnen6ZWb0PNw9sV rTQlMP29AbEH/FofGZPgjhnKqVj1kPtevut58EemASF8BLr2PwNJV1TZSJRsttJU3fj/ /f0Q== X-Gm-Message-State: APjAAAUX3oZVXWhrGRDzGxM0/b3cw4zg2dKDvJ7Sth4miipaSc56/t+G 5F7t+r5xE7P5r/KX3R1UcVEPcDjVon8UoicFbPg= X-Google-Smtp-Source: APXvYqzmUrQE5Tcbx/i9jQ0l/TGE5S245IfYKO0rGc3T5mHiunPh4P8zUzKXflxNFGXqNVmnim+thi96Qow9lc4b5Rw= X-Received: by 2002:a05:6e02:5c8:: with SMTP id l8mr4960177ils.287.1576095057214; Wed, 11 Dec 2019 12:10:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Wed, 11 Dec 2019 12:10:45 -0800 Message-ID: To: Prateesh Goyal Cc: bloat , ECN-Sane , Hari Balakrishnan , Mohammad Alizadeh , Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] abc congestion control on time varying wireless links 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: Wed, 11 Dec 2019 20:10:58 -0000 On Wed, Dec 11, 2019 at 11:54 AM Dave Taht wrote: > > On Wed, Dec 11, 2019 at 11:19 AM Prateesh Goyal wro= te: > > > > Adding Hari, Mohammad > > > > On Wed, Dec 11, 2019 at 2:17 PM Dave Taht wrote: > >> > >> https://arxiv.org/pdf/1905.03429.pdf > >> > >> the principal item of interest is section 3.1.2 where the accelerate > >> and brake concepts and math are described. > > What we have now is a string of conflicts of interest over the values > of the ecn bits, in part based > on the characteristics of the underlying link technologies. > > The DC folk want a multibit more immediate signal, for which L4S is > kind of targetted, (and SCE also > applies). I haven't seen any data on how well dctcp or SCE -style can > work on wildly RTT varying links as yet, although it's been pitched at > the LTE direction, not at wifi. > > The abc concept hasn't been tried in a DC-like environment, and while > it shows some good results for both the LTE and wifi simulations, was > not compared against the fq_codel based solution currently in linux > wifi, nor against the minstrel rate controller. > > I have plenty of data on how fq_codel + RFC3168 ecn currently works on > wifi, I like to think it's pretty good, but it's still pretty slow to > respond with just RFC3168 or drop. > > this is yet another one of those cases where unified sets of > benchmarks would help. > > And then there's, like, the actual deployment on actual devices... I > just did a string of benchmarks, tethered to my new moto 6e phone. You > saturate the download, and nearly ALL other traffic (icmp and udp) in > the upstream direction, gets starved out. > > I just did a string of benchmarks on my new LTE (I'll post these at some point) Kan Yan, Toke, and a multitude of others have committed AQL (Airtime queue limits) for the QCA ath10k 802.11ac chip to the linux kernel and it should be appearing in mainline and in openwrt soon if it hasn't already. (It already worked on the mt76, and I'm hoping we can make it work on the iwl devices, notably the new ax ones) https://lore.kernel.org/linux-wireless/20191119060610.76681-5-kyan@google.c= om/ Kan's data and post about it: https://drive.google.com/corp/drive/folders/14OIuQEHOUiIoNrVnKprj6rBYFNZ0Co= if The raw trace, parsed data in csv format and plots can be found here: https://drive.google.com/open?id=3D1Mg_wHu7elYAdkXz4u--42qGCVE1nrILV All tests are done with 2 TCP download sessions that oversubscribed the link bandwidth. With AQL on, the mean sojourn time about ~20000us, matches the default codel "target". With AQL off, the mean sojourn time is less than 4us even the latency is off the charts, just as we expected that fd_codel with mac80211 alone is not effective for drivers with deep firmware/hardware queues. Kan followed up with some 10ms vs 20 codel target data > Apologize for the late reply. Here is the test results with target set to= 10ms. > The trace for the sojourn time: > https://drive.google.com/open?id=3D1MEy_wbKKdl22yF17hZaGzpv3uOz6orTi > > Flent test for 20 ms target time vs 10 ms target time: > https://drive.google.com/open?id=3D1leIWe0-L0XE78eFvlmRJlNmYgbpoH8xZ At which point a debate kicked off on the make-wifi-list about using the 10ms target on wifi, particularly with multiple stations transmitting. https://lists.bufferbloat.net/pipermail/make-wifi-fast/2019-December/002605= .html To me, the arrival of AQL, and the applicability various AQM technologies to 802.11ac devices is kind of a whole new debate, that we simply do not have enough data on. > >> > >> -- > >> Make Music, Not War > >> > >> Dave T=C3=A4ht > >> CTO, TekLibre, LLC > >> http://www.teklibre.com > >> Tel: 1-831-435-0729 > > > > -- > Make Music, Not War > > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729 --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729