From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 9D9E83B29E for ; Sat, 28 Mar 2020 18:22:18 -0400 (EDT) Received: by mail-qk1-x731.google.com with SMTP id x3so15049778qki.4 for ; Sat, 28 Mar 2020 15:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rBWXkHvUg3dA7lSw+cn4Tlk0xDn16fVoUeJPyOemexg=; b=r0dNAKku19dmovmMJxiIrdEuHpA2G1ZiMOnBcbgbra5BT8jDSTXkdK/JrOcE3B/2T+ vJkwkQbwvely9G/XMwK1tA8ZxMAgJblKs6a0ny2PyuAu/6JW2AESGuLaON79gX5NrEdh qwXmrbZ+i5QHlKbb2LKEWbEXu+i4mnoR21waQe4LNf9Qxa4HuvJOhjiEXoqkseIw8Zzk 00EKFHI8jC8TKei/XH4ee7FfQ7pLLi9wB7xTVPWPKKUFDzTKB+C+fOIoYTm1eOpCSOpS yOwYV6UVI87LLYWaRS9uT8LGSMWb2hjW70ZDjrj/6v//hetL5h5edZ+sMJiHaDC/PbeF rIyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rBWXkHvUg3dA7lSw+cn4Tlk0xDn16fVoUeJPyOemexg=; b=hXM907exK0/j3+bVPYcQV8JBtHT6CAS65946RAPsF+LwJRratK09tqAXBiBmp+MvKJ +hdOH/qgp/ic6UffpkfAnammTkSKKuT7oCo5sAWQ4WSlzf+2lQrswIIzNQoBVOky0kPh afsWIB/lzGSRSpSxySiTcD1m8Az2b4gffdDOAtOQVwNY1+lr48nNViBTQyohP+6JdULH IReEXF0lSGvCf1hVyzVtGEa5nHe9aRBQRWC/5Zz3lOGRz8mRCCG2UCin5+VI7X4EkMXe whGQSMuP7WNmanwbEdZzH0uDLAjAg821NoGISDMnWldQHlARBhe9j//qIvJF2L2MQRn0 NM8Q== X-Gm-Message-State: ANhLgQ2xBYQvoWUD8wr7DhTQ5oVCx1mABjsaNS/mxqoe/haIdGPmNsFQ 3Dw3u3q1VfHvFw8BIudaU+8kmyWPUgqivhbCdq8= X-Google-Smtp-Source: ADFU+vvdM8zX26Q7rtYhXB5nZ82neI3Fro9K7mlCu+jPDfa9WDXT3oH7+US+r6t8ZTcGgdfPT7hYh7Ya/wGlwi1fmlQ= X-Received: by 2002:a37:cd0:: with SMTP id 199mr5848638qkm.189.1585434138164; Sat, 28 Mar 2020 15:22:18 -0700 (PDT) MIME-Version: 1.0 References: <0E492E75-A6AE-46A6-A92D-F6BDD6511AF4@gmx.de> In-Reply-To: <0E492E75-A6AE-46A6-A92D-F6BDD6511AF4@gmx.de> From: Aaron Wood Date: Sat, 28 Mar 2020 15:22:07 -0700 Message-ID: To: Sebastian Moeller Cc: =?UTF-8?Q?Dave_T=C3=A4ht?= , bloat Content-Type: multipart/alternative; boundary="0000000000009ec2fd05a1f1a656" Subject: Re: [Bloat] fcc's coronovirus guidelines 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: Sat, 28 Mar 2020 22:22:18 -0000 --0000000000009ec2fd05a1f1a656 Content-Type: text/plain; charset="UTF-8" On Sat, Mar 28, 2020 at 7:30 AM Sebastian Moeller wrote: > > > On Mar 27, 2020, at 22:41, Dave Taht 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... --0000000000009ec2fd05a1f1a656 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Mar 28, 2020 at 7:30 AM Sebas= tian 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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sorry to disagree a bit, but I consider this to= be conceptually decent advice. If a problem can be avoided by a simple beh= avioral change, recommending that change seems quite reasonable. Sure, the = crowd here on the bloat list, probably has sufficiently competent AQM* in p= lace to not having to change their behavior, but for the majority of links/= users/home networks this recommendation seems reasonable. And certainly eas= ier to implement by everybody that recommending to deploy competent AQM...<= br>

I will say that my network (Cake on ups= tream, 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=C2=A0data uploads/downlo= ads at the same time from "the cloud").=C2=A0 Usually, my VC does= n'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 m= odem itself.=C2=A0 If it doesn't move, it usually gets ethernet, not wi= fi, 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.

<= /div>
Some are turning on AQM if it was available, but not on by defaul= t, some are bulk replacing hardware, but I wouldn't want to try to refl= ash a modem with OpenWRT right now, not without a spare, as internet is key= to us being able to get our work done...
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Also there are quite some misconceptions floati= ng around, even in tech-circles, about the effect of "cyclically pumpe= d" traffic like "adaptive" streaming on concurrent latency s= ensitive flows on standard consumer-grade internet access links. Quite a nu= mber of voices in Germany criticized the EU/BEREC as uninformed and incompe= tent=C2=A0 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.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alas, on non-fq'd links adaptive streaming = is not free of side-effects, but causes cyclic latency increases on the lin= k that sufficiently latency sensitive traffic will expose. So far, it only = were on-line twitch-type gamers that noticed this but both remote desktop a= nd video conferencing applications are latency sensitive enough that the ne= wly delegated to home-office crowd takes note as well.

Oh, and they are, at least in my office...
=C2=A0=


Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian


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

I doub= t it's the _right_ device, as Jonathan pointed out.=C2=A0 I think in mo= st homes, it's the router/AP, CM, or CMTS that's the culprit.
=
=C2=A0

**) What happened in reality, is that the EU/BEREC informed European ISPs u= nder 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 curren= t circumstances). Most major video streaming sources understood that correc= tly 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 w= ith actual overloads, and economically crafty by the content side to realiz= e that voluntary reductions keep the control over the "how" in th= eir court. So, well played by both sides ;)

=
From this, and my conversations with friends in the policy side of fib= er in the EU, I realize just how much better the EU has managed connectivit= y than the US has...
--0000000000009ec2fd05a1f1a656--