[Cake] dslreports and inbound rate shaping

[Cake] dslreports and inbound rate shaping

[Dave Taht]

0) dslreports has a hires bufferbloat option now in their settings. It
reveals much detail that I like very much. It may not work well on
some browsers. Give it a shot, please.

1) I like that the graphic .png reports now a ping range, but I think
that is baseline latencies. but I think it would be clearer if it
showed the up and the down, under load, 98th percentile, also.

an unshaped, unmodified cable modem result in all it's horrible glory:

http://www.dslreports.com/speedtest/506793

I am puzzled as to why the idle portion of the test is so bad. Perhaps
it it measuring a new flow syn/synack/data? Or there is a need for the
lowat option on the server side so as to end the test more quickly? or
have we lost so badly there are still 10 seconds of data in flight??

(will take apart some captures when I have time)

2) the "cable" test (which keeps changing the number of flows - these
are all 16/6 flows) thoroughly breaks the sqm system's inbound rate
shaper, using cake or fq_codel (cake here), with my rate set 12% below
the delivered rate (100mbit vs 112Mbit).

http://www.dslreports.com/speedtest/509743

fq_codel:

http://www.dslreports.com/speedtest/509763

Pie:

http://www.dslreports.com/speedtest/509736

Desperate, I applied the linux policer to the inbound test, and got
huge reductions in latency, still with big bursts at a huge cost in
bandwidth.

http://www.dslreports.com/speedtest/506807

We have done too much testing with the gentler rrul test, and this
explains a lot about some bittorrent results I have got elsewhere.

So I finished writing up my thoughts on bobbie,
http://www.bufferbloat.net/projects/codel/wiki/Bobbie

which might work better than anything on the table in the face of huge
bursts like these, when the rate differential is so small.

3) I will try to add a few dslreports emulations into the netperf-wrapper suite.

Sigh. Still so much work left to perform on bufferbloat on conventional devices.

I think fixing wifi will be harder than this. Building spacecraft is
easier than this.

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Cake] [Bloat] dslreports and inbound rate shaping

[Kathleen Nichols]

On 5/21/15 9:21 AM, Jonathan Morton wrote:
> 
>> On 19 May, 2015, at 22:17, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> So I finished writing up my thoughts on bobbie, 
>> http://www.bufferbloat.net/projects/codel/wiki/Bobbie
>> 
>> which might work better than anything on the table in the face of
>> huge bursts like these, when the rate differential is so small.
> 
> I wonder if there’s any profit in making fq_codel and cake behave
> more like a policer on ingress; that would be halfway to bobbie
> without writing a lot of new code.
> 
> A reasonable test would be to try configuring fq_codel with interval
> = target = 5ms.  If that works better, I could add similar
> functionality to cake.

I'm curious why you think that would be a "reasonable test".

		Kathie
> 
> - Jonathan Morton
> 
> _______________________________________________ Bloat mailing list 
> Bloat@lists.bufferbloat.net 
> https://lists.bufferbloat.net/listinfo/bloat
> 

Re: [Cake] [Bloat] dslreports and inbound rate shaping

[Jonathan Morton]

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

When Codel is applied on the upstream side of a link, a burst arrives in it
almost instantly, and thus it only takes 5ms to detect that 5ms of queue
has developed. The interval parameter then delays action on that detection
until it is certain that it's a standing queue and not simply a burst.

When applied on the downstream side of a link, however, it takes longer for
a burst to filter through to where Codel can see it. If the shaper is set
to 90% of the link rate, it takes at least 45ms to build a 5ms queue,
during which the receiver is acking data without any clue that congestion
is in place. At 95%, it requires at least 95ms. The delay in detection
might be even longer under some circumstances.

This means Codel has to be more aggressive at responding to a detected 5ms
queue on ingress in order to provide control of the flow comparable to
egress. I'm proposing using a reduced interval parameter to do that. A
drawback is that the response will be stronger than designed, and this may
have an impact on throughput, but the same is true (and more definitely so)
of a policer.

On the one hand, this might lead to an interim solution while Bobbie gets
fleshed out. On the other, it should provide more information on whether
Bobbie is likely to work.

- Jonathan Morton

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

Re: [Cake] dslreports and inbound rate shaping

[Jonathan Morton]

> On 19 May, 2015, at 22:17, Dave Taht <dave.taht@gmail.com> wrote:
> 
> So I finished writing up my thoughts on bobbie,
> http://www.bufferbloat.net/projects/codel/wiki/Bobbie
> 
> which might work better than anything on the table in the face of huge
> bursts like these, when the rate differential is so small.

I wonder if there’s any profit in making fq_codel and cake behave more like a policer on ingress; that would be halfway to bobbie without writing a lot of new code.

A reasonable test would be to try configuring fq_codel with interval = target = 5ms.  If that works better, I could add similar functionality to cake.

- Jonathan Morton

Re: [Cake] [Bloat] dslreports and inbound rate shaping

[Kathleen Nichols]

It sounds like you are defining congestion as packets experiencing 5ms of
delay over a period of 5ms.

When you evaluate this, what metrics do you use to evaluate the effect on
the applications using this buffer?

	Kathie

On 5/21/15 8:26 AM, Jonathan Morton wrote:
> When Codel is applied on the upstream side of a link, a burst arrives in
> it almost instantly, and thus it only takes 5ms to detect that 5ms of
> queue has developed. The interval parameter then delays action on that
> detection until it is certain that it's a standing queue and not simply
> a burst.
> 
> When applied on the downstream side of a link, however, it takes longer
> for a burst to filter through to where Codel can see it. If the shaper
> is set to 90% of the link rate, it takes at least 45ms to build a 5ms
> queue, during which the receiver is acking data without any clue that
> congestion is in place. At 95%, it requires at least 95ms. The delay in
> detection might be even longer under some circumstances.
> 
> This means Codel has to be more aggressive at responding to a detected
> 5ms queue on ingress in order to provide control of the flow comparable
> to egress. I'm proposing using a reduced interval parameter to do that.
> A drawback is that the response will be stronger than designed, and this
> may have an impact on throughput, but the same is true (and more
> definitely so) of a policer.
> 
> On the one hand, this might lead to an interim solution while Bobbie
> gets fleshed out. On the other, it should provide more information on
> whether Bobbie is likely to work.
> 
> - Jonathan Morton
> 

Re: [Cake] [Bloat] dslreports and inbound rate shaping

[Jonathan Morton]

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

No - at 90% shaping on ingress, 5/5ms will trigger when the visible queue
has built up to 5ms over a continuous 50ms.  At 95%, it'll trigger at 100ms.

Remember, Codel can't see what's in the dumb FIFO on the upstream end of
the link. By the time it triggers, there's potentially a lot of queue there
that it doesn't know about and can't directly measure. That's why it has to
be more aggressive about the queue it can see.

- Jonathan Morton

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

Re: [Cake] [Bloat] dslreports and inbound rate shaping

[Aaron Wood]

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

But will it trigger at all?  If the inbound rate is say 50Mbps, and the
link to the in-home devices are over 100Mbps ethernet, will codel _ever_
see a 5ms buffer on inbound?

Or is the shaping buffering incoming packets, and creating a bundle that it
can measure?  (I don't know the internals of how htb(?) does the limiting)

-Aaron

On Thu, May 21, 2015 at 9:39 AM, Jonathan Morton <chromatix99@gmail.com>
wrote:

> No - at 90% shaping on ingress, 5/5ms will trigger when the visible queue
> has built up to 5ms over a continuous 50ms.  At 95%, it'll trigger at 100ms.
>
> Remember, Codel can't see what's in the dumb FIFO on the upstream end of
> the link. By the time it triggers, there's potentially a lot of queue there
> that it doesn't know about and can't directly measure. That's why it has to
> be more aggressive about the queue it can see.
>
> - Jonathan Morton
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>

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

Re: [Cake] [Bloat] dslreports and inbound rate shaping

[Jonathan Morton]

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

Yes, it will. That's the whole point of combining it with a shaper.

- Jonathan Morton

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

Re: [Cake] [Bloat] dslreports and inbound rate shaping

[Mikael Abrahamsson]

On Tue, 19 May 2015, Dave Taht wrote:

> 0) dslreports has a hires bufferbloat option now in their settings. It
> reveals much detail that I like very much. It may not work well on
> some browsers. Give it a shot, please.

I tried it on my DOCSIS 3 connection 250/50 with my Apple Airport Extreme 
(via gige cable):

http://www.dslreports.com/speedtest/545437

I then cranked up the flows to 32/32 (max that was allowed)

http://www.dslreports.com/speedtest/545449

I then changed to use "fiber" instead of "coax" (I have no idea what that 
changes in the test):

http://www.dslreports.com/speedtest/545457

I get occasional delay spikes but at least 95% of the time this is kept 
very well under control.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se