From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 D99F83BA8E for ; Fri, 15 Mar 2019 09:01:54 -0400 (EDT) Received: from [172.16.12.10] ([134.76.241.253]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M96Jd-1hCBXJ3mAP-00CU3g; Fri, 15 Mar 2019 14:01:53 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 15 Mar 2019 14:01:51 +0100 Cc: bloat Content-Transfer-Encoding: quoted-printable Message-Id: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> References: To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:j6htdAQp9stjG9B9Zjcb3eulycEQ270PpIwwRzYRk5JOv1aOD81 aX+55MuitT6db6QKOl3+ukJRVdXyf022601bwHQYye9Kw0Cv3d5FSlD+6JY3WLgz1DlW5e3 IvKTXF4E7T0PYXV1dvqy3tszHkPgSLpCX5IafNKSwv+OQNS0QCV72YIZWqaLShXA3NlCwx8 uuQYio5WdBfLUuMTaJyVA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:9E2ktJXrHXk=:db7Fe4pzJ3wVHX+/0S55UO ljLcpgd4BYQWyqW1NfX2GlClLMpH25SK2IbPT0lnSov3UWp4CeDTcFojbUjJHfkGn9l5pi6Zi Wr4QjGhE3yF9gqOo93WmWPWFAVGOfp0Rs52taNwjTkW2+C0zt2u0g6xsi5FG43GcVYqxfyOHH M/3stPMkjma5nRN5N2wO5Ny4xO0myWAgpQWZAfcOfhOphuHwO84vu0pUEjpJvi2qMZTf0jCDT leZ7N9t42zhWJ9CihYhYMQ2Dk0dAyuqQJmrbG4l1GMu5DTtUyyerttzBfqobhoGWNvUsIuJXH N0iud1oxy64xSVrfx8RGOuOaqNfwwc9M1X8+fj5EmG09laL5lkw0o0PPE873SowgcGeHlBDHM rEx9Bm1r9DCjUUqA1MmKaMuZN2cIVnDd3TT0qRzlbDMNnHLl8WQ4laQjhnWKyoeZ7gj3Z26aU c/Rwvbi2RuoECrjjaacNb9/yyIZd08fPZmYRCxUw6I3//PoDGJFfAV893ssooI46O4Egn4R9B PIDVSjKw6mWVdg51oYUFybVJ+Lx6iA+BQzYcjkpB55unZyOD/KH4yS5FO+2Ln5sFWuvm9ajyn zfV6zw3zhtr7wfJWlnhypZlq0zDQMOCYM4kJHN9LsvzUcHwGPKSApXGc50kKTtYX5YNbTTaXf dhuQm8YcLBJlZdb6Xc+6vWzTi9aHsD4fHZptTodgRAybc7IuU7vbJDdARPSRYGhc40f00AolY +HE2DyEYhsodDsWKBgtyBx4DEWw23yXebEDQMR4LVd6FOroiP5MbCybzOTPAP/jvbeff+WvfA eD80hIWtcvr/j0W4IM4PnW3hPmJA8SbPJFo+HOZ8dJnb/sJFJv8O+hWCboRyBGxo9LkTpRDr4 f3Kl52sV8OkvTPfWNsVZxfUswmKnnWA3akXouQsJ7eqVrzteVeCCd1CaIEilJZw/kQu3KAnU+ h6sPvhBp52Q== 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 13:01:55 -0000 Hi Dave, I pruned the CC list as I am out of my league here and want to restrict = the radius of my embarrassment to those that already know my level of = incompetence before hand. That said, having read through the L4S architecture description and the = related appendices of draft-ietf-tsvwg-ecn-l4s-id-05 I came to the = conclusion, that this is a mess. The L4S project proposes a really wide-ranging change of basically the = internet (but allow a concurrent operation with legacy probably to cater = to the fact that an internet-wide flag-day seems daunting to organize). = But then they chicken out when figuring out how to differentiate between = their new and the old by proposing to use ECT(1) for a purpose outside = of its nominal purpose namely explicit congestion notification, why not = think bolder? If the plan is to change everything the feasibility can = not hinge upon the ability to re-using one old legacy bit, can it... Conceptually it seems much cleaner to use ECT(1) for congestion = notification directly (there are already proposals out there and SCE = just added another fully back-ward compatible one) and find another way = to mark l4s traffic, sure that is going to be hard and inconvenient, but = if you set out to change the internet that is par for the course.=20 IMHO they would do more good if they actually fought for a better use of = the 6 DSCP bits instead. (say by splitting into two groups of 3 bits, = one group for reduced diffserv and one group for new features, that = would even allow for concurrent use of the inevitable L5S and L6S ;) ). = Especially since as far as I can understand l4s actually would like to = have a more gradual congestion information stream than classic ECN, and = since they need to modify DCTCP anyway to make it save for the wider = internet, replacing its ECN response should be well inside the scope of = work they already have on their list. If I sound a bit miffed, it is because after reading = https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03 I do not have = the feeling they are trying to build abetter internet, but rather that = they are building an internet where I can be a better "product" and = customer of newfangled services, and I do not look forward to such a = facebooky future with much enthusiasm.=20 I hope that the discussion in Prague go well and a compromise/consense = can be hashed out as I see different implementations duking it out here, = but the overall goal of the competitors seems quite compatible, = improving the internet by focussing on latency. Best Regards Sebastian > On Mar 15, 2019, at 11:46, Dave Taht wrote: >=20 > 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.=20 >=20 > That draft is under continuous revision, here: >=20 > = https://github.com/dtaht/bufferbloat-rfcs/blob/master/sce/draft-morton-tah= t-tsvwg-sce.txt >=20 > Our Linux and FreeBSD team is also flying into prague for SCE = presentations at netdevconf and ietf. >=20 > 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. >=20 > Its charter is here: = https://www.bufferbloat.net/projects/ecn-sane/wiki/ >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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) >=20 > 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. >=20 > 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. >=20 > Finally, running code. Will we find consensus? >=20 > Thx! >=20 >=20 > [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=20 >=20 > 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. >=20 > Cake has a docsis specific mode which we longed for cablelabs to = evaluate. >=20 >=20 > 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. >=20 > 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. >=20 >=20 > Bob >=20 >=20 > -------- 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=AAne , De Schepper, Koen (Nokia - = BE/Antwerp) >=20 > Hi all, >=20 > 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 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. >=20 > 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. >=20 > See you in Prague. >=20 > Best, > Olivier >=20 >=20 > Implementation and experimentation of TCP Prague/L4S >=20 > * 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=8Bhttps://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-2= 1 > * 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/session.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-chirp > * L4S architecture > * Specs =E2=80=94 = =E2=80=8Bhttps://tools.ietf.org/html/draft-ietf-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/L4STeam/sch_dualpi2_upstream > * 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 >=20 > --=20 >=20 > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat