From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 830A93CB35 for ; Thu, 28 Dec 2017 12:48:26 -0500 (EST) Received: by mail-lf0-x22c.google.com with SMTP id j143so713409lfg.0 for ; Thu, 28 Dec 2017 09:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uHN3J9PNWHeKsnLlDSOTXs4KdgXfAPD/fIxWk3W9jLc=; b=j8O82xJ3L4c/UDTi+UerBZM+6GdsDCiXl0AdiibhXzPAMEz1CxBM/vI9MiXGDbnbJi FOj2m3ea4hiQxdAgI5jITjFhfksWqAgqX0e4a5FqNrdv/h5QYGgiZwJcBbOwmaoT/9dr D1bTzTihA7qtH3s2ySMNg+KtmX75dLpC6km04Xw5HvZ2Y7Pa4E85CQAvgr5EluRlLC9+ +4+U1mnap4bw8oIch8MHSQ3RkHtFqZd07rPuIsElhlrFhA/rBmwCHgmuoJv2OmCMPS/d 347hHqyY3LcetjBykAE3ZiAAN89a9Lfzkt6+rH2bVceFlh7eMzBaGnlFDX8nacw+fTtY aGTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uHN3J9PNWHeKsnLlDSOTXs4KdgXfAPD/fIxWk3W9jLc=; b=F46cpz+N5dhUv5nrKl0/I2pdBkD5dedOLSpEsSYSygFXvwzBQvXO7TylljPwF/yloe ITn20BAJT6NYNSonmMmu2aGKNXjvEGR4czyC8HaQ7nTyua00oDuVbe/942qrn5M8XuYu CW1NS0DYypAn4OrxzBElj/OnA20K+ef+vaMFPDvWx8elKur6r/lDSGTNCY6hEGqdZ2eQ w0G7IUqDsTm9++V0ljY55/MjeUYmPzupuyAMADlcFTaUmIoDUXCSHaIvUrOTXMaMp8cV ViYdanHVw0YeLCKCcmL73lM+CjMmoM6+5Qj47KOH7wit32LxrtIa6EABBcAsFH95z/bj +pGg== X-Gm-Message-State: AKGB3mLJKaKZEGsmZ0TjGgC1599eZPwQtjtgdcnHOV0J9FhDlt6c9Vs3 3p5G2tEu04tmyJT/QwjBPybLiBDmiA/C9/3cKZI= X-Google-Smtp-Source: ACJfBotdYm6NpnfSOSk6TFYu4LX0OtByye2kjaOKX0GpHRf/STi77GAALPo0ZSrkbbvXrJEQThYTHlgK139yHzbRZ9E= X-Received: by 10.46.97.10 with SMTP id v10mr18982976ljb.48.1514483305026; Thu, 28 Dec 2017 09:48:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.215.212 with HTTP; Thu, 28 Dec 2017 09:48:24 -0800 (PST) In-Reply-To: References: <3657B600-407D-46A5-BE00-BE0088096FA7@gmail.com> From: Benjamin Cronce Date: Thu, 28 Dec 2017 11:48:24 -0600 Message-ID: To: Ryan Mounce Cc: Rich Brown , bloat Content-Type: multipart/alternative; boundary="f403045f74086a175105616a1f13" Subject: Re: [Bloat] Win10 Updates vs cake 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: Thu, 28 Dec 2017 17:48:26 -0000 --f403045f74086a175105616a1f13 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 21, 2017 at 8:55 PM, Ryan Mounce wrote: > I've experienced this recently myself. In my case I have a 100Mbps > link from my ISP and their shaper will queue up to about 120ms worth > of packets (on top of the ~10ms baseline latency). I run cake in > ingress mode at 99.2Mbps, which has normally been enough to keep > everything in check and keep my ISP's queue empty at least in the > steady state. > > Boot up a Windows 10 PC that's been unused for a few months, let it > update and bam! 100-130ms RTT, family member's Netflix stream in the > next room stalls completely, and running a quick speedtest on a > different machine (that should get ~50% share of the link under normal > circumstances with dual-dsthost) yields about 1.2Mbps on a 100Mbps > link! I performed a quick pcap while this was happening and determined > that Windows Update had started on the order of 120 parallel HTTP > downloads from 2 different Akamai cache IPs (within my ISP's network > 20ms away). > > The 20ms jump in latency in your case just indicates that there is a > small buffer in your DSLAM, however it is still being flooded by the > parallel transfers from the CDN. > > Windows 10 probably deserves most of the blame for opening so many > parallel connections, however I think there is also some concern here > with Akamai's FastTCP not responding to congestion signals. > Without packet pacing, this is impossible. All TCP implementations have a minimum window size of 2 segments. Assuming 1500 bytes per segment, that's 3,000 bytes. Divide by RTT of 20ms for 1.2Mb/s minimum bandwidth. Because there is no pacing, aka delaying packets, the packets are sent as soon as the ACK hits. With 120 connections, that's 144Mb/s. It can't respond to congestion by slowing itself down because it's already as slow as it can go. Packet pacing is very new and is slowly being standardized. Windows just needs to reduce the number of connections. > Regards, > Ryan Mounce > > > On 22 December 2017 at 12:31, Rich Brown wrote: > > I'm using LEDE 17.01.4 on my Archer C7v2. I have a 7mbps/768kbps ADSL2+ > connection through Fairpoint. The modem stats page shows its "attainable > rates" (kbps): 13330/1272 and Rates: 8271/1181. My SQM settings are: > > > > Download: 7000 (kbps) > > Upload: 925 > > Queue Disc: Cake/piece_of_cake.qos > > Link Layer: ATM/44 bytes overhead > > Advanced Options: default > > > > I have noticed that Win10 updates cause the network connection to become > unusable for other services/people, as if I had bufferbloat. But ping times > remain stable - they jump from ~20-22 msec unloaded to 40-50 msec. > > > > Experiments I have tried: > > > > - Setting download speed to 5000 makes the connection usable for other > people, although the ping times remain about the same (40-50 msec) > > > > - Setting the download speed to 8600 still keeps ping times down, but > that really harms other people's performance. > > > > - The link rates (download and upload) seem to track the SQM setting, > measured with both YAMon and the built-in real-time graphs. I get ~6,000 > kbps with a 7000 download setting, I got ~3,000kbps at the 5000 setting. I > get ~8500 kbps after setting download to 8600. > > > > - This doesn't seem to happen when I'm downloading other kinds of files > (I haven't tried torrenting files...) Downloading non-Win10 update files > seems to leave the connection in a fairly responsive state. > > > > Any thoughts? What other experiments should I make? Thanks! > > > > Rich > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --f403045f74086a175105616a1f13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 21, 2017 at 8:55 PM, Ryan Mounce <ryan@mounce.com.au&= gt; wrote:
I've experienced th= is recently myself. In my case I have a 100Mbps
link from my ISP and their shaper will queue up to about 120ms worth
of packets (on top of the ~10ms baseline latency). I run cake in
ingress mode at 99.2Mbps, which has normally been enough to keep
everything in check and keep my ISP's queue empty at least in the
steady state.

Boot up a Windows 10 PC that's been unused for a few months, let it
update and bam! 100-130ms RTT, family member's Netflix stream in the next room stalls completely, and running a quick speedtest on a
different machine (that should get ~50% share of the link under normal
circumstances with dual-dsthost) yields about 1.2Mbps on a 100Mbps
link! I performed a quick pcap while this was happening and determined
that Windows Update had started on the order of 120 parallel HTTP
downloads from 2 different Akamai cache IPs (within my ISP's network 20ms away).

The 20ms jump in latency in your case just indicates that there is a
small buffer in your DSLAM, however it is still being flooded by the
parallel transfers from the CDN.

Windows 10 probably deserves most of the blame for opening so many
parallel connections, however I think there is also some concern here
with Akamai's FastTCP not responding to congestion signals.

Without packet pacing, this is impossible. All TCP= implementations have a minimum window size of 2 segments. Assuming 1500 by= tes per segment, that's 3,000 bytes. Divide by RTT of 20ms for 1.2Mb/s = minimum bandwidth. Because there is no pacing, aka delaying packets, the pa= ckets are sent as soon as the ACK hits. With 120 connections, that's 14= 4Mb/s. It can't respond to congestion by slowing itself down because it= 's already as slow as it can go. Packet pacing is very new and is slowl= y being standardized. Windows just needs to reduce the number of connection= s.


Regards,
Ryan Mounce


On 22 December 2017 at 12:31, Rich Brown <richb.hanover@gmail.com> wrote:
> I'm using LEDE 17.01.4 on my Archer C7v2. I have a 7mbps/768kbps A= DSL2+ connection through Fairpoint. The modem stats page shows its "at= tainable rates" (kbps): 13330/1272 and Rates: 8271/1181. My SQM settin= gs are:
>
> Download: 7000 (kbps)
> Upload: 925
> Queue Disc: Cake/piece_of_cake.qos
> Link Layer: ATM/44 bytes overhead
> Advanced Options: default
>
> I have noticed that Win10 updates cause the network connection to beco= me unusable for other services/people, as if I had bufferbloat. But ping ti= mes remain stable - they jump from ~20-22 msec unloaded to 40-50 msec.
>
> Experiments I have tried:
>
> - Setting download speed to 5000 makes the connection usable for other= people, although the ping times remain about the same (40-50 msec)
>
> - Setting the download speed to 8600 still keeps ping times down, but = that really harms other people's performance.
>
> - The link rates (download and upload) seem to track the SQM setting, = measured with both YAMon and the built-in real-time graphs.=C2=A0 I get ~6,= 000 kbps with a 7000 download setting, I got ~3,000kbps at the 5000 setting= . I get ~8500 kbps after setting download to 8600.
>
> - This doesn't seem to happen when I'm downloading other kinds= of files (I haven't tried torrenting files...) Downloading non-Win10 u= pdate files seems to leave the connection in a fairly responsive state.
>
> Any thoughts? What other experiments should I make? Thanks!
>
> Rich
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat= .net
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat

--f403045f74086a175105616a1f13--