From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 49F8F3BA8E for ; Fri, 29 Jun 2018 11:45:21 -0400 (EDT) Received: by mail-it0-x231.google.com with SMTP id 188-v6so3461854ita.5 for ; Fri, 29 Jun 2018 08:45:21 -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=KKh2B2EqkuOB+R3D14vH8dQsnRkk0i2ghTh2mViZ1bU=; b=jdlOGk19X7h4CGc1YXU2Zey4a79iCuLgjMn+Z2Quibwx4K6TKPE3N0z4d4XRNcELq6 /c8rnYXwqEOxC9nbj06F21OkMKgf4YSnRQD4du+Cv0WaQ0zU+3MYHYIGoEzJS94jxZOq dvSlp+I2a6t+SFbRMXyM8Cd0mugH9fkcgL0okpVH/L/Ud4F1zrptjKLO4NN++klRL1KV odus7uLfSiJqHomVP+5qkQLfk/fGDLyPhQQqqqNYYegCTJ1/1OG/8MxlTn0aR3RN3wvm LbZRpNXNAkDRBGivas5tS85mwezlFM9izI5CARGRTkMrJqAi/1YFqZDioTNrzbO1ch/9 owBQ== 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=KKh2B2EqkuOB+R3D14vH8dQsnRkk0i2ghTh2mViZ1bU=; b=U9S+TQP/wfwaHi77Hj8bhLx+XOgBMjQ1iwGTfL+kstIPP28Zl6XLI5aDbqwXLqYCfA VpNBHufdUTKwRhveHMtCbm7tXbWgnXMNIgvGyC/RPumCpaAnZWPAfjG+j6o9eKI5za8o 2DG0EY1xCdUf/bcOO80WU/0FVja3L6bB02PpW3lRGA+wYRMRyrujCDzhSKMVP0QPFSae hnR1exWgkjDQ6816Odi7eFCrdrGYqPX/Vaq/wHoic79b5WIg2JoC/+Mew3DODeNG7VrO yYH5FDQ4cBXMghKUaCFX2FutroMt+mhtJMiKSzNfZOCrjHoXzzx43g7KIPmbqpRnHxte c8zQ== X-Gm-Message-State: APt69E3tewUnmhib4B/oOLAEKgiehTpzxh+xo2TRZ1H6bQmJKgR5uwWO P20YhFFE4mJJ1RxEb3d+r4h8ChiPhhWGtnpXtD0= X-Google-Smtp-Source: AAOMgpevrAaQdeeqvwSB1uWwwOaCTxC8UxUkGShZyJf2C4Hb7GeUVPhEzKJwEEg14ZjsZyvHCSKiONHKCtGSw8vlPZI= X-Received: by 2002:a24:4e8f:: with SMTP id r137-v6mr2364733ita.9.1530287120726; Fri, 29 Jun 2018 08:45:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Jonas_M=C3=A5rtensson?= Date: Fri, 29 Jun 2018 17:45:09 +0200 Message-ID: To: Jonathan Morton Cc: bloat Content-Type: multipart/alternative; boundary="0000000000003c3e1a056fc9bc8e" Subject: Re: [Bloat] powerboost and sqm 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: Fri, 29 Jun 2018 15:45:21 -0000 --0000000000003c3e1a056fc9bc8e Content-Type: text/plain; charset="UTF-8" Hi Jonathan, thanks for the detailed analysis. Some comments: "PowerBoost" is just a trade name for the increasingly-common practice of > configuring a credit-mode shaper (typically a token bucket filter, or TBF > for short) with a very large bucket. Do you have any data indicating this is increasingly common? I believe Comcast, who introduced the trade name, stopped doing it. > The maximum inter-flow induced latency is consistently about 125ms. This > is roughly what you'd expect from a dumb FIFO that's been sized to 1x BDP, > and *much* better than typical ISP configurations to date. I'd still much > rather have the sub-millisecond induced latencies that Cake achieves, but > this is a win for the average Joe Oblivious. > Where do you get 125 ms from my results? Do you mean 25 ms? That's what the latency hovers around except for the short spikes maxing out at around 260 ms during upload. Compared to the idle latency, 25 ms means the induced latency is close to the sub-milliseconds Cake achieves (again, except for the spikes). So why the spikes? Yeah, I still do not fully get this from your explanation. Are you saying that the buffer in the shaper is 260 ms? But this doesn't look like typical bufferbloat since I don't even see it without high resolution. > Windows, I believe, increases cwnd by one packet per RTT (ie. is > Reno-like). > No, Windows 10 uses cubic tcp these days. > Yes, I would absolutely use SQM here. It'll both iron out those latency > spikes and reduce packet loss, and what's more it'll prevent > congestion-related latency and loss from affecting any but the provoking > flow(s). > Still not sure about the latency spikes but I probably agree about the packet loss. Another thing I like about sqm is that I can set it to use ecn. > IMHO, the benefits of PowerBoost are illusory. When you've got 100Mbps > steady-state, tripling that for a short period is simply not perceptible in > most applications. Even Web browsing, which typically involves transfers > smaller than the size of the bucket, is limited by latency not bandwidth, > once you get above a couple of Mbps. For a real performance benefit - for > example, speeding up large software updates - bandwidth increases need to > be available for minutes, not seconds, so that a gigabyte or more can be > transferred at the higher speed. > I think I agree. For some things, like downloading a large photo or a not so large software update, I guess it could make a small difference, although I don't know how perceptible it is. > Those latency spikes would be seen by latency-sensitive applications as > jitter, which is one of the most insidious problems to cope with in a > realtime interactive system. They coincide with momentary spikes in packet > loss (which unfortunately is not represented in dslreports' graphs) which > are also difficult to cope with. > > That means your VoIP or videoconference session will glitch and drop out > periodically, unless it has deliberately increased its own latency with > internal buffering and redundant transmissions to compensate, if a bulk > transfer is started up by some background application (Steam, Windows > Update) or by someone else in your house (visiting niece bulk-uploads an SD > card full of holiday photos to Instagram, wife cues up Netflix for the > evening). > Yes, this is a good motivation of course. Still, I will try to investigate a bit more how real those latency spikes are and how big the impact of the packet loss is. /Jonas --0000000000003c3e1a056fc9bc8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jonathan,

thanks for the detailed an= alysis. Some comments:

"PowerBoost" is just a trade name for the increasingly-common pra= ctice of configuring a credit-mode shaper (typically a token bucket filter,= or TBF for short) with a very large bucket.=C2=A0

Do you have any data indicating this is increasingly common? I bel= ieve Comcast, who introduced the trade name, stopped doing it.
= =C2=A0
The maximum inter-flow induced latency is consistently about 125ms.=C2=A0 T= his is roughly what you'd expect from a dumb FIFO that's been sized= to 1x BDP, and *much* better than typical ISP configurations to date.=C2= =A0 I'd still much rather have the sub-millisecond induced latencies th= at Cake achieves, but this is a win for the average Joe Oblivious.

Where do you get 125 ms from my results? Do you= mean 25 ms? That's what the latency hovers around except for the short= spikes maxing out at around 260 ms during upload. Compared to the idle lat= ency, 25 ms means the induced latency is close to the sub-milliseconds Cake= achieves (again, except for the spikes).=C2=A0=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> So why the spikes?

Yeah, I still do not fu= lly get this from your explanation. Are you saying that the buffer in the s= haper is 260 ms? But this doesn't look like typical bufferbloat since I= don't even see it without high resolution.
=C2=A0
Windows, I believe, increases cwnd by one packet = per RTT (ie. is Reno-like).

No, Windows= 10 uses cubic tcp these days.
=C2=A0
Yes, I would absolutely use SQM here.=C2=A0 It'll both iron ou= t those latency spikes and reduce packet loss, and what's more it'l= l prevent congestion-related latency and loss from affecting any but the pr= ovoking flow(s).

Still not sure about t= he latency spikes but I probably agree about the packet loss. Another thing= I like about sqm is that I can set it to use ecn.
=C2=A0
IMHO, the benefits of PowerBoost are illusory.=C2=A0 When you've got 10= 0Mbps steady-state, tripling that for a short period is simply not percepti= ble in most applications.=C2=A0 Even Web browsing, which typically involves= transfers smaller than the size of the bucket, is limited by latency not b= andwidth, once you get above a couple of Mbps.=C2=A0 For a real performance= benefit - for example, speeding up large software updates - bandwidth incr= eases need to be available for minutes, not seconds, so that a gigabyte or = more can be transferred at the higher speed.

I think I agree. For some things, like downloading a large photo or a= not so large software update, I guess it could make a small difference, al= though I don't know how perceptible it is.
=C2=A0
Those latency spikes would be seen by latency-sens= itive applications as jitter, which is one of the most insidious problems t= o cope with in a realtime interactive system.=C2=A0 They coincide with mome= ntary spikes in packet loss (which unfortunately is not represented in dslr= eports' graphs) which are also difficult to cope with.

That means your VoIP or videoconference session will glitch and drop out pe= riodically, unless it has deliberately increased its own latency with inter= nal buffering and redundant transmissions to compensate, if a bulk transfer= is started up by some background application (Steam, Windows Update) or by= someone else in your house (visiting niece bulk-uploads an SD card full of= holiday photos to Instagram, wife cues up Netflix for the evening).

Yes, this is a good motivation of course. Sti= ll, I will try to investigate a bit more how real those latency spikes are = and how big the impact of the packet loss is.

/Jon= as=C2=A0
--0000000000003c3e1a056fc9bc8e--