Subject: [aqm] AQM hurts utilization with a single TCP stream?

From: Simon Barber <[email-masked]>
Date: Fri, 22 May 2015 22:54:10 -0700

For throughput to be unaffected with a single TCP-Reno stream the buffer 
must grow to contain half the BDP, since the window will be halved on 
loss. With TCP-CUBIC the buffer must contain 20% of the BDP. CoDEL will 
make it's first drop when the sojourn time remains > 5ms, so with 
TCP-Reno, if the RTT is > 10ms, then utilization will be hurt. With 
TCP-CUBIC if the RTT is > 25ms then utilization will be hurt.

Is this correct?

Simon

---

From: Jonathan Morton <[email-masked]>
Date: Sat, 23 May 2015 09:42:54 +0300

In practice, I haven't noticed any loss of throughput due to using Codel on
100ms+ RTTs. Probably most servers now use CUBIC, which contributes to that
impression. Using ECN rather than tail drops also makes the delivery
smoother.

There is a flaw in your analysis. Codel only starts dropping (or marking)
when the sojourn time has remained above target (5ms) for an entire
interval (100ms), during which time the cwnd is still growing. Thus the
peak queue occupancy is more than 5ms.

It is however probably fair to say that a single Reno flow does lose some
throughput under AQM.

- Jonathan Morton

---

From: Dave Taht <[email-masked]>
Date: Sat, 23 May 2015 00:42:53 -0700

On Fri, May 22, 2015 at 11:42 PM, Jonathan Morton <[email-masked]> wrote:
> impression.

There are only slight differences between these tcps (and everybody
just uses multiple flows to do stuff anyway)

> Using ECN rather than tail drops also makes the delivery
> smoother.

I can try some longer rtts than this (10,70). this was against the
latest cake on linux 4.1rc3.

http://snapon.lab.bufferbloat.net/~cero3/renovscubic.tgz (or the dir)

> when the sojourn time has remained above target (5ms) for an entire interval
> (100ms), during which time the cwnd is still growing. Thus the peak queue
> occupancy is more than 5ms.

yes. people keep missing the "wait for an interval" thing in codel.

> It is however probably fair to say that a single Reno flow does lose some

very clear plot of reno's classic sawtooth behavior vs cubics:

http://snapon.lab.bufferbloat.net/~cero3/renovscubic/reno.png

http://snapon.lab.bufferbloat.net/~cero3/renovscubic/cubic.png

On a 200ms rtt things look more interesting, but aqm hardly enters
into it. Reno is simply less efficient than cubic, period.

but I'll leave it to you to generate your own plots if you want, out
of the netperf-eu dataset above.

(it would be nice to be able to generate directly comparable plots vs
cc algo types, presently you can't combine these data sets in "flent")
>
> - Jonathan Morton
>
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

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

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

---

From: grenville armitage <[email-masked]>
Date: Sat, 23 May 2015 19:52:01 +1000

On 05/23/2015 15:54, Simon Barber wrote:
> For throughput to be unaffected with a single TCP-Reno stream the buffer must grow to contain half the BDP, since the window will be halved on loss. With TCP-CUBIC the buffer must contain 20% of the BDP. CoDEL will make it's first drop when the sojourn time remains > 5ms, so with TCP-Reno, if the RTT is > 10ms, then utilization will be hurt. With TCP-CUBIC if the RTT is > 25ms then utilization will be hurt.
>
> Is this correct?

I've seen something similar in physical testbed experiments. Although not exactly what you're querying, http://caia.swin.edu.au/reports/140630A/CAIA-TR-140630A.pdf is related -- Section III.B notes NewReno throughput over a codel/pie/fq_codel bottleneck is markedly worse @ 200ms RTT than @ 20ms RTT (all other things being equal). Section IV.B sees the same with CUBIC.

cheers,
gja

---

From: Simon Barber <[email-masked]>
Date: Sun, 24 May 2015 11:34:12 -0700

Good point. So the queue will be somewhat more full when the first drop 
happens. The question is will it be full enough to ensure that the cwnd 
after the drop is detected remains big enough to keep the pipe filled. 
Some math or experimentation is needed to figure this out. I suspect 
there will still be some situations where the AQM hurts single TCP 
throughput, at larger RTTs. There are some tweaks I can think of to 
avoid this.

Simon

On 5/22/2015 11:42 PM, Jonathan Morton wrote:
>
> In practice, I haven't noticed any loss of throughput due to using 
> Codel on 100ms+ RTTs. Probably most servers now use CUBIC, which 
> contributes to that impression. Using ECN rather than tail drops also 
> makes the delivery smoother.
>
> There is a flaw in your analysis. Codel only starts dropping (or 
> marking) when the sojourn time has remained above target (5ms) for an 
> entire interval (100ms), during which time the cwnd is still growing. 
> Thus the peak queue occupancy is more than 5ms.
>
> It is however probably fair to say that a single Reno flow does lose 
> some throughput under AQM.
>
> - Jonathan Morton
>

---

From: "LAUTENSCHLAEGER, Wolfram (Wolfram)" <[email-masked]>
Date: Tue, 26 May 2015 07:21:59 +0000

In steady state and single flow operation for 100% link utilization Reno requires a full BDP queue, CUBIC requires 40% BDP. This is independent of AQM or not. A tail-drop queue of the same size as CoDel's drop level performs exactly the same way in these circumstances. (I did the experiments.)

The benefit of AQM comes into play with many TCP flows in parallel. Then the queue size requirement goes down to something like BDP/sqrt(N) or even BDP/N (with N the number of flows). AQMs can earn this gain, tail-drop can not, it stays at BDP.

For CoDel + CUBIC @100ms RTT that means, it's default 5ms target does not hurt, if more than 5 to 10 flows are present. (Taking into account that it drops slightly above the target.)

Wolfram

> must grow to contain half the BDP, since the window will be halved on loss.
> With TCP-CUBIC the buffer must contain 20% of the BDP. CoDEL will make
> it's first drop when the sojourn time remains > 5ms, so with TCP-Reno, if
> the RTT is > 10ms, then utilization will be hurt. With TCP-CUBIC if the RTT is
> > 25ms then utilization will be hurt.
> 
> Is this correct?
> 
> Simon