<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi David, <div class=""><br class=""></div><div class="">Great topic, and glad you brought it up, as increasing awareness of all the goodness that de-bloating brings to end users is important, especially with all the WFH and soon, teaching/learning going on these days.</div><div class=""><br class=""></div><div class="">Background / disclosure: I’m the founder and CEO of Evenroute, so first, thank you for your order :-)  Second, please let me know if you have any questions once you get the unit. Happy to personally support you, or any member of this list.</div><div class=""><br class=""></div><div class="">Given I have access to the combined data of the deployed IQrouter fleet, I have a pretty good view of how well Cake performs in the real world, as we are on nearly every ISP domestically (US) and a surprising number of International deployments as well (even though we only market in the US).</div><div class="">as you might imagine, given our marketing, we have a huge number of users with really bad lines, or on challenging tech, like WISPs & Satellite. So we get to see the worst of the worst.</div><div class="">But interestingly enough, we also have a certain amount of users with extremely low and stable latencies with no QoS, yet they still continue to deploy their IQrouters, likely because the prior ISP-supplied device *added* latencies, and the benefits of fairness in the per-device, per-host settings in Cake, plus correctly prioritizing based on type & DSCP marks (most WiFi-calling smartphone traffic is correctly marked).</div><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" cite="mid:fdpzkz.qetg01.2wxsbn-qmf@smtp.gmail.com" class=""><blockquote type="cite" class=""><pre class="moz-quote-pre" wrap="">Are the risks and tradeoffs well enough understood (and visible enough 
for troubleshooting) to recommend broader deployment?</pre></blockquote></blockquote></div></blockquote><div class="">We’ve been deploying SQM / CAKE for 4+ years in the IQrouter, and while we have evolved a lot of our algorithms do deal with the <font color="#000000" class="">millions of permutations in configurations and settings, I’ve seen SQM and lately CAKE likewise mature, and my assessment is they are indeed ready for prime time in terms of foundational tech.</font></div></div><div class=""><font color="#000000" class="">The challenge is not the core tech, it’s accessibility. That was my take in 2015 when I first discovered it, and led to the founding of my company.</font></div><div class=""><br class=""></div><div class="">As for troubleshooting visibility, check out the Status->Ping Stats page once your IQrouter has been running for a few days. Very helpful in triaging modem and line issues. Basically its a line capacity usage monitor and ping plotter.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">but in my view we haven't converted "grandma".</blockquote><div><br class=""></div><div>Because until I produced a product with zero user configuration requirements (relative to QoS), ‘grandma’ was never a viable user.</div><div>Back story: I live in a large (3,000 homes) development in a rural area, most residents are retired professionals and DSL was the only choice up until recently, so a bunch of non-technical grandma's and grandpas are my neighbors. The IQrouter was developed to meet the needs of that audience. Grandma should be able to deploy in 15 minutes and have a de-bloated DSL connection that got rid of the 5,000ms+ lag spikes. So initial config workflow, and all the tuning and dynamic line adaptation were largely born of dealing with my local needs.</div><div><br class=""></div><div>Funny enough, our focus on non-techie usability led to a skeptical backlash from some ’techies’, who find our marketing messaging and simple UI too off-putting for them. Even though we do expose the full native UI for OpenWRT under the ‘Advanced Menus’ option. Heck, you can even instal OpenWRT packages on this thing.</div><div>Smart techies love though, a recent IT guy wrote in response to our support team letting him know about OpenWRT support was: "<span style="color: rgb(153, 0, 0); font-size: 9pt;" class="">Now, I know that this really is the </span><b style="color: rgb(153, 0, 0); font-size: 9pt;" class=""><u class="">best router</u></b><span style="color: rgb(153, 0, 0); font-size: 9pt;" class=""> for
all consumers to use in their homes!</span>”. We made his WISP service usable.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><p class="">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.</p></div></blockquote><div class=""><div class=""><p class="">Big time. As noted above, it not just the CPE devices, it’s the congestion on the backhauls that causes issues, and it’s everything from DSL (slammed DSLAMs are endemic) to cable systems with oversubscribed local loops and congested CMTS backhaul. Hell, even fiber to the home ISPs manage to have variable capacity (and bloat) in the evenings.</p><div class="">Traffic management is a requirement these days.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="">I propose we show the results in terms that we can explain to Grandma, specifically concentrating on functioning VOIP.</blockquote></div></blockquote><br class=""></div><div class="">This is desperately needed, as there need to be more points of proof and articles outlining the problem, and the impacts of resolving it with effective traffic management.</div><div class=""><br class=""></div><div class="">Stuff like this article from Jim Gettys on the needs of teachers. BTW- he calls out the IQrouter as his ‘Go to’ recommendation for non-techies. He runs one himself and gave one to his non-techie brother. <a href="https://gettys.wordpress.com/2020/04/22/bufferbloat-in-action-due-to-covid-19/" class="">Bufferbloat in Action due to Covid-19</a></div><div class=""><br class=""></div><div class="">More comments on other response later, got work to do ;-)</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Jonathan Foulkes</div><div class=""><br class=""></div></div></div></div><div><br class=""></div><div><blockquote type="cite" class=""><div class="">On Aug 10, 2020, at 8:57 AM, David Collier-Brown <<a href="mailto:davecb.42@gmail.com" class="">davecb.42@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
  
  <div class=""><p class="">On 2020-08-09 5:35 p.m., Jonathan Morton wrote:<br class="">
    </p>
    <blockquote type="cite" cite="mid:fdpzkz.qetg01.2wxsbn-qmf@smtp.gmail.com" class="">
      <blockquote type="cite" class="">
        <pre class="moz-quote-pre" wrap="">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.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">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.</pre>
    </blockquote><p class="">I'm primarily thinking of <i class="">this week's</i> version of the home
      router problem (;-)) <br class="">
    </p><p class="">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.</p><p class="">A (very!) draft version is up in Google docs, at
<a class="moz-txt-link-freetext" href="https://docs.google.com/document/d/1gWKp9HqTbuHLfgD59WU4KJ8Og3eHuBtIeC7BUK0Ju9w/edit?usp=sharing">https://docs.google.com/document/d/1gWKp9HqTbuHLfgD59WU4KJ8Og3eHuBtIeC7BUK0Ju9w/edit?usp=sharing</a></p><p class="">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 (;-))</p><p class="">The hard part, IMHO, is constructing a test that immediately
      communicates the idea that the reader has a problem, and that CAKE
      addresses it. <br class="">
    </p><p class="">Returning to the hardware question, <a class="moz-txt-link-freetext" href="https://evenroute.com/iqrv3">https://evenroute.com/iqrv3</a>
      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!)</p><p class="">I just ordered one, so I'll have a 'plug in" example, along with
      reflashing my linksys for the umpty-thousandth time.<br class="">
    </p><p class="">--dave<br class="">
    </p><div class="">
      <br class="webkit-block-placeholder"></div><blockquote type="cite" class=""> 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.
        <br class="">
        <br class="">
        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.
        <br class="">
        <br class="">
        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.
        <br class="">
        <br class="">
        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 (;-))
        <br class="">
        <br class="">
        Who's interested?
      </blockquote>
      <br class=""><div class=""><br class="webkit-block-placeholder"></div><p class=""><br class="">
    </p><p class=""><br class="">
    </p>
    <pre class="moz-signature" cols="72">-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
<a class="moz-txt-link-abbreviated" href="mailto:davecb@spamcop.net">davecb@spamcop.net</a>           |                      -- Mark Twain
</pre>
  </div>

_______________________________________________<br class="">Bloat mailing list<br class=""><a href="mailto:Bloat@lists.bufferbloat.net" class="">Bloat@lists.bufferbloat.net</a><br class="">https://lists.bufferbloat.net/listinfo/bloat<br class=""></div></blockquote></div><br class=""></div></body></html>