From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 AE10A3CB35 for ; Mon, 10 Aug 2020 08:57:26 -0400 (EDT) Received: by mail-qt1-x844.google.com with SMTP id o22so6559177qtt.13 for ; Mon, 10 Aug 2020 05:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=WRrxiPGLcPYLVmqYy/Gsxh9QyeiFj0UM5NNSmtgXWdA=; b=bzNbofSbo2zkTtV/oZHTkNz6e7lj24JLiESs5+jT07b14OAK896F7YHbeJv6EH0QYD 68+XQmQwm8ZUF8kq9YMU8AyVohpXZOweFgirF8OXKzFoFC3U+UizO6CWIgz408KPP8DW Mp/mbm2UwblNpTbVjZA3KMWV3DEN/2SLYFuGu97/PsqQHbMhuwmuBdEFVFmEsupei5PR XLfypx3St/XOV+qMbG1fNi7e5727JhCEfxGdJ5uEeD0xfL/wc3maMY+MfOsU2YJU1fOX YCbXydJE/NUy77E4jmFElrKL0iYdT6yu+pP6lyARIw7K/NxGECMb/qw0vG6fH+RHYs1t ejGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=WRrxiPGLcPYLVmqYy/Gsxh9QyeiFj0UM5NNSmtgXWdA=; b=OKziF+MS229eHL17ImvjrvmI8X/m+mTsfZpTcDaI5WwCmSfqxLN3lwLbKXy8quWbgM ytk/v5jQfGtpTJU3vPDdFIlAoI3gbMIZT3aVol75q/e9Dp/KG9/rRm/r0WkwsH9Somaf x+axFpCxequE6BKRvltEN8xT2efo/Pf0rSOook+yzr2cZ6FzNoWIKf5WmKKvEhNCOzxh fa0p9FVnn1EqQRA3ZYnVeeIRzpwXSUZJQeYsuKymKYTWinrLxUuagB/Piqm39O5ZxySV /vqxB6HFWd8zd7Syq6srHSN+rgsRwhBsmCNnZWd9H4MCFC2+5hfX0wQ4hBlmXgrudx7W zVMQ== X-Gm-Message-State: AOAM533PgvGo1lzE7nMdwra02JE0jePnx4djv5eomotv1Fhjw+nNwzaL DOvDF67upczFUqUmRe08Oxc= X-Google-Smtp-Source: ABdhPJyP+wenHxYwGDr0WrZ6PdicYWqCps0eELkZIK0eG+9w/BOa4NZQ+yCFGyEUxVMBQALVsHk3WQ== X-Received: by 2002:ac8:3d92:: with SMTP id v18mr27554760qtf.104.1597064245813; Mon, 10 Aug 2020 05:57:25 -0700 (PDT) Received: from ?IPv6:2607:fea8:561f:e34d::5c53? ([2607:fea8:561f:e34d::5c53]) by smtp.gmail.com with ESMTPSA id t32sm16528709qtb.3.2020.08.10.05.57.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 05:57:24 -0700 (PDT) From: David Collier-Brown X-Google-Original-From: David Collier-Brown Reply-To: davecb@spamcop.net To: Jonathan Morton , tomh@tomh.org Cc: bloat@lists.bufferbloat.net, "dave.collier-brown@indexexchange.com" References: <225a9c89-ac76-f21e-1450-5deeb3cd23eb@tomh.org> Message-ID: <04949cee-c4de-900c-e1b1-4b1f227933eb@rogers.com> Date: Mon, 10 Aug 2020 08:57:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5A09172B9BF0ED556C4FD23A" Content-Language: en-US Subject: Re: [Bloat] How about a topical LWN article on demonstrating the real-world goodness of CAKE? 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: Mon, 10 Aug 2020 12:57:26 -0000 This is a multi-part message in MIME format. --------------5A09172B9BF0ED556C4FD23A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2020-08-09 5:35 p.m., Jonathan Morton wrote: >> Are the risks and tradeoffs well enough understood (and visible enough >> for troubleshooting) to recommend broader deployment? >> >> I recently gave openwrt a try on some hardware that I ultimately >> concluded was insufficient for the job. Fairly soon after changing out >> my access point, I started getting complaints of Wi-Fi dropping in my >> household, especially when someone was trying to videoconference. I >> discovered that my AP was spontaneously rebooting, and the box was >> getting hot. > Most CPE devices these days rely on hardware accelerated packet forwarding to achieve their published specs. That's all about taking packets in one side and pushing them out the other as quickly as possible, with only minimal support from the CPU (likely, new connections get a NAT/firewall lookup, that's all). It has the advantages of speed and power efficiency, but unfortunately it is also incompatible with our debloating efforts. So debloated CPE will tend to run hotter and with lower peak throughput, which may be noticeable to cable and fibre users; VDSL (FTTC) users might have service of 80Mbps or less where this effect is less likely to matter. > > It sounds like that AP had a very marginal thermal design which caused the hardware to overheat as soon as the CPU was under significant load, which it can easily be when a shaper and AQM are running on it at high throughput. The cure is to use better designed hardware, though you could also contemplate breaking the case open to cure the thermal problem directly. There are some known reliable models which could be collected into a list. As a rule of thumb, the ones based on ARM cores are likely to be designed with CPU performance more in mind than those with MIPS. > > Cake has some features which can be used to support explicit classification and (de)prioritisation of traffic via firewall marking rules, either by rewriting the Diffserv field or by associating metadata with packets within the network stack (fwmark). This can be very useful for pushing Bittorrent or WinUpdate swarm traffic out of the way. But for most situations, the default flow-isolating behaviour already works pretty well, especially for ensuring that one computer's network load has only a bounded effect on any other. We can discuss that in more detail if that would be helpful. I'm primarily thinking of /this week's/ version of the home router problem (;-)) Because of the degree to which we're working from home and videoconferencing, a lot of low-price, medium-performance devices are suddenly too wimpy for their new role. A (very!) draft version is up in Google docs, at https://docs.google.com/document/d/1gWKp9HqTbuHLfgD59WU4KJ8Og3eHuBtIeC7BUK0Ju9w/edit?usp=sharing Using myself as the guinea-pig, running pfifo-fast was clearly bad, fq_codel was better, and cake was good with a newish Fedora and the stock Rogers router.  It's been a while since I did rrul tests, and in any case, I think that to convince readers we need a very practical way of making it clear that they have a problem. I'm thinking that making VOIP fail might do the trick (;-)) The hard part, IMHO, is constructing a test that immediately communicates the idea that the reader has a problem, and that CAKE addresses it. Returning to the hardware question, https://evenroute.com/iqrv3 seems to be capable of handling up to ~300 Mbit/S connections, and my ISP only delivers 170 (and advertises 150, which is mildly surprising!) I just ordered one, so I'll have a 'plug in" example, along with reflashing my linksys for the umpty-thousandth time. --dave >  I suspect not enough people are aware of the later efforts of the > bufferbloat team, so I'm thinking of one or two articles, starting > with LWN and an audience of aficionados. > > The core community is aware of what we've done, but in my view we > haven't converted "grandma". Grandma, as well as a whole bunch of > ordinary engineers and partners of engineers, are dependent on > debloated performance because they're working at home now, and > competing with granddaughter playing video games while they're trying > to hold a video call. > > Right now, my colleagues at work suffer from more than a second of > bloat-related lag. They therefore tend to speak over each other on > con-calls, apologize, start again and talk over each other, again. > After a little while, the picture becomes a distinctly silly one: a > bunch of grown adults putting their hands up and waving, like little > kids in school. No-one has called out “me, me, teacher” yet, but I > expect it any time. > > I propose we show the results in terms that we can explain to Grandma, > specifically concentrating on functioning VOIP. I just upgraded to > Fedora 31, and the networking is absolutely stock, so I make a perfect > victim/guinea-pig (;-)) > > Who's interested? -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain --------------5A09172B9BF0ED556C4FD23A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2020-08-09 5:35 p.m., Jonathan Morton wrote:

Are the risks and tradeoffs well enough understood (and visible enough 
for troubleshooting) to recommend broader deployment?

I recently gave openwrt a try on some hardware that I ultimately 
concluded was insufficient for the job.  Fairly soon after changing out 
my access point, I started getting complaints of Wi-Fi dropping in my 
household, especially when someone was trying to videoconference.  I 
discovered that my AP was spontaneously rebooting, and the box was 
getting hot.

Most CPE devices these days rely on hardware accelerated packet forwarding to achieve their published specs.  That's all about taking packets in one side and pushing them out the other as quickly as possible, with only minimal support from the CPU (likely, new connections get a NAT/firewall lookup, that's all).  It has the advantages of speed and power efficiency, but unfortunately it is also incompatible with our debloating efforts.  So debloated CPE will tend to run hotter and with lower peak throughput, which may be noticeable to cable and fibre users; VDSL (FTTC) users might have service of 80Mbps or less where this effect is less likely to matter.

It sounds like that AP had a very marginal thermal design which caused the hardware to overheat as soon as the CPU was under significant load, which it can easily be when a shaper and AQM are running on it at high throughput.  The cure is to use better designed hardware, though you could also contemplate breaking the case open to cure the thermal problem directly.  There are some known reliable models which could be collected into a list.  As a rule of thumb, the ones based on ARM cores are likely to be designed with CPU performance more in mind than those with MIPS.

Cake has some features which can be used to support explicit classification and (de)prioritisation of traffic via firewall marking rules, either by rewriting the Diffserv field or by associating metadata with packets within the network stack (fwmark).  This can be very useful for pushing Bittorrent or WinUpdate swarm traffic out of the way.  But for most situations, the default flow-isolating behaviour already works pretty well, especially for ensuring that one computer's network load has only a bounded effect on any other.  We can discuss that in more detail if that would be helpful.

I'm primarily thinking of this week's version of the home router problem (;-))

Because of the degree to which we're working from home and videoconferencing, a lot of low-price, medium-performance devices are suddenly too wimpy for their new role.

A (very!) draft version is up in Google docs, at https://docs.google.com/document/d/1gWKp9HqTbuHLfgD59WU4KJ8Og3eHuBtIeC7BUK0Ju9w/edit?usp=sharing

Using myself as the guinea-pig, running pfifo-fast was clearly bad, fq_codel was better, and cake was good with a newish Fedora and the stock Rogers router.  It's been a while since I did rrul tests, and in any case, I think that to convince readers we need a very practical way of making it clear that they have a problem. I'm thinking that making VOIP fail might do the trick (;-))

The hard part, IMHO, is constructing a test that immediately communicates the idea that the reader has a problem, and that CAKE addresses it.

Returning to the hardware question, https://evenroute.com/iqrv3 seems to be capable of handling up to ~300 Mbit/S connections, and my ISP only delivers 170 (and advertises 150, which is mildly surprising!)

I just ordered one, so I'll have a 'plug in" example, along with reflashing my linksys for the umpty-thousandth time.

--dave

 I suspect not enough people are aware of the later efforts of the bufferbloat team, so I'm thinking of one or two articles, starting with LWN and an audience of aficionados.

The core community is aware of what we've done, but in my view we haven't converted "grandma". Grandma, as well as a whole bunch of ordinary engineers and partners of engineers, are dependent on debloated performance because they're working at home now, and competing with granddaughter playing video games while they're trying to hold a video call.

Right now, my colleagues at work suffer from more than a second of bloat-related lag. They therefore tend to speak over each other on con-calls, apologize, start again and talk over each other, again. After a little while, the picture becomes a distinctly silly one: a bunch of grown adults putting their hands up and waving, like little kids in school. No-one has called out “me, me, teacher” yet, but I expect it any time.

I propose we show the results in terms that we can explain to Grandma, specifically concentrating on functioning VOIP. I just upgraded to Fedora 31, and the networking is absolutely stock, so I make a perfect victim/guinea-pig (;-))

Who's interested? 



-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain
--------------5A09172B9BF0ED556C4FD23A--