[Bloat] fcc's coronovirus guidelines

[Bloat] fcc's coronovirus guidelines

[Dave Taht]

"put everyone on a schedule"... sigh

https://www.fcc.gov/home-network-tips-coronavirus-pandemic


-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

Re: [Bloat] fcc's coronovirus guidelines

[Kenneth Porter]

--On Friday, March 27, 2020 3:41 PM -0700 Dave Taht <dave.taht@gmail.com> 
wrote:

> "put everyone on a schedule"... sigh
>
> https://www.fcc.gov/home-network-tips-coronavirus-pandemic

How do we educate officials? It's not clear who we'd even address a 
correction to. Is there a bufferbloat page we can point them to?

Re: [Bloat] fcc's coronovirus guidelines

[Y]

sigh...

On Fri, 27 Mar 2020 14:41:57 -0700
Dave Taht <dave.taht@gmail.com> wrote:

> "put everyone on a schedule"... sigh
> 
> https://www.fcc.gov/home-network-tips-coronavirus-pandemic
> 
> 
> -- 
> Make Music, Not War
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


-- 
Y <intruder_tkyf@yahoo.fr>

Re: [Bloat] fcc's coronovirus guidelines

[Sebastian Moeller]

> On Mar 27, 2020, at 22:41, Dave Taht <dave.taht@gmail.com> wrote:
> 
> "put everyone on a schedule"... sigh

	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...

	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. 
	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.


Best Regards
	Sebastian


*) I wonder how well macos devices stack-up here, given that they default to fq_codel (at least over wifi)?

**) 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 ;)



> 
> https://www.fcc.gov/home-network-tips-coronavirus-pandemic
> 
> 
> -- 
> Make Music, Not War
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] fcc's coronovirus guidelines

[Jonathan Morton]

> On 28 Mar, 2020, at 4:30 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> *) I wonder how well macos devices stack-up here, given that they default to fq_codel (at least over wifi)?

That might help if the wifi link is the bottleneck, *and* if not too much buffering is done by the wifi hardware.  Otherwise the benefit will only be limited.  AQM and/or FQ has to be applied at the bottleneck; sometimes a bottleneck has to be artificially induced to implement that.

 - Jonathan Morton

Re: [Bloat] fcc's coronovirus guidelines

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 4109 bytes --]

On Sat, Mar 28, 2020 at 7:30 AM Sebastian Moeller <moeller0@gmx.de> wrote:

>
> > On Mar 27, 2020, at 22:41, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > "put everyone on a schedule"... sigh
>
>         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...
>

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).

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.

Many of my coworkers are not so lucky, and many are seeing latency spikes
or unusable networks while trying to do similar workloads.

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...


>         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.
>         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.
>

Oh, and they are, at least in my office...


>
>
> Best Regards
>         Sebastian
>
>
> *) I wonder how well macos devices stack-up here, given that they default
> to fq_codel (at least over wifi)?
>

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.


**) 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 ;)
>

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...

[-- Attachment #2: Type: text/html, Size: 5378 bytes --]