Subject: [iccrg] Fwd: codel and coded tcp

From: Douglas Leith <[email-masked]>
Date: Fri, 2 Aug 2013 08:42:02 +0100

and this one too ...

Begin forwarded message:

> From: Douglas Leith <[email-masked]>
> Subject: codel and coded tcp
> Date: 1 August 2013 08:02:46 GMT+01:00
> To: "[email-masked] list" <[email-masked]>
> Bcc: Douglas Leith <[email-masked]>
> 
> Just following up on the comment/question yesterday regarding inter-operability of the codel queueing scheme and the coded congestion control algorithm.   Since coded tcp responds to every loss event, I don't think there is any fundamental incompatibility between the two.   
> 
> One possible issue is that its hard for tcp to measure end to end delay with an accuracy of < 5ms - due to end host o/s scheduling, TSO etc etc.   Increasing therefore the codel target value from the 5ms recommended in the draft to something like 25ms would probably be helpful to tcp flows using delay (not just coded tcp, but also e.g. compound tcp), since then the baseline queue delay would stand out clearly from measurement "noise". 
> 
> Another possible issue is that when the queue is very short relative to the path bandwidth-delay product (e.g. a 5ms of queue on a 100ms path), then the coded tcp backoff factor RTTmin/RTT will start to become quite close to 1.   It will still backoff cwnd to just empty the queue, so I would say there is no fundamental issue regarding congestion control.  But the convergence/responsiveness of the network, e.g. to new flows starting, is known to become slower as the AIMD backoff factor gets larger.   See, for example, the 2007 discussion in ToN here:
> 
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4265608
> 
> (also available as a preprint here: http://www.hamilton.ie/net/ToNbackoff.pdf)
> 
> In the past, slower convergence rate doesn't seem to have been a big issue for most folks, so perhaps this is a non-issue.  If it is, a quick fix might be to clamp the backoff factor to be at least e.g. 0.8 or 0.9.  That will carry a throughput cost on links with a short queue and on lossy links, but guarantees a certain basic convergence rate.
> 
> Of course I'd be more than happy to work with the codel folks to do some testing to look into this further.
> 
> Doug

---

From: Dave Taht <[email-masked]>
Date: Tue, 6 Aug 2013 06:00:47 -0700

>> Just following up on the comment/question yesterday regarding inter-operability of the codel queueing scheme and the coded congestion control algorithm.   Since coded tcp responds to every loss ev…

I think it's good....

>> One possible issue is that its hard for tcp to measure end to end delay with an accuracy of < 5ms - due to end host o/s scheduling, TSO etc etc.

It's hard to measure anything with an accuracy of less than < 10ms,
which is the typical scheduler latency in many OSes. I've seen
something of a move to to clock ticks in the 2.5ms range and tickless
clocks, but it still remains hard, as OS developers tend to optimize
for performance of the cpu, and (lately) battery life, and this leads
inevitably towards batching packets with TSO/GSO offloads and GRO/NAPI
like techniques on the receive path.

I have struggled greatly in trying to get accurate measurements below
1ms. Adventures with owamp indicate a need for doing real-time
scheduling at the very least (which would be easy to add).

I am no fan of tso/gso/gro in general and would like it to be off on
devices running at 100Mbit or less by default. Much modern equipment
can also run without offloads at GigE speeds (atoms can't)  (let
packets be packets!)

> Increasing therefore the codel target value from the 5ms recommended in the draft to something like 25ms would probably be helpful to tcp flows using delay (not just coded tcp, but also e.g. compound tcp), since then the baseline queue delay would stand out clearly from measurement "noise".

But why? ;) I'd rather aim for fixing the measurement... or...

If you can regularly achieve latencies below the limits of human
perception without affecting throughput, why not aim for that? Take
for example, a netflix stream in a fq_codeled world. If the data
center
is 10ms RTT away and you are only adding 5ms on the bottleneck gw,
losing and retransmitting a packet only costs another 15ms... and
nothing at all if ECN is used.

Anyway, most attempts at doing delay based tcp have "converged" at
100ms, not 25, as a hittable "target", and the presence of AQM of
nearly any sort tends to re-prioritize every delay based tcp into
being a loss based tcp:

http://perso.telecom-paristech.fr/~drossi/dataset/ledbat+aqm/ledbat+aqm-techrep.pdf

But: tho it upsets my co-authors, I don't really regard aiming at and
hitting 5ms on the bottleneck as a bad thing! It's necessary for good
voip and gaming experiences.

(Although the results I get with westwood are sometimes "interesting",
I haven't poked into it in detail, and the TCP-ledbat cc code I have
for linux appears to be badly broken in the first place)

I'd like it if torrents used less peers by default, and if slow start
was a little bit less exponential in the iw10 age. The vast majority
of real traffic I've looked at spends very little to no time in
congestion avoidance.

>> In the past, slower convergence rate doesn't seem to have been a big issue for most folks, so perhaps this is a non-issue.  If it is, a quick fix might be to clamp the backoff factor to be at leas…

Slow start needs to be harder looked at.

>> Of course I'd be more than happy to work with the codel folks to do some testing to look into this further.

Be delighted. What sort of tests/experiments would be suitable?

>>
>> Doug
>
>
> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
>

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Douglas Leith <[email-masked]>
Date: Tue, 06 Aug 2013 16:52:23 +0100

> Be delighted. What sort of tests/experiments would be suitable?

I'd suggest that for starters that we should run a test sending some data using coded tcp over a link using codel for a few different rtt's and bandwidths.   Does that seem reasonable ?

Regards,

Doug

---

From: Dave Taht <[email-masked]>
Date: Tue, 6 Aug 2013 09:13:31 -0700

> I'd suggest that for starters that we should run a test sending some data using coded tcp over a link using codel for a few different rtt's and bandwidths.   Does that seem reasonable ?

Sure. Codel and fq_codel are available now in fedora 17 and later,
ubuntu 12.4 and later, arch, almost anything else running linux 3.6
and later, fq_codel is the default in openwrt and dd-wrt, it's in a
couple commercial products now... so it should be easy to add to your
own testbed(s).

I have a reasonable ability to do delay based testing now in the yurtlab, also.

https://plus.google.com/u/0/s/%23yurtlab

What sort of test tools exist for coded tcp? What are the requirements
to use them?

-- 
Dave Täht