From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp86.iad3a.emailsrvr.com (smtp86.iad3a.emailsrvr.com [173.203.187.86]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F1B563B2A4 for ; Fri, 14 Feb 2020 11:40:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1581698457; bh=AOZofH+/GschRZkkivdco2eph/bvxqNAkFup0o5tHyk=; h=Date:Subject:From:To:From; b=K/zRV1vb7dxSbQiCSLsxjeosJ2dYqmdA3mJG0fT/Io+Mc0FtD16hGWL5yc31Q8MIm zX9JM9iDfBISAtjxJ0THED9QW13VYisSVzjM3v6Y54ymsx5VLECo2tUTQJD95FWNVs g3nz5yQRGVBz+A6mOfeLLmrk8hVCbd+cREOwTgmI= Received: from app59.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A884E2498A; Fri, 14 Feb 2020 11:40:57 -0500 (EST) X-Sender-Id: dpreed@deepplum.com Received: from app59.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 14 Feb 2020 11:40:57 -0500 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app59.wa-webapps.iad3a (Postfix) with ESMTP id 93DBD60B8D; Fri, 14 Feb 2020 11:40:57 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Fri, 14 Feb 2020 11:40:57 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Fri, 14 Feb 2020 11:40:57 -0500 (EST) From: "David P. Reed" To: "Jonathan Morton" Cc: "Bob McMahon" , "Make-Wifi-fast" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <353B0939-F7FE-49C3-B637-2AEDE00C7E5B@gmail.com> References: <1581552513.586428831@apps.rackspace.com> <1581559003.730714516@apps.rackspace.com> <1581632601.347810479@apps.rackspace.com> <353B0939-F7FE-49C3-B637-2AEDE00C7E5B@gmail.com> Message-ID: <1581698457.60278267@apps.rackspace.com> X-Mailer: webmail/17.2.8-RC Subject: Re: [Make-wifi-fast] Status of the industry on over buffering at the WiFi air interface 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: Fri, 14 Feb 2020 16:40:58 -0000 Wow. I didn't know Pause Frames were becoming commonly used. That's terribl= e in general, but I guess for a dedicated box with only one path outgoing i= t is OK. A pause tells a source to stop sending to the access router. It do= esn't reflect any path dependency, so if the access router were actually a = *router* that could feed more than one outgoing link, a pause would not be = selective enough.=0A=0ASo this is a special case that moves the bufferbloat= situation into the router.=0A=0ABut I really thank you, because that resol= ves one issue being observed. That's new information for me. So thanks agai= n! Is there a "best practice RFC" aoout using Pause Frames in the Ethernet = under IP? Or is this just random hacking by hardware vendors who don't unde= rstand the end-to-end nature of congestion management?=0A=0AHowever, the ot= her issue observed, which I didn't mention, is that there is a big problem = on the downlink side, too, when using one of several different APs. I'm not= aware of how a pause frame might be utilized by a laptop using WiFi, or ev= en if there is a notion of Pause Frame in Windows WiFi drivers. (if there w= ere, then "out of control" congestion would be a property of both a Netgear= and a Linksys AP, both of which had this "download" lag under load.)=0A=0A= On Thursday, February 13, 2020 5:36pm, "Jonathan Morton" said:=0A=0A>> On 14 Feb, 2020, at 12:23 am, David P. Reed wrote:=0A>>=0A>> The modem clearly is capable of giving congesti= on control signals to a directly=0A>> connected Ethernet path (non-wireless= ), by dropping packets.=0A> =0A> No - by sending Pause frames back. It's a= n increasingly-used method of applying=0A> back pressure on an Ethernet lin= k, in preference to dropping packets. If it *did*=0A> drop packets, you wo= uldn't get an F grade for bloat.=0A> =0A> So the Nighthawk is correctly hal= ting Ethernet output in response to those frames=0A> (it's probably a funct= ion of the NIC hardware or driver), but exercises absolutely=0A> no control= over the queue that builds up as a result.=0A> =0A> - Jonathan Morton=0A>= =0A> =0A