Re: [Bloat] powerboost and sqm

["Jonas Mårtensson" <martensson.jonas@gmail.com>]

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

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

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