From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E96543BA8E; Fri, 15 Mar 2019 06:46:40 -0400 (EDT) Received: by mail-qt1-x82c.google.com with SMTP id v20so9465696qtv.12; Fri, 15 Mar 2019 03:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=myDgnxek1A0g6mVA8qKx0rtEvTjX98r2YbQxJa5nzkk=; b=K1H4RkB5e94N/gjlVhqnm2OAsFasBNP1H8xZDeFt67VpkYwiyxLRWL9FRyiupJZn/H YWJ8WSj5LtaNkzdJuCldFFIjl4s+udDqtssCKcKPB4U1eOrNXcBO/coyQSOmI7jwe2Z/ PBV/jyYuQoSzxZxuIGjb6E/3ySWcZR84nCPuHqeEbcFE7zKOcBnsMLr9WLkbtADvYjkv VY5samQ+S/Ehz81/ZDSv7oDMH5YlXqLpkV3ClUxd8RN0hVkbIeWDvX034uUKS/mT97m9 iTAdW93tyH7djuWBO6cR1sEdk7Vo9aO6YwmWeWHy1sQb7FEwE6V+ntow79mYIIoIlYVc MevQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=myDgnxek1A0g6mVA8qKx0rtEvTjX98r2YbQxJa5nzkk=; b=eLcRnoI21KxfDb4iImCwxqlaa/hi7rWQeKznXCGJhH+nTq+pup7VpEOJ//Yl7e/Ldy X+3gyhKA6EK0leP+qAtbq51EcJSY4MJz5m2bz4MQzeNQ2NXGqKwvR+CFi6WecICyCSIg hz80cG+1YBlshMd8F5E90qiufX0+HsshI9/QfYuq/w5Nrtet5DUC9iOq3/OWwi/7xg9Y S7dVozXPXyOp1gztyPhCH4H6iPrKqiYRhjDWd4vKWKcgSf9qnRUtHWLj/KpCWKl2eaKj YdWMdGFXTCcwaRJkQYoT5qWc4tsC9bTHVcpM8Dmk+4q3EuRhtkUGrCxeoWLXBoh6iIJW 9d+A== X-Gm-Message-State: APjAAAW2CqRvYNUcSkMm08gvWRRLpcCq9eOi2OXImzz78p9eb6hsYaC2 Uo1yFlPstrfPN3x8lcW6cYmJ9jOldEEzo1Zz0ZU= X-Google-Smtp-Source: APXvYqzb92DFRl4jyS7VknHEZ2diUVpoGoSZx1HrsA/iMdO3RhZ+1n+qHisftZkwchlFH7qOx5A8iqNkoaequRsCidQ= X-Received: by 2002:a0c:a485:: with SMTP id x5mr1906210qvx.206.1552646800307; Fri, 15 Mar 2019 03:46:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Fri, 15 Mar 2019 03:46:28 -0700 Message-ID: To: Bob Briscoe Cc: tcpm IETF list , iccrg IRTF list , ecn-sane@lists.bufferbloat.net, bloat Content-Type: multipart/alternative; boundary="000000000000fe7ad705841fc0ee" Subject: Re: [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 10:46:41 -0000 --000000000000fe7ad705841fc0ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > 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) > > > To: hackathon@ietf.org , > tcpprague@ietf.org > CC: dlebrun@google.com , Joakim > Misund , Bob Briscoe > , Quentin De Coninck > , > Fran=C3=A7ois Michel > , Mirja Kuehlewind > , > Maxime Piraux , > Olga Albisser , Fabien Duch=C3=AAn= e > , De Schepper, > Koen (Nokia - BE/Antwerp) > > > 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=E2=80=94i.e., meet the safety requirements and have supporting mate= rials > (e.g., VMs, labs) to let people experiment with it. Depending on people's > interest, prototyping something similar for QUIC is another possible outp= ut. > > 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 befor= e. > > See you in Prague. > > Best, > Olivier > > > Implementation and experimentation of TCP Prague/L4S > > * Champion > * Olivier Tilmans > * 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 =E2=80=94 =E2=80=8Bhttps://github.com/L4STeam/tcp-prague > * Requirements =E2=80=94 =E2=80=8B > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-21 > * Upcoming netdev talk =E2=80=94 > https://netdevconf.org/0x13/session.html?talk-tcp-prague-l4s > * Accurate ECN > * Specs =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/html/draft-ietf-tcpm-ac= curate-ecn-07 > * Implementation for Linux v4.17 =E2=80=94 =E2=80=8Bhttps://github.com/mi= rjak/linux-accecn > * Past netdev talk =E2=80=94 > https://www.netdevconf.org/2.2/session.html?kuhlewind-accecn-talk > * Paced Chirping * Repository =E2=80=94 =E2=80=8B > https://github.com/JoakimMisund/PacedChirping > * Upcoming netdev talk =E2=80=94 > https://netdevconf.org/0x13/session.html?talk-chirp > * L4S architecture > * Specs =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/html/draft-ietf-tsvwg-l= 4s-arch-03 > * DualPI2 AQM > * Specs =E2=80=94 =E2=80=8B > https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08 > * Repository =E2=80=94 =E2=80=8Bhttps://github.com/L4STeam/sch_dualpi2_up= stream > * Upcoming netdev talk =E2=80=94 > https://netdevconf.org/0x13/session.html?talk-DUALPI2-AQM > * RITE Project =E2=80=94 =E2=80=8Bhttps://riteproject.eu/dctth/#code > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg > --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 --000000000000fe7ad705841fc0ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 d= evelopers co-ordinating on landing code for our competing proposal "So= me Congestion Experienced", which we submitted to tsvwg last sunday.= =C2=A0

That draft is under continuous = revision, here:


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

= Some background to this: after the L4S/TCP Prague/and dualpi experiments ap= peared stalled out indefinitely in the IETF, and with our own frustration w= ith IETF processes, bu= fferbloat.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:=C2=A0https://www.bufferbloat.net/pr= ojects/ecn-sane/wiki/

We were unaware, until las= t 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/d= ualpi IETF "experiments" into an actual DOCSIS standard.

Our SCE proposal appears to be backward compatible with th= e 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 an= y tcp-friendly congestion control) at all in order to basically work. tcp-p= rague is subtly incompatible with that, and dualpi, more so. Our proposal i= s different also, it proposes some receiver side changes in order to get th= e full benefit of SCE while remaining backward compatible with the existing= meaning of the CE codepoint.

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

The mem= bers of the ecn-sane working group are delighted to finally hear that runni= ng code for tcp-prague might land this ietf, and look forward to finally te= sting the whole l4s/tcpprague/dualpi architecture in conjunction with the <= a href=3D"http://flent.org" target=3D"_blank">flent.org 's and irtt= 's exhaustive suite of tests and servers in the cloud in the coming mon= ths, both against our existing, deployed, fq_codel, fq_pie, cake and pie de= rived solutions and our new SCE proposal. We hope to finally be able to wri= te new tests for flent in particular, that can show tcpprague off in the wa= ys that are important to those developing it. Flent has some basic dctcp te= sts, but nothing that can get down below a 20ms sample rate on modern hardw= are. (currently. It's easy to add tests, flent is written in python)

We also hope that more test tools and implementation= s in ns2 and ns3 show up for tcpprauge=C2=A0 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 develop= ers due to some technical and legal problems with linux net-next HEAD (=C2= =A0https://patchwor= k.ozlabs.org/patch/1054521/=C2=A0 ) , and I do hope that a corrected ve= rsion lands soon, so we can safely test it with current versions of OpenWrt= , etc.

Finally, running code. Will we find consens= us?

Thx!


[2] sch_cake was available= for 3 years out of tree and was mainlined last august, in linux 4.19. It i= s partially described by "Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways" "https://arxiv.org/pdf/1804.07617.= pdf=C2=A0

A second paper describing its fq_cod= el-derived "cobalt" AQM algorithm is awaiting publication in a pe= er reviewed journal. It has been part of openwrt and the related sqm-script= s for many years and is widely deployed on multiple commercial products, su= ch as those from eero and evenroute.

Cake has a do= csis specific mode which we longed for cablelabs to evaluate.


On Fri, Mar 15, 2019 at 2:= 33 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:
=20 =20 =20
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) <olivier.tilmans@nokia-bell-labs.com>
To: hackathon@ietf.org <hackathon@ietf.org>, tcpprague@ietf.org <tcpprague@ietf.org>
CC: dlebrun@google.com <dlebrun@google.com>, Joakim Misund <joakim.misund@gmail.com>, Bob Briscoe <research@bobbriscoe.net>, Quentin De Coninck <quentin.deconinck@uclouvain.be>, Fran=C3=A7oi= s Michel <francois.michel@uclouvain.be>, Mirja Kuehlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Maxime Pir= aux <maxime.piraux@uclouvain.be>, Olga Albisser <olga@albisser.org>, Fabien Duch=C3=AAne <fabien.duchene@uclouvain.be>, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>


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=E2=80=94i.e., meet the safety requiremen= ts 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 =E2=80=94 =E2=80=8Bhttps://github.com/L4STeam/tcp-p= rague
* Requirements =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/htm= l/draft-ietf-tsvwg-ecn-l4s-id-05#page-21
* Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/session.html?= talk-tcp-prague-l4s
* Accurate ECN
* Specs =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/html/draft= -ietf-tcpm-accurate-ecn-07
* Implementation for Linux v4.17 =E2=80=94 =E2=80=8Bhttps://github.com/mirjak/linux-accecn
* Past netdev talk =E2=80=94 https://www.netdevconf.org/2.2/sessi= on.html?kuhlewind-accecn-talk
* Paced Chirping * Repository =E2=80=94 =E2=80=8Bhttps://github.com/JoakimMisund/PacedChirping
* Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/session.html?talk-chir= p
* L4S architecture
* Specs =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/html/draft-ie= tf-tsvwg-l4s-arch-03
* DualPI2 AQM
* Specs =E2=80=94 =E2=80=8Bhttps://tools.ietf.org/html= /draft-ietf-tsvwg-aqm-dualq-coupled-08
* Repository =E2=80=94 =E2=80=8Bhttps://github.com/L4S= Team/sch_dualpi2_upstream
* Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/session.html?tal= k-DUALPI2-AQM
* RITE Project =E2=80=94 =E2=80=8Bhttps://riteproject.eu/dctth/#cod= e
_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org
https://www.ietf.org/mailman/listinfo/tcpprague
_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg


--

Dave T=C3=A4htCTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
--000000000000fe7ad705841fc0ee--