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 8BCA53BA8E; Fri, 15 Mar 2019 10:07:03 -0400 (EDT) Received: by mail-qt1-x82c.google.com with SMTP id v32so10155753qtc.10; Fri, 15 Mar 2019 07:07:03 -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:content-transfer-encoding; bh=IIwFfXiUZekyxS7Fh088X1ly1TFSjnQvo12Ala13B7c=; b=A7+Bc61EFNzlPIWf6zNNVSPUUIWlISJm1oGHZS4FHuHrS1VBeFwFeQgBz31KZTMTvq NeVQ7+2hOvHsBVxsr8pU4AtVW9Xd4nEfznXrAwEHaMfDXCoDFzELNZj4wsN+/gjbsSkl LU+a3rdF4CrvkAra4jKu1b8i0VD5zqq7wikOlERhaCdxfdmMZlAklcsRSJNzClWHhbBk sg7q0DY6xjfZt5RuGEdiniwZJsy+eFd4Q9mqRPzKfFrXqOUEA/Q8tw4qXnSNsHTeT1Go t4gi+v1BFMtM1MxfzZk7X6MyeUlSpSkJzFWoGT3e1SJ175DE/tYyMfqwbY2aanJv/uT9 rsPQ== 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:content-transfer-encoding; bh=IIwFfXiUZekyxS7Fh088X1ly1TFSjnQvo12Ala13B7c=; b=lJa9OSLiyNYNwIRhPqy1aMTuV7guiRoDExGsOr9NEcffnalf6X/NsKOLACtYDZY1cT uxDiyn4hfeSSWEfUUVqrlDlKZhymE7TOK4UxE9nhG3xqwxxNKO77CS3qR6O34VMfT28C AnAMeqagdRCu1eAI7KquQuVWQh9EJjOIAJSmmj/BDSx1BXz6gVvkTzs1pETtv9NYA2m9 KZSS+g/zYBet9ifUX/KCPEXiLtUggNG1Nug/lmKxurNz92eu4by0MqY2bF6q4/SZGa72 vSIQaqL8bSb0NUmGexbtP+vGZFp4bZu09Xznuh3FqmXzi2GyMYvuYO7P4jp1ljTQ+7Zk YSJA== X-Gm-Message-State: APjAAAUSpOQmvoZb4CzHFHtn/lYCOje5Y96SDFIMZsyFacY71G6MkGQX Yi2rwmDYGl8xuBH6OcXnRyhuVu25AdSwpQsdkZjnfPcj X-Google-Smtp-Source: APXvYqyE9ycRPqTsB7H0r9YLhbom7iKxuehCQvgIAMo65w62yXVGhRv+tbJY+eAPI1BEJ2A7HD9envc69U23mKaC5rI= X-Received: by 2002:a0c:a485:: with SMTP id x5mr2628107qvx.206.1552658822823; Fri, 15 Mar 2019 07:07:02 -0700 (PDT) MIME-Version: 1.0 References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> In-Reply-To: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> From: Dave Taht Date: Fri, 15 Mar 2019 07:06:50 -0700 Message-ID: To: Sebastian Moeller Cc: bloat , ecn-sane@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 14:07:03 -0000 I would really prefer to move this discussion to the ecn-sane mailing list, as IMHO, ecn is generally such a tiny thing needed for good congestion control compared to better transports like pacing + bbr, and things like bql, fq, and aqm using drop. I'm going to keep cc-ing that list in the hope that we can keep better track of the discussion here. On Fri, Mar 15, 2019 at 6:01 AM Sebastian Moeller wrote: > > Hi Dave, > > I pruned the CC list as I am out of my league here and want to restrict t= he radius of my embarrassment to those that already know my level of incomp= etence before hand. IMHO, your work on educating the OpenWrt community over the years on how to use sqm, makes you much more than "only a grasshopper". You have a firm grip on what can be achieved in the real world. > > That said, having read through the L4S architecture description and the r= elated appendices of draft-ietf-tsvwg-ecn-l4s-id-05 I came to the conclusio= n, that this is a mess. I am so glad someone other than I has now read it. > The L4S project proposes a really wide-ranging change of basically the in= ternet (but allow a concurrent operation with legacy probably to cater to t= he fact that an internet-wide flag-day seems daunting to organize). But the= n 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 nomina= l purpose namely explicit congestion notification, why not think bolder? If= the plan is to change everything the feasibility can not hinge upon the ab= ility to re-using one old legacy bit, can it... > Conceptually it seems much cleaner to use ECT(1) for congestion notificat= ion directly (there are already proposals out there and SCE just added anot= her fully back-ward compatible one) and find another way to mark l4s traffi= c, sure that is going to be hard and inconvenient, but if you set out to ch= ange the internet that is par for the course. > 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 g= roup for reduced diffserv and one group for new features, that would even The existing diffserv deployment is a failure. I have another ID cooking that suggests a better way, going forward, to use them, but I do not feel at this time it would be useful to present. One big battle at a time. That ID is very simple, it basically proposes that all diffserv codepoints be passed through ISPs and transit providers unchanged, and if any given codepoint must be changed, the only permissible change is to 0 (BE), and MUST be not be remarked to anything else, especially not CS1. >allow for concurrent use of the inevitable L5S and L6S ;) ). Especially si= nce as far as I can understand l4s actually would like to have a more gradu= al congestion information stream than classic ECN, and since they need to m= odify DCTCP anyway to make it save for the wider internet, replacing its EC= N response should be well inside the scope of work they already have on the= ir list. Next up for sce was going to be to find if dctcp could be modified to use it. Also, bittorrent. > If I sound a bit miffed, it is because after reading https://tools.ietf.o= rg/html/draft-ietf-tsvwg-l4s-arch-03 I do not have the feeling they are try= ing to build abetter internet, but rather that they are building an interne= t where I can be a better "product" and customer of newfangled services, an= d I do not look forward to such a facebooky future with much enthusiasm. I have rigorously tried to keep the network neutrality debate out of this. dualpi is just another aqm that needs the same thorough technical and public evaluation done to it that pie, codel, fq_codel were subjected to.The use of ect_1 in dualpi for it is nuts IMHO, and I'd vastly prefer that another L4S codepoint be added to make it work, but any attempt to do so would also require industry consolidation on that ID and that would be distracting at this time. It appears, also, ironically, (I have confirmation from several sources now) that cake, fq_codel and dualpi are now illegal for an ISP to use in their provided equipment under california law. The idea of one day having to appear in court to defend our key algorithms reminds me of the famous john fogerty case where he demonstrated how blues music was made. I wish I knew a lawyer willing to take on "bufferbloat.net vs the state of california", though, as it may come down to that. I blew up on this part of the issue here: http://blog.cerowrt.org/post/net_neutrality_customers/ > > I hope that the discussion in Prague go well and a compromise/consense ca= n be hashed out as I see different implementations duking it out here, but = the overall goal of the competitors seems quite compatible, improving the i= nternet by focussing on latency. > > Best Regards > Sebastian > > > On Mar 15, 2019, at 11:46, Dave Taht wrote: > > > > Bufferbloat.net's ecn-sane working group members have a co-ordinated re= sponse 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 tsv= wg 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 presentat= ions at netdevconf and ietf. > > > > Some background to this: after the L4S/TCP Prague/and dualpi experiment= s appeared stalled out indefinitely in the IETF, and with our own frustrati= on with IETF processes, bufferbloat.net project members publicly formed our= own working group to look into the problems with ecn, back in august of la= st 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 month= s back gone and formed its own private working group also, and was intendin= g to turn the tcp prague/l4s/dualpi IETF "experiments" into an actual DOCSI= S standard. > > > > Our SCE proposal appears to be backward compatible with the existing 10= s-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 co= ngestion control) at all in order to basically work. tcp-prague is subtly i= ncompatible 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 C= E codepoint. > > > > In either case, either approach essentially permanently redefines the E= CT_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 debat= es 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 technica= l 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_cod= el, fq_pie, cake and pie derived solutions and our new SCE proposal. We hop= e to finally be able to write new tests for flent in particular, that can s= how tcpprague off in the ways that are important to those developing it. Fl= ent 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 i= s written in python) > > > > We also hope that more test tools and implementations in ns2 and ns3 sh= ow up for tcpprauge and dualpi show up soon also, from members of those pr= ojects. > > > > Note: sunday's dual-pi linux submission was kicked back from the linux = networking developers due to some technical and legal problems with linux n= et-next HEAD ( https://patchwork.ozlabs.org/patch/1054521/ ) , and I do ho= pe that a corrected version lands soon, so we can safely test it with curre= nt 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 la= st august, in linux 4.19. It is partially described by "Piece of CAKE: A Co= mprehensive Queue Management Solution for Home Gateways" "https://arxiv.org= /pdf/1804.07617.pdf > > > > A second paper describing its fq_codel-derived "cobalt" AQM algorithm i= s awaiting publication in a peer reviewed journal. It has been part of open= wrt and the related sqm-scripts for many years and is widely deployed on mu= ltiple commercial products, such as those from eero and evenroute. > > > > Cake has a docsis specific mode which we longed for cablelabs to evalua= te. > > > > > > On Fri, Mar 15, 2019 at 2:33 AM Bob Briscoe wrote= : > > Forwarding to tcpm & iccrg - apologies if you were already on one of th= e lists that received this. > > > > Olivier has been working hard on integrating the pieces of a Linux impl= ementation of TCP Prague, and is close to having a version ported against t= he tip of the Linux mainline tree. This is his request for more people to g= et involved. > > > > > > Bob > > > > > > -------- Forwarded Message -------- > > Subject: [tcpPrague] Implementation and experimentation of TCP Pra= gue/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 Pira= ux , Olga Albisser , Fabien = Duch=C3=AAne , De Schepper, Koen (Nokia - BE/A= ntwerp) > > > > Hi all, > > > > We'll be working on the "TCP Prague" congestion control/L4S architectur= e during the IETF-104 hackaton. > > This topics aims at accelerating the work that started during the IETF9= 3 (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 peop= le's interest, prototyping something similar for QUIC is another possible o= utput. > > > > 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 bef= ore. > > > > 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 w= ith the technology (e.g., virtual machine, or mininet labs) > > * Work towards "QUIC Prague" > > * Resources > > * TCP Prague > > * Repository =E2=80=94 https://github.com/L4STeam/tcp-prague > > * Requirements =E2=80=94 https://tools.ietf.org/html/draft-ietf-tsvwg-e= cn-l4s-id-05#page-21 > > * Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/session.ht= ml?talk-tcp-prague-l4s > > * Accurate ECN > > * Specs =E2=80=94 https://tools.ietf.org/html/draft-ietf-tcpm-accurate-= ecn-07 > > * Implementation for Linux v4.17 =E2=80=94 https://github.com/mirjak/li= nux-accecn > > * Past netdev talk =E2=80=94 https://www.netdevconf.org/2.2/session.htm= l?kuhlewind-accecn-talk > > * Paced Chirping * Repository =E2=80=94 https://github.com/JoakimMisund= /PacedChirping > > * Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/session.ht= ml?talk-chirp > > * L4S architecture > > * Specs =E2=80=94 https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch= -03 > > * DualPI2 AQM > > * Specs =E2=80=94 https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dual= q-coupled-08 > > * Repository =E2=80=94 https://github.com/L4STeam/sch_dualpi2_upstream > > * Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/session.ht= ml?talk-DUALPI2-AQM > > * RITE Project =E2=80=94 https://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 > > > > > > -- > > > > 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 > -- Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740