Subject: [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

From: Bob Briscoe <[email-masked]>
Date: Fri, 15 Mar 2019 09:32:48 +0000

Forwarding to tcpm & iccrg - apologies if you were already on one of the 
lists that received this.

Olivier has been working hard on integrating the pieces of a Linux 
implementation of TCP Prague, and is close to having a version ported 
against the tip of the Linux mainline tree. This is his request for more 
people to get involved.

Bob

-------- Forwarded Message --------
Subject: 	[tcpPrague] Implementation and experimentation of TCP 
Prague/L4S hackaton at IETF104
Date: 	Wed, 6 Mar 2019 10:26:05 +0000
From: 	Tilmans, Olivier (Nokia - BE/Antwerp) 
<[email-masked]>
To: 	[email-masked] <[email-masked]>, [email-masked] 
<[email-masked]>
CC: 	[email-masked] <[email-masked]>, Joakim Misund 
<[email-masked]>, Bob Briscoe <[email-masked]>, 
Quentin De Coninck <[email-masked]>, François Michel 
<[email-masked]>, Mirja Kuehlewind 
<[email-masked]>, Maxime Piraux 
<[email-masked]>, Olga Albisser <[email-masked]>, Fabien 
Duchêne <[email-masked]>, De Schepper, Koen (Nokia - 
BE/Antwerp) <[email-masked]>

Hi all,

We'll be working on the "TCP Prague" congestion control/L4S architecture 
during the IETF-104 hackaton.
This topics aims at accelerating the work that started during the IETF93 
(coincidentally also in Prague), in order to get TCP Prague to an 
'usable' state—i.e., meet the safety requirements and have supporting 
materials (e.g., VMs, labs) to let people experiment with it. Depending 
on people's interest, prototyping something similar for QUIC is another 
possible output.

Details and links to resources/supporting drafts are available at 
https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon#tcp-prague and 
copied below.
Additionally, few topics will presented during netdev 0x13 the week before.

See you in Prague.

Best,
Olivier

Implementation and experimentation of TCP Prague/L4S

* Champion
* Olivier Tilmans <olivier.tilmans at nokia-bell-labs.com>
* Projects
* Prototype the "TCP Prague" congestion control on Linux
* Finalize the implementation of accurate ECN (draft conformance), and 
port it on Linux v5.x * Build tooling around L4S to let people 
experiment with the technology (e.g., virtual machine, or mininet labs)
* Work towards "QUIC Prague"
* Resources
* TCP Prague
* Repository — ​https://github.com/L4STeam/tcp-prague
* Requirements — 
​https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-21
* Upcoming netdev talk — 
https://netdevconf.org/0x13/session.html?talk-tcp-prague-l4s
* Accurate ECN
* Specs — ​https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07
* Implementation for Linux v4.17 — ​https://github.com/mirjak/linux-accecn
* Past netdev talk — 
https://www.netdevconf.org/2.2/session.html?kuhlewind-accecn-talk
* Paced Chirping * Repository — 
​https://github.com/JoakimMisund/PacedChirping
* Upcoming netdev talk — https://netdevconf.org/0x13/session.html?talk-chirp
* L4S architecture
* Specs — ​https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03
* DualPI2 AQM
* Specs — ​https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08
* Repository — ​https://github.com/L4STeam/sch_dualpi2_upstream
* Upcoming netdev talk — 
https://netdevconf.org/0x13/session.html?talk-DUALPI2-AQM
* RITE Project — ​https://riteproject.eu/dctth/#code
_______________________________________________
tcpPrague mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpprague

---

From: Dave Taht <[email-masked]>
Date: Fri, 15 Mar 2019 03:46:28 -0700

Bufferbloat.net's ecn-sane working group members have a co-ordinated
response to your efforts brewing but it's not ready yet. We have a
worldwide team of linux and freebsd developers co-ordinating on landing
code for our competing proposal "Some Congestion Experienced", which we
submitted to tsvwg last sunday.

That draft is under continuous revision, here:

https://github.com/dtaht/bufferbloat-rfcs/blob/master/sce/draft-morton-taht-tsvwg-sce.txt

Our Linux and FreeBSD team is also flying into prague for SCE presentations
at netdevconf and ietf.

Some background to this: after the L4S/TCP Prague/and dualpi experiments
appeared stalled out indefinitely in the IETF, and with our own frustration
with IETF processes, bufferbloat.net project members publicly formed our
own working group to look into the problems with ecn, back in august of
last year.

Its charter is here: https://www.bufferbloat.net/projects/ecn-sane/wiki/

We were unaware, until last month, that the cable industry had 16 months
back gone and formed its own private working group also, and was intending
to turn the tcp prague/l4s/dualpi IETF "experiments" into an actual DOCSIS
standard.

Our SCE proposal appears to be backward compatible with the existing
10s-100s of millions of ecn-enabled fq_codel[1] and sch_cake[2]
deployments, and doesn't require any changes to any RFC3168 tcps (or any
tcp-friendly congestion control) at all in order to basically work.
tcp-prague is subtly incompatible with that, and dualpi, more so. Our
proposal is different also, it proposes some receiver side changes in order
to get the full benefit of SCE while remaining backward compatible with the
existing meaning of the CE codepoint.

In either case, either approach essentially permanently redefines the ECT_1
codepoint incompatibly, once and for all, and for all time. This is a final
battle over the meaning of a single bit in IP, and I expect the debates to
be as difficult as the ones described in
https://www.ietf.org/rfc/ien/ien137.txt - I would really, really, really
prefer that they stay technical and not veer into politics, but I have
little hope for that.

The members of the ecn-sane working group are delighted to finally hear
that running code for tcp-prague might land this ietf, and look forward to
finally testing the whole l4s/tcpprague/dualpi architecture in conjunction
with the flent.org 's and irtt's exhaustive suite of tests and servers in
the cloud in the coming months, both against our existing, deployed,
fq_codel, fq_pie, cake and pie derived solutions and our new SCE proposal.
We hope to finally be able to write new tests for flent in particular, that
can show tcpprague off in the ways that are important to those developing
it. Flent has some basic dctcp tests, but nothing that can get down below a
20ms sample rate on modern hardware. (currently. It's easy to add tests,
flent is written in python)

We also hope that more test tools and implementations in ns2 and ns3 show
up for tcpprauge  and dualpi show up soon also, from members of those
projects.

Note: sunday's dual-pi linux submission was kicked back from the linux
networking developers due to some technical and legal problems with linux
net-next HEAD ( https://patchwork.ozlabs.org/patch/1054521/  ) , and I do
hope that a corrected version lands soon, so we can safely test it with
current versions of OpenWrt, etc.

Finally, running code. Will we find consensus?

Thx!

[1] https://tools.ietf.org/html/rfc8290
[2] sch_cake was available for 3 years out of tree and was mainlined last
august, in linux 4.19. It is partially described by "Piece of CAKE: A
Comprehensive Queue Management Solution for Home Gateways" "
https://arxiv.org/pdf/1804.07617.pdf

A second paper describing its fq_codel-derived "cobalt" AQM algorithm is
awaiting publication in a peer reviewed journal. It has been part of
openwrt and the related sqm-scripts for many years and is widely deployed
on multiple commercial products, such as those from eero and evenroute.

Cake has a docsis specific mode which we longed for cablelabs to evaluate.

On Fri, Mar 15, 2019 at 2:33 AM Bob Briscoe <[email-masked]> wrote:

> Subject: [tcpPrague] Implementation and experimentation of TCP Prague/L4S
> hackaton at IETF104
> To: [email-masked] <[email-masked]> <[email-masked]>,
> [email-masked] <[email-masked]> <[email-masked]>
> CC: [email-masked] <[email-masked]> <[email-masked]>, Joakim
> Misund <[email-masked]> <[email-masked]>, Bob Briscoe
> <[email-masked]> <[email-masked]>, Quentin De Coninck
> <[email-masked]> <[email-masked]>,
> François Michel <[email-masked]>
> <[email-masked]> <[email-masked]>,
> Maxime Piraux <[email-masked]> <[email-masked]>,
> Olga Albisser <[email-masked]> <[email-masked]>, Fabien Duchêne
> <[email-masked]> <[email-masked]>, De Schepper,
> Koen (Nokia - BE/Antwerp) <[email-masked]>
> <[email-masked]>
>
> Hi all,
>
> (coincidentally also in Prague), in order to get TCP Prague to an 'usable'
> state—i.e., meet the safety requirements and have supporting materials
> (e.g., VMs, labs) to let people experiment with it. Depending on people's
> interest, prototyping something similar for QUIC is another possible output.
>
> port it on Linux v5.x * Build tooling around L4S to let people experiment
> with the technology (e.g., virtual machine, or mininet labs)
> * Requirements — ​
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-21
> * Upcoming netdev talk —
> * Paced Chirping * Repository — ​
> https://github.com/JoakimMisund/PacedChirping
> * Upcoming netdev talk —
> https://netdevconf.org/0x13/session.html?talk-chirp
> * L4S architecture
> * Specs — ​
> https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
>

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 15 Mar 2019 17:34:35 -0400

Hi, Dave, strangely it looks like nobody has been copying TSVWG on this 
thread, even though that is where the L4S work is happening in the IETF!  :)

I just wanted to respond to one part of your message since I am 
currently acting as document shepherd for the L4S drafts in TSVWG, and 
it seems like maybe you don't know where to find all of the IETF 
materials in order to participate (based on the "stalled out 
indefinitely" comment below).  So in case it's helpful here are some 
pointers to where things are kept.

The 3 base L4S documents were adopted in the TSVWG WG, and have been 
regularly updated.  You can find the charter and milestone dates 
(currently June 2019) quite easily on the WG datatracker page: 
https://datatracker.ietf.org/group/tsvwg/about/ and of course the 
"Documents" tab there takes you to the copies of all the documents.

There have been updates on L4S and presentations/discussions at the IETF 
meetings (with minutes and charts posted to the proceedings), as well as 
L4S draft reviews and comment threads on the TSVWG list whose archives 
are under "List archive".  You can find meeting minutes and slide decks 
also readily linked from that WG page: 
https://datatracker.ietf.org/group/tsvwg/meetings/

There are source code repositories, papers, videos, etc. that the 
proponents have also made very easy to find, e.g. 
https://riteproject.eu/dctth/#code (and as linked in meeting materials).

Since we (TSVWG chairs) are looking for inputs towards WGLC readiness to 
proceed on these, hopefully this information is helpful for you.

On 3/15/2019 6:46 AM, Dave Taht wrote:
 > ...
 >
 > Some background to this: after the L4S/TCP Prague/and dualpi 
experiments appeared stalled out indefinitely in the IETF, and with our 
own frustration with IETF processes, bufferbloat.net project members 
publicly formed our own working group to look into the problems with 
ecn, back in august of last year.