[Ecn-sane] [tsvwg] Comments on L4S drafts

[De Schepper, Koen (Nokia - BE/Antwerp)]

All,

We have the testbed running our reference kernel version 3.19 with the drop patch. Let me know if you want to see the difference in behavior between the “good” DCTCP and the “deteriorated” DCTCP in the latest kernels too. There were several issues introduced which made DCTCP both more aggressive, and currently less aggressive. It calls for better regression tests (for Prague at least) to make sure it’s behavior is not changed too drastically by new updates. If enough people are interested, we can organize a session in one of the available rooms.

Pete, Jonathan,

Also for testing further your tests, let me know when you are available.

Koen.

From: Pete Heist <pete at heistp.net>
Sent: Monday, July 22, 2019 9:48 PM
To: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper at nokia-bell-labs.com>
Cc: Jonathan Morton <chromatix99 at gmail.com>; Bob Briscoe <in at bobbriscoe.net>; ecn-sane at lists.bufferbloat.net; Black, David <David.Black at dell.com>; tsvwg at ietf.org; Dave Taht <dave at taht.net>
Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts


On Jul 22, 2019, at 2:15 PM, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper at nokia-bell-labs.com<mailto:koen.de_schepper at nokia-bell-labs.com>> wrote:

- related to the flent testing, you might have expected to find big differences, but both measurements showed exactly the same results. I understood you need to extent your tools to get more measurement parameters included which were missing compared to ours.

On this point, this morning the ability to start multiple ping flows with different tos values for each was already added to flent (thanks to Toke), so that we can measure inter-flow latency separately for the classic and L4S queues. We added a few related plots to use this new feature.

Since 104, development and testing of SCE has been our focus, but work on testing and interop with L4S has begun. We have built the TCP Prague and sch_dualpi2 repos for use in our testbed. Some documentation on setup, including which kernels from which repos need to be deployed in which part of a dumbbell setup, and for example, what if any configuration is, like new sysctls or sysctl values, could be helpful. We have added some documentation to the README of our repo (https://github.com/chromi/sce/).

To editorialize a bit, I think we’re both aware that testing congestion control can take time and care. I believe that together we can figure out how to improve congestion control for people that use the Internet, and the different ways that they use it. We’ll try to think about them first and foremost. :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190725/dc3c44ff/attachment.html>