From: Aaron Wood <woody77@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: "Dave Täht" <dave.taht@gmail.com>, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] fcc's coronovirus guidelines
Date: Sat, 28 Mar 2020 15:22:07 -0700 [thread overview]
Message-ID: <CALQXh-PBUVijixFmpSCk9YqKvEwULw2g1pt7QruAWmnQpP-Tdg@mail.gmail.com> (raw)
In-Reply-To: <0E492E75-A6AE-46A6-A92D-F6BDD6511AF4@gmx.de>
[-- 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 --]
prev parent reply other threads:[~2020-03-28 22:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 21:41 Dave Taht
2020-03-28 3:04 ` Kenneth Porter
2020-03-28 13:01 ` Y
2020-03-28 14:30 ` Sebastian Moeller
2020-03-28 14:38 ` Jonathan Morton
2020-03-28 22:22 ` Aaron Wood [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALQXh-PBUVijixFmpSCk9YqKvEwULw2g1pt7QruAWmnQpP-Tdg@mail.gmail.com \
--to=woody77@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=moeller0@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox