From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 E8AEF3B29E for ; Thu, 13 Feb 2020 18:49:52 -0500 (EST) Received: by mail-wr1-x432.google.com with SMTP id w12so8875532wrt.2 for ; Thu, 13 Feb 2020 15:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9ZMaXzCbJesfYcWV+EQBHnApy7wH/y3KWAK5gK8od5k=; b=JaLomNNd3m7nH54+fG+at+oPGcDCUs0DSeMrqvvhnMtxDCA535sUGzjHujBLWV/FLj X2WerewjbrAq93TiTrQ08jM4KJpLK8nC0VCEEI0akCX66DAOEOxupTDOtmTW59rFRrEE HlKrcR22+AV9lZ1icbAPIklaf/tejEd0YjwMI= 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=9ZMaXzCbJesfYcWV+EQBHnApy7wH/y3KWAK5gK8od5k=; b=uabVQPHeq35UfR33+x8tbH/0HisdY4v6x2hb81gTysXoP0ipMpLfWG40r8zz3U4TAK 4p6Cp6akmmZYxUeQfoV8QXoUmF1eyze6gdK7+SqU2AU2UjiCRX7zS+bLetT/nKHXj8vi 0uZ3BrP8i3bm3ZYK5/MBIH42/+n7g416mXKSNRxclRoYHCdF/p9msO+HfZ9BChCIOUNn FF6DKqxpoluekqkVbrTO5qCiBXM+R/j4Vi1WdIVM2cDyplWepYhINxhFGZ+c+PTrz4LQ 1gygR0bMetCtnEdCqweyMPCGkqMrQePw0JML+4ArXzFgGGE9XEFD4xt17lSbYzZKYMCT gczg== X-Gm-Message-State: APjAAAXw8BFafVH0/pCU5DgvUw/Xci+e0xRJjtCpm7shC6LE64Zux/Wx WjcP3QIZ7PT3C5DTqBB/V4LhggTmKDgh5NRLp7ez/XqP3/0= X-Google-Smtp-Source: APXvYqwlad5X8CdSfWEndo2wkyud4ClJdpaKxq4Umlp/CyFv0TimehVLfQkYXjxhY/aSMBifl5No6jC05xjzxCLsKGA= X-Received: by 2002:adf:90ee:: with SMTP id i101mr23863149wri.417.1581637791685; Thu, 13 Feb 2020 15:49:51 -0800 (PST) MIME-Version: 1.0 References: <1581552513.586428831@apps.rackspace.com> <1581559003.730714516@apps.rackspace.com> <1581632601.347810479@apps.rackspace.com> <353B0939-F7FE-49C3-B637-2AEDE00C7E5B@gmail.com> In-Reply-To: <353B0939-F7FE-49C3-B637-2AEDE00C7E5B@gmail.com> From: Bob McMahon Date: Thu, 13 Feb 2020 15:49:40 -0800 Message-ID: Subject: Re: [Make-wifi-fast] Status of the industry on over buffering at the WiFi air interface To: Jonathan Morton Cc: "David P. Reed" , Make-Wifi-fast Content-Type: multipart/alternative; boundary="000000000000bce352059e7dbe31" X-List-Received-Date: Thu, 13 Feb 2020 23:49:53 -0000 --000000000000bce352059e7dbe31 Content-Type: text/plain; charset="UTF-8" I believe this switching path is all transistors on a very low cost chip where no sw is involved. I also think some nighthawks have the ability to disable honoring the pause frames on a per port basis. The core of such a problem seems to be a 1Gb/s switch port connected to a 25Mb/s one. I've noticed when my relatives purchased XFINITY home security services they significantly increased their uplink speeds all for the security cameras. So this may be an issue per the lack of structural separation. https://www.communications.gov.au/what-we-do/internet/competition-broadband/telstras-separation-framework Back to humans getting in the way of ourselves which is all too common. Bob On Thu, Feb 13, 2020 at 2:36 PM Jonathan Morton wrote: > > On 14 Feb, 2020, at 12:23 am, David P. Reed wrote: > > > > The modem clearly is capable of giving congestion control signals to a > directly connected Ethernet path (non-wireless), by dropping packets. > > No - by sending Pause frames back. It's an increasingly-used method of > applying back pressure on an Ethernet link, in preference to dropping > packets. If it *did* drop packets, you wouldn't get an F grade for bloat. > > So the Nighthawk is correctly halting Ethernet output in response to those > frames (it's probably a function of the NIC hardware or driver), but > exercises absolutely no control over the queue that builds up as a result. > > - Jonathan Morton > > --000000000000bce352059e7dbe31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe this switching path is all transistors on a= very low cost chip where no sw is involved.=C2=A0 I also think some nighth= awks have the ability to disable honoring the pause frames on a per port ba= sis.

The core of such a problem seems to be a 1Gb/s switch port conn= ected to a 25Mb/s one.=C2=A0 I've noticed when my relatives purchased X= FINITY home security services they significantly increased their uplink spe= eds all for the security cameras.=C2=A0 So this may be an issue per the lac= k of structural separation.=C2=A0 =C2=A0https://www.communications.gov.au/what-we-do/internet/competition-b= roadband/telstras-separation-framework

Back to humans= getting in the way of ourselves which is all too common.

Bob

On Thu, Feb 13, 2020 at 2:36 PM Jonathan Morton <chromatix99@gmail.com> wrote:
=
> On 14 Feb, 202= 0, at 12:23 am, David P. Reed <dpreed@deepplum.com> wrote:
>
> The modem clearly is capable of giving congestion control signals to a= directly connected Ethernet path (non-wireless), by dropping packets.

No - by sending Pause frames back.=C2=A0 It's an increasingly-used meth= od of applying back pressure on an Ethernet link, in preference to dropping= packets.=C2=A0 If it *did* drop packets, you wouldn't get an F grade f= or bloat.

So the Nighthawk is correctly halting Ethernet output in response to those = frames (it's probably a function of the NIC hardware or driver), but ex= ercises absolutely no control over the queue that builds up as a result.
=C2=A0- Jonathan Morton

--000000000000bce352059e7dbe31--