<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 28, 2020 at 7:30 AM Sebastian Moeller <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
> On Mar 27, 2020, at 22:41, Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<br>
> <br>
> "put everyone on a schedule"... sigh<br>
<br>
Sorry to disagree a bit, but I consider this to be conceptually decent advice. If a problem can be avoided by a simple behavioral change, recommending that change seems quite reasonable. Sure, the crowd here on the bloat list, probably has sufficiently competent AQM* in place to not having to change their behavior, but for the majority of links/users/home networks this recommendation seems reasonable. And certainly easier to implement by everybody that recommending to deploy competent AQM...<br></blockquote><div><br></div><div>I will say that my network (Cake on upstream, downstream now limited by router forwarding capability, not a shaper in the cable head-end), has utterly shrugged off the sudden WFH demands (I often have 10s to 100s of processes all demanding data uploads/downloads at the same time from "the cloud"). Usually, my VC doesn't notice, nor does anyone else in the house (including the little kid who will scream bloody murder if netflix sees a hiccup).</div><div><br></div><div>But _nothing_ is "out of the box", aside from the cable modem itself. If it doesn't move, it usually gets ethernet, not wifi, and those IoT-ish things that need wifi only, get to languish on 2.4GHz while the personal devices all get the 5GHz radio.</div><div><br></div><div>Many of my coworkers are not so lucky, and many are seeing latency spikes or unusable networks while trying to do similar workloads.</div><div><br></div><div>Some are turning on AQM if it was available, but not on by default, some are bulk replacing hardware, but I wouldn't want to try to reflash a modem with OpenWRT right now, not without a spare, as internet is key to us being able to get our work done...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Also there are quite some misconceptions floating around, even in tech-circles, about the effect of "cyclically pumped" traffic like "adaptive" streaming on concurrent latency sensitive flows on standard consumer-grade internet access links. Quite a number of voices in Germany criticized the EU/BEREC as uninformed and incompetent for "convincing" content providers to reduce streaming traffic**, based on the believe in that adaptive streaming is side-effect free as it probes the available bandwidth and would not cause congestion by itself. <br>
Alas, on non-fq'd links adaptive streaming is not free of side-effects, but causes cyclic latency increases on the link that sufficiently latency sensitive traffic will expose. So far, it only were on-line twitch-type gamers that noticed this but both remote desktop and video conferencing applications are latency sensitive enough that the newly delegated to home-office crowd takes note as well.<br></blockquote><div><br></div><div>Oh, and they are, at least in my office...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<br>
Best Regards<br>
Sebastian<br>
<br>
<br>
*) I wonder how well macos devices stack-up here, given that they default to fq_codel (at least over wifi)?<br></blockquote><div><br></div><div>I doubt it's the _right_ device, as Jonathan pointed out. I think in most homes, it's the router/AP, CM, or CMTS that's the culprit.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
**) What happened in reality, is that the EU/BEREC informed European ISPs under which conditions they would be permitted to use traffic engineering to reduce traffic load caused by streaming video (in short, as long as it is to avoid network overload and applies to all video streaming independent of source, throttling/blocking/policing is considered fair game in the current circumstances). Most major video streaming sources understood that correctly and voluntarily offered to reduce their bitrates; which strikes as both crafty politics by the EU in pro-actively laying out how ISPs could deal with actual overloads, and economically crafty by the content side to realize that voluntary reductions keep the control over the "how" in their court. So, well played by both sides ;)<br></blockquote><div><br></div><div>From this, and my conversations with friends in the policy side of fiber in the EU, I realize just how much better the EU has managed connectivity than the US has...</div></div></div>