From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp68.iad3a.emailsrvr.com (smtp68.iad3a.emailsrvr.com [173.203.187.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 701ED3BA8E for ; Fri, 15 Mar 2019 13:01:24 -0400 (EDT) Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1D900230F7; Fri, 15 Mar 2019 13:01:24 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 16319252BB; Fri, 15 Mar 2019 13:01:24 -0400 (EDT) Received: from app52.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9C167230F7; Fri, 15 Mar 2019 13:01:23 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app52.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 15 Mar 2019 13:01:24 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app52.wa-webapps.iad3a (Postfix) with ESMTP id 88229E003F; Fri, 15 Mar 2019 13:01:23 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Fri, 15 Mar 2019 13:01:23 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Fri, 15 Mar 2019 13:01:23 -0400 (EDT) From: "David P. Reed" To: "Sebastian Moeller" Cc: "=?utf-8?Q?Dave_T=C3=A4ht?=" , ecn-sane@lists.bufferbloat.net, "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190315130123000000_84948" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> Message-ID: <1552669283.555112988@apps.rackspace.com> X-Mailer: webmail/16.2.2-RC Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 17:01:24 -0000 ------=_20190315130123000000_84948 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AThe absolute fundamental issue with diffserv, IMO, is that the carriers = cannot agree on an actual specification of what routers and gateways are su= pposed to do, while being compatible with the core principle of the IP laye= r: do not hold packets if they cause increasing queueing delay. (this is in= the Best Practices RFC)=0A =0AAnd it's not for lack of trying. Dave Clark = led a working group at the MIT communications futures program (where I was = a principle) that included most major backbone providers' key folks that wa= s specifically focused on getting a widespread agreement on what any of the= code points might mean, not as bullshit English descriptions of what kind = of traffic each one represented, but as an operational description of what = should be done by a router to manage its queues.=0A =0AThey couldn't even a= gree (after about 18 months of meetings) about what the bullshit English in= tent was, much less what operational semantics in the packet forwarding net= work had to be.=0A =0ASo if the responsible network engineers in the carrie= rs cannot agree on anything, IETF is wasting its time.=0A =0A =0A =0A =0A--= ---Original Message-----=0AFrom: "Sebastian Moeller" =0ASe= nt: Friday, March 15, 2019 11:52am=0ATo: "Dave T=C3=A4ht" =0ACc: ecn-sane@lists.bufferbloat.net, "bloat" =0ASubject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementa= tion and experimentation of TCP Prague/L4S hackaton at IETF104=0A=0A=0A=0AH= i Dave,=0A=0A=0A> On Mar 15, 2019, at 15:06, Dave Taht wrote:=0A> =0A> I would really prefer to move this discussion to the ecn-= sane mailing=0A> list, as IMHO, ecn is generally such a tiny thing needed f= or good=0A> congestion control compared to better transports like pacing + = bbr,=0A> and things like bql, fq, and aqm using drop.=0A> =0A> I'm going to= keep cc-ing that list in the hope that we can keep better=0A> track of the= discussion here.=0A=0A Ah, sure, I basically wanted to avoid annoying the = ietf lists as I feel out of place there, having only had a cursory read of = the relevant RFCs.=0A=0A=0A> =0A> On Fri, Mar 15, 2019 at 6:01 AM Sebastian= Moeller wrote:=0A>> =0A>> Hi Dave,=0A>> =0A>> I pruned t= he 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 befor= e hand.=0A> =0A> IMHO, your work on educating the OpenWrt community over th= e years on=0A> how to use sqm, makes you much more than "only a grasshopper= ". You=0A> have a firm grip on what can be achieved in the real world.=0A> = =0A>> =0A>> 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.=0A> =0A> I am so glad someone other than = I has now read it.=0A> =0A>> The L4S project proposes a really wide-ranging= change of basically the internet (but allow a concurrent operation with le= gacy probably to cater to the fact that an internet-wide flag-day seems dau= nting to organize). But then they chicken out when figuring out how to diff= erentiate between their new and the old by proposing to use ECT(1) for a pu= rpose outside of its nominal purpose namely explicit congestion notificatio= n, why not think bolder? If the plan is to change everything the feasibilit= y can not hinge upon the ability to re-using one old legacy bit, can it...= =0A>> Conceptually it seems much cleaner to use ECT(1) for congestion notif= ication directly (there are already proposals out there and SCE just added = another fully back-ward compatible one) and find another way to mark l4s tr= affic, sure that is going to be hard and inconvenient, but if you set out t= o change the internet that is par for the course.=0A>> IMHO they would do m= ore good if they actually fought for a better use of the 6 DSCP bits instea= d. (say by splitting into two groups of 3 bits, one group for reduced diffs= erv and one group for new features, that would even=0A> =0A> The existing d= iffserv deployment is a failure.=0A=0A Which is a shame, but one RFC's fail= ure is another one's opportunity.=0A=0A=0A> I have another ID=0A> cooking t= hat suggests a better way, going forward, to use them, but I=0A> do not fee= l at this time it would be useful to present. One big battle=0A> at a time.= =0A=0A:)=0A=0A> That ID is very simple, it basically proposes that all=0A> = diffserv codepoints be passed through ISPs and transit providers=0A> unchan= ged, and if any given codepoint must be changed, the only=0A> permissible c= hange is to 0 (BE), and MUST be not be remarked to=0A> anything else, espec= ially not CS1.=0A=0A I like the simplicity, but I also like the split into = two groups of 3 bits, say "active bit pattern" (for transport purposes) and= "intenden bit pattern" for the sender to transmit intent, which than can b= e conveyed lossless to the receiver; my gut feeling is that throwing the tr= ansport people a bone here might work better, as in the end they are the on= e that will carry the "burden" of the change. IMHO this has the additional = advantage that it will make "tabula rasa" of the existing distict set of bi= t patterns used in the real world. Which in turn probably is this ideas dow= nfall...=0A=0A=0A> =0A>> allow for concurrent use of the inevitable L5S and= L6S ;) ). Especially since as far as I can understand l4s actually would l= ike 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 in= ternet, replacing its ECN response should be well inside the scope of work = they already have on their list.=0A> =0A> Next up for sce was going to be t= o find if dctcp could be modified to=0A> use it. Also, bittorrent.=0A=0A YE= S! I endorse this message.=0A=0A> =0A>> If I sound a bit miffed, it is beca= use 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 ra= ther that they are building an internet where I can be a better "product" a= nd customer of newfangled services, and I do not look forward to such a fac= ebooky future with much enthusiasm.=0A> =0A> I have rigorously tried to kee= p the network neutrality debate out of=0A> this.=0A=0A And I really do not = want to start this here, as I agree that this is about a technical question= . That said, I had hoped more out of the l4s promises from an end-user pers= pective. Then again, it if this is going to happen it needs the ISPs buy-in= so it might be politically wise to emphasize the advantages for ISPs.=0A= =0A=0A> dualpi is just another aqm that needs the same thorough=0A> technic= al and public evaluation done to it that pie, codel, fq_codel=0A> were subj= ected to.=0A=0A+1, I note that the main argument against fq is "we can do i= t with two" without a convincing argument why two is better than the few 10= 0s you realistically will never need for fq even on an busy core router.=0A= =0A> The use of ect_1 in dualpi for it is nuts IMHO,=0A=0A At least it is u= nclean...=0A=0A> and=0A> I'd vastly prefer that another L4S codepoint be ad= ded to make it work,=0A> but any attempt to do so would also require indust= ry consolidation on=0A> that ID and that would be distracting at this time.= =0A=0A But as I said, L4S aims to change everything so why stop there ;)=0A= =0A> =0A> It appears, also, ironically, (I have confirmation from several= =0A> sources now) that cake, fq_codel and dualpi are now illegal for an ISP= =0A> to use in their provided equipment under california law.=0A=0A I will = happily look at specific sections of code if pointed to, but I will not act= ively search for. At least the European net neutrality rules do not make an= y of these illegal, as the rules allow for traffic management (and special = services at extra cost as long as these are not built be restricting the be= st-effort net, no idea how that should be poiced) (and in the end the rules= only apply for ISPs in one's own network one can DPI to a far greater exte= nt if one is such inclined).=0A=0A=0A> The idea of=0A> one day having to ap= pear in court to defend our key algorithms reminds=0A> me of the famous joh= n fogerty case where he demonstrated how blues=0A> music was made.=0A=0A I = see a nice art-house movie coming up.=0A=0A=0A> =0A> I wish I knew a lawyer= willing to take on "bufferbloat.net vs the=0A> state of california", thoug= h, as it may come down to that.=0A> =0A> I blew up on this part of the issu= e here:=0A> http://blog.cerowrt.org/post/net_neutrality_customers/=0A=0A I = read that, but it does not reflect to well on the situation this side of th= e pond. We had situations where ISPs worked hard (but without success) to s= witch from their flat-rate access to introduce volume caps, that served a d= ual purpose, a) extracting more revenue from customers and b) allowing to m= ake "zero-rating" deals with content-providers (which in the end are also p= ayed for by the end-users, indirectly). Sure, this is all normal in busines= s, but that does not necessarily mean that I do need to like being a pawn i= n a business transaction between global corporations. (I consider this to b= e at least somewhat related to the net neutrality debate).=0A=0ABest Regard= s=0A Sebastian=0A=0A=0A>> =0A>> I hope that the discussion in Prague go wel= l and a compromise/consense can be hashed out as I see different implementa= tions duking it out here, but the overall goal of the competitors seems qui= te compatible, improving the internet by focussing on latency.=0A>> =0A>> B= est Regards=0A>> Sebastian=0A>> =0A>>> On Mar 15, 2019, at 11:46, Dave Taht= wrote:=0A>>> =0A>>> Bufferbloat.net's ecn-sane worki= ng group members have a co-ordinated response to your efforts brewing but i= t'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.=0A>>> =0A>>> That dr= aft is under continuous revision, here:=0A>>> =0A>>> https://github.com/dta= ht/bufferbloat-rfcs/blob/master/sce/draft-morton-taht-tsvwg-sce.txt=0A>>> = =0A>>> Our Linux and FreeBSD team is also flying into prague for SCE presen= tations at netdevconf and ietf.=0A>>> =0A>>> Some background to this: after= the L4S/TCP Prague/and dualpi experiments appeared stalled out indefinitel= y in the IETF, and with our own frustration with IETF processes, bufferbloa= t.net project members publicly formed our own working group to look into th= e problems with ecn, back in august of last year.=0A>>> =0A>>> Its charter = is here: https://www.bufferbloat.net/projects/ecn-sane/wiki/=0A>>> =0A>>> W= e were unaware, until last month, that the cable industry had 16 months bac= k 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 sta= ndard.=0A>>> =0A>>> 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-pr= ague 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.=0A>>> =0A>>> In either case, either approach e= ssentially 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 si= ngle bit in IP, and I expect the debates to be as difficult as the ones des= cribed 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 h= ave little hope for that.=0A>>> =0A>>> 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 exhaus= tive suite of tests and servers in the cloud in the coming months, both aga= inst our existing, deployed, fq_codel, fq_pie, cake and pie derived solutio= ns 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 i= mportant to those developing it. Flent has some basic dctcp tests, but noth= ing that can get down below a 20ms sample rate on modern hardware. (current= ly. It's easy to add tests, flent is written in python)=0A>>> =0A>>> We als= o 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.=0A>= >> =0A>>> Note: sunday's dual-pi linux submission was kicked back from the = linux networking developers due to some technical and legal problems with l= inux 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.=0A>>> =0A>>> Finally, running code. Will = we find consensus?=0A>>> =0A>>> Thx!=0A>>> =0A>>> =0A>>> [1] https://tools.= ietf.org/html/rfc8290=0A>>> [2] sch_cake was available for 3 years out of t= ree and was mainlined last august, in linux 4.19. It is partially described= by "Piece of CAKE: A Comprehensive Queue Management Solution for Home Gate= ways" "https://arxiv.org/pdf/1804.07617.pdf=0A>>> =0A>>> A second paper des= cribing its fq_codel-derived "cobalt" AQM algorithm is awaiting publication= in a peer reviewed journal. It has been part of openwrt and the related sq= m-scripts for many years and is widely deployed on multiple commercial prod= ucts, such as those from eero and evenroute.=0A>>> =0A>>> Cake has a docsis= specific mode which we longed for cablelabs to evaluate.=0A>>> =0A>>> =0A>= >> On Fri, Mar 15, 2019 at 2:33 AM Bob Briscoe wrote:= =0A>>> Forwarding to tcpm & iccrg - apologies if you were already on one of= the lists that received this.=0A>>> =0A>>> Olivier has been working hard o= n integrating the pieces of a Linux implementation of TCP Prague, and is cl= ose to having a version ported against the tip of the Linux mainline tree. = This is his request for more people to get involved.=0A>>> =0A>>> =0A>>> Bo= b=0A>>> =0A>>> =0A>>> -------- Forwarded Message --------=0A>>> Subject: [t= cpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at = IETF104=0A>>> Date: Wed, 6 Mar 2019 10:26:05 +0000=0A>>> From: Tilmans, Oli= vier (Nokia - BE/Antwerp) =0A>>> To: h= ackathon@ietf.org , tcpprague@ietf.org =0A>>> CC: dlebrun@google.com , Joakim Misund , Bob Briscoe , Quentin De Con= inck , Fran=C3=A7ois Michel , Mirja Kuehlewind , Maxime= Piraux , Olga Albisser , Fa= bien Duch=C3=AAne , De Schepper, Koen (Nokia -= BE/Antwerp) =0A>>> =0A>>> Hi all,=0A= >>> =0A>>> We'll be working on the "TCP Prague" congestion control/L4S arch= itecture during the IETF-104 hackaton.=0A>>> This topics aims at accelerati= ng 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 saf= ety requirements and have supporting materials (e.g., VMs, labs) to let peo= ple experiment with it. Depending on people's interest, prototyping somethi= ng similar for QUIC is another possible output.=0A>>> =0A>>> Details and li= nks to resources/supporting drafts are available at https://trac.ietf.org/t= rac/ietf/meeting/wiki/104hackathon#tcp-prague and copied below.=0A>>> Addit= ionally, few topics will presented during netdev 0x13 the week before.=0A>>= > =0A>>> See you in Prague.=0A>>> =0A>>> Best,=0A>>> Olivier=0A>>> =0A>>> = =0A>>> Implementation and experimentation of TCP Prague/L4S=0A>>> =0A>>> * = Champion=0A>>> * Olivier Tilmans = =0A>>> * Projects=0A>>> * Prototype the "TCP Prague" congestion control on = Linux=0A>>> * Finalize the implementation of accurate ECN (draft conformanc= e), and port it on Linux v5.x * Build tooling around L4S to let people expe= riment with the technology (e.g., virtual machine, or mininet labs)=0A>>> *= Work towards "QUIC Prague"=0A>>> * Resources=0A>>> * TCP Prague=0A>>> * Re= pository =E2=80=94 https://github.com/L4STeam/tcp-prague=0A>>> * Requiremen= ts =E2=80=94 https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#pag= e-21=0A>>> * Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/ses= sion.html?talk-tcp-prague-l4s=0A>>> * Accurate ECN=0A>>> * Specs =E2=80=94 = https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07=0A>>> * Impleme= ntation for Linux v4.17 =E2=80=94 https://github.com/mirjak/linux-accecn=0A= >>> * Past netdev talk =E2=80=94 https://www.netdevconf.org/2.2/session.htm= l?kuhlewind-accecn-talk=0A>>> * Paced Chirping * Repository =E2=80=94 https= ://github.com/JoakimMisund/PacedChirping=0A>>> * Upcoming netdev talk =E2= =80=94 https://netdevconf.org/0x13/session.html?talk-chirp=0A>>> * L4S arch= itecture=0A>>> * Specs =E2=80=94 https://tools.ietf.org/html/draft-ietf-tsv= wg-l4s-arch-03=0A>>> * DualPI2 AQM=0A>>> * Specs =E2=80=94 https://tools.ie= tf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08=0A>>> * Repository =E2=80= =94 https://github.com/L4STeam/sch_dualpi2_upstream=0A>>> * Upcoming netdev= talk =E2=80=94 https://netdevconf.org/0x13/session.html?talk-DUALPI2-AQM= =0A>>> * RITE Project =E2=80=94 https://riteproject.eu/dctth/#code=0A>>> __= _____________________________________________=0A>>> tcpPrague mailing list= =0A>>> tcpPrague@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/tcppr= ague=0A>>> _______________________________________________=0A>>> iccrg mail= ing list=0A>>> iccrg@irtf.org=0A>>> https://www.irtf.org/mailman/listinfo/i= ccrg=0A>>> =0A>>> =0A>>> --=0A>>> =0A>>> Dave T=C3=A4ht=0A>>> CTO, TekLibre= , LLC=0A>>> http://www.teklibre.com=0A>>> Tel: 1-831-205-9740=0A>>> _______= ________________________________________=0A>>> Bloat mailing list=0A>>> Blo= at@lists.bufferbloat.net=0A>>> https://lists.bufferbloat.net/listinfo/bloat= =0A>> =0A> =0A> =0A> --=0A> =0A> Dave T=C3=A4ht=0A> CTO, TekLibre, LLC=0A> = http://www.teklibre.com=0A> Tel: 1-831-205-9740=0A=0A______________________= _________________________=0AEcn-sane mailing list=0AEcn-sane@lists.bufferbl= oat.net=0Ahttps://lists.bufferbloat.net/listinfo/ecn-sane ------=_20190315130123000000_84948 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The absolute fundament= al issue with diffserv, IMO, is that the carriers cannot agree on an actual= specification of what routers and gateways are supposed to do, while being= compatible with the core principle of the IP layer: do not hold packets if= they cause increasing queueing delay. (this is in the Best Practices RFC)<= /p>=0A

 

=0A

And it's not f= or lack of trying. Dave Clark led a working group at the MIT communications= futures program (where I was a principle) that included most major backbon= e providers' key folks that was specifically focused on getting a widesprea= d agreement on what any of the code points might mean, not as bullshit Engl= ish descriptions of what kind of traffic each one represented, but as an op= erational description of what should be done by a router to manage its queu= es.

=0A

 

=0A

They could= n't even agree (after about 18 months of meetings) about what the bullshit = English intent was, much less what operational semantics in the packet forw= arding network had to be.

=0A

 

=0A

So if the responsible network engineers in the carriers cannot= agree on anything, IETF is wasting its time.

=0A

&n= bsp;

=0A

 

=0A

 =0A

 

=0A

-----Original Me= ssage-----
From: "Sebastian Moeller" <moeller0@gmx.de>
Sent= : Friday, March 15, 2019 11:52am
To: "Dave T=C3=A4ht" <dave.taht@gm= ail.com>
Cc: ecn-sane@lists.bufferbloat.net, "bloat" <bloat@list= s.bufferbloat.net>
Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tc= pPrague] Implementation and experimentation of TCP Prague/L4S hackaton at I= ETF104

=0A
=0A

Hi Dave,


> On Mar 15, 2019, at 15:06, Dave Taht = <dave.taht@gmail.com> wrote:
>
> I would really pref= er to move this discussion to the ecn-sane mailing
> list, as IMHO,= ecn is generally such a tiny thing needed for good
> congestion co= ntrol compared to better transports like pacing + bbr,
> and things= like bql, fq, and aqm using drop.
>
> I'm going to keep c= c-ing that list in the hope that we can keep better
> track of the = discussion here.

Ah, sure, I basically wanted to avoid annoying= the ietf lists as I feel out of place there, having only had a cursory rea= d of the relevant RFCs.


>
> On Fri, Mar 15, 20= 19 at 6:01 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>>= ;
>> Hi Dave,
>>
>> I pruned the CC list= as I am out of my league here and want to restrict the radius of my embarr= assment to those that already know my level of incompetence 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 gra= sshopper". You
> have a firm grip on what can be achieved in the re= al world.
>
>>
>> That said, having read th= rough 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.
>
> I am so glad someone other than I has now read it.
&= gt;
>> The L4S project proposes a really wide-ranging change of= basically the internet (but allow a concurrent operation with legacy proba= bly to cater to the fact that an internet-wide flag-day seems daunting to o= rganize). 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 outs= ide 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...
>&= gt; Conceptually it seems much cleaner to use ECT(1) for congestion notific= ation directly (there are already proposals out there and SCE just added an= other fully back-ward compatible one) and find another way to mark l4s traf= fic, sure that is going to be hard and inconvenient, but if you set out to = change the internet that is par for the course.
>> IMHO they wou= ld 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 reduce= d diffserv and one group for new features, that would even
>
= > The existing diffserv deployment is a failure.

Which is a = shame, but one RFC's failure is another one's opportunity.


> 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
> a= nything else, especially not CS1.

I like the simplicity, but I = also like the split into two groups of 3 bits, say "active bit pattern" (fo= r transport purposes) and "intenden bit pattern" for the sender to transmit= intent, which than can be conveyed lossless to the receiver; my gut feelin= g is that throwing the transport people a bone here might work better, as i= n the end they are the one that will carry the "burden" of the change. IMHO= this has the additional advantage that it will make "tabula rasa" of the e= xisting distict set of bit patterns used in the real world. Which in turn p= robably is this ideas downfall...


>
>> allo= w for concurrent use of the inevitable L5S and L6S ;) ). Especially since a= s far as I can understand l4s actually would like to have a more gradual co= ngestion information stream than classic ECN, and since they need to modify= DCTCP anyway to make it save for the wider internet, replacing its ECN res= ponse should be well inside the scope of work they already have on their li= st.
>
> Next up for sce was going to be to find if dctcp c= ould be modified to
> use it. Also, bittorrent.

YES! I = endorse this message.

>
>> If I sound a bit miffe= d, 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 int= ernet, but rather that they are building an internet where I can be a bette= r "product" and customer of newfangled services, and I do not look forward = to such a facebooky future with much enthusiasm.
>
> I hav= e rigorously tried to keep the network neutrality debate out of
> t= his.

And I really do not want to start this here, as I agree th= at this is about a technical question. That said, I had hoped more out of t= he l4s promises from an end-user perspective. Then again, it if this is goi= ng to happen it needs the ISPs buy-in so it might be politically wise to em= phasize the advantages for ISPs.


> dualpi is just anoth= er aqm that needs the same thorough
> technical and public evaluati= on done to it that pie, codel, fq_codel
> were subjected to.
<= br />+1, I note that the main argument against fq is "we can do it with two= " without a convincing argument why two is better than the few 100s you rea= listically will never need for fq even on an busy core router.

&= gt; The use of ect_1 in dualpi for it is nuts IMHO,

At least it= is unclean...

> 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 wo= uld be distracting at this time.

But as I said, L4S aims to cha= nge everything so why stop there ;)

>
> 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.

I will happil= y look at specific sections of code if pointed to, but I will not actively = search for. At least the European net neutrality rules do not make any of t= hese illegal, as the rules allow for traffic management (and special servic= es at extra cost as long as these are not built be restricting the best-eff= ort net, no idea how that should be poiced) (and in the end the rules only = apply for ISPs in one's own network one can DPI to a far greater extent if = one is such inclined).


> 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 see a nice art-house movie coming up.

>
> I wish I knew a lawyer willing to take on "buffer= bloat.net vs the
> state of california", though, as it may come dow= n to that.
>
> I blew up on this part of the issue here:> http://blog.cerowrt.org/post/net_neutrality_customers/

= I read that, but it does not reflect to well on the situation this side of= the pond. We had situations where ISPs worked hard (but without success) t= o switch from their flat-rate access to introduce volume caps, that served = a dual purpose, a) extracting more revenue from customers and b) allowing t= o make "zero-rating" deals with content-providers (which in the end are als= o payed for by the end-users, indirectly). Sure, this is all normal in busi= ness, but that does not necessarily mean that I do need to like being a paw= n in a business transaction between global corporations. (I consider this t= o be at least somewhat related to the net neutrality debate).

Be= st Regards
Sebastian


>>
>> I hope = that the discussion in Prague go well and a compromise/consense can be hash= ed out as I see different implementations duking it out here, but the overa= ll goal of the competitors seems quite compatible, improving the internet b= y focussing on latency.
>>
>> Best Regards
>= > Sebastian
>>
>>> On Mar 15, 2019, at 11:46, = Dave Taht <dave.taht@gmail.com> wrote:
>>>
>&g= t;> 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 worldwi= de team of linux and freebsd developers co-ordinating on landing code for o= ur competing proposal "Some Congestion Experienced", which we submitted to = tsvwg last sunday.
>>>
>>> That draft is under= continuous revision, here:
>>>
>>> https://gi= thub.com/dtaht/bufferbloat-rfcs/blob/master/sce/draft-morton-taht-tsvwg-sce= .txt
>>>
>>> Our Linux and FreeBSD team is als= o flying into prague for SCE presentations at netdevconf and ietf.
>= ;>>
>>> Some background to this: after the L4S/TCP Pra= gue/and dualpi experiments appeared stalled out indefinitely in the IETF, a= nd with our own frustration with IETF processes, bufferbloat.net project me= mbers 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/
&= gt;>>
>>> We were unaware, until last month, that the = cable industry had 16 months back gone and formed its own private working g= roup also, and was intending to turn the tcp prague/l4s/dualpi IETF "experi= ments" into an actual DOCSIS standard.
>>>
>>>= Our SCE proposal appears to be backward compatible with the existing 10s-1= 00s 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 conge= stion control) at all in order to basically work. tcp-prague is subtly inco= mpatible 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 SC= E while remaining backward compatible with the existing meaning of the CE c= odepoint.
>>>
>>> In either case, either appro= ach essentially permanently redefines the ECT_1 codepoint incompatibly, onc= e 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 one= s described in https://www.ietf.org/rfc/ien/ien137.txt - I would really, re= ally, really prefer that they stay technical and not veer into politics, bu= t 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 f= lent.org 's and irtt's exhaustive suite of tests and servers in the cloud i= n 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 finall= y be able to write new tests for flent in particular, that can show tcpprag= ue off in the ways that are important to those developing it. Flent has som= e 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 i= n python)
>>>
>>> We also hope that more test = tools and implementations in ns2 and ns3 show up for tcpprauge and dualpi s= how up soon also, from members of those projects.
>>>
&= gt;>> Note: sunday's dual-pi linux submission was kicked back from th= e 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 wit= h current versions of OpenWrt, etc.
>>>
>>> Fi= nally, running code. Will we find consensus?
>>>
>&g= t;> Thx!
>>>
>>>
>>> [1] htt= ps://tools.ietf.org/html/rfc8290
>>> [2] sch_cake was availab= le 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 eer= o and evenroute.
>>>
>>> Cake has a docsis spe= cific mode which we longed for cablelabs to evaluate.
>>> >>>
>>> On Fri, Mar 15, 2019 at 2:33 AM Bob Bris= coe <ietf@bobbriscoe.net> wrote:
>>> Forwarding to tcpm= & iccrg - apologies if you were already on one of the lists that recei= ved this.
>>>
>>> Olivier has been working har= d 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 tre= e. This is his request for more people to get involved.
>>> <= br />>>>
>>> Bob
>>>
>>&g= t;
>>> -------- Forwarded Message --------
>>>= Subject: [tcpPrague] Implementation and experimentation of TCP Prague/L4S = hackaton at IETF104
>>> Date: Wed, 6 Mar 2019 10:26:05 +0000<= br />>>> From: Tilmans, Olivier (Nokia - BE/Antwerp) <olivier.t= ilmans@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 Mis= und <joakim.misund@gmail.com>, Bob Briscoe <research@bobbriscoe.ne= t>, Quentin De Coninck <quentin.deconinck@uclouvain.be>, Fran=C3= =A7ois Michel <francois.michel@uclouvain.be>, Mirja Kuehlewind <mi= rja.kuehlewind@tik.ee.ethz.ch>, Maxime Piraux <maxime.piraux@uclouvai= n.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>
>>>
>>&= gt; Hi all,
>>>
>>> We'll be working on the "T= CP 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 Prag= ue 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. D= epending on people's interest, prototyping something similar for QUIC is an= other possible output.
>>>
>>> Details and lin= ks to resources/supporting drafts are available at https://trac.ietf.org/tr= ac/ietf/meeting/wiki/104hackathon#tcp-prague and copied below.
>>= ;> Additionally, few topics will presented during netdev 0x13 the week b= efore.
>>>
>>> See you in Prague.
>>= ;>
>>> Best,
>>> Olivier
>>> =
>>>
>>> Implementation and experimentation of= TCP Prague/L4S
>>>
>>> * Champion
>&g= t;> * Olivier Tilmans <olivier.tilmans at nokia-bell-labs.com>
>>> * Projects
>>> * Prototype the "TCP Prague" co= ngestion control on Linux
>>> * Finalize the implementation o= f accurate ECN (draft conformance), and port it on Linux v5.x * Build tooli= ng around L4S to let people experiment with the technology (e.g., virtual m= achine, 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-= ecn-l4s-id-05#page-21
>>> * Upcoming netdev talk =E2=80=94 ht= tps://netdevconf.org/0x13/session.html?talk-tcp-prague-l4s
>>>= ; * Accurate ECN
>>> * Specs =E2=80=94 https://tools.ietf.org= /html/draft-ietf-tcpm-accurate-ecn-07
>>> * Implementation fo= r Linux v4.17 =E2=80=94 https://github.com/mirjak/linux-accecn
>>= ;> * Past netdev talk =E2=80=94 https://www.netdevconf.org/2.2/session.h= tml?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.html?ta= lk-chirp
>>> * L4S architecture
>>> * Specs =E2= =80=94 https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03
>&g= t;> * DualPI2 AQM
>>> * Specs =E2=80=94 https://tools.ietf= .org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08
>>> * Reposit= ory =E2=80=94 https://github.com/L4STeam/sch_dualpi2_upstream
>>= > * Upcoming netdev talk =E2=80=94 https://netdevconf.org/0x13/session.h= tml?talk-DUALPI2-AQM
>>> * RITE Project =E2=80=94 https://rit= eproject.eu/dctth/#code
>>> _________________________________= ______________
>>> tcpPrague mailing list
>>> t= cpPrague@ietf.org
>>> https://www.ietf.org/mailman/listinfo/t= cpprague
>>> _______________________________________________<= br />>>> iccrg mailing list
>>> iccrg@irtf.org
= >>> https://www.irtf.org/mailman/listinfo/iccrg
>>> =
>>>
>>> --
>>>
>>&g= t; Dave T=C3=A4ht
>>> CTO, TekLibre, LLC
>>> ht= tp://www.teklibre.com
>>> Tel: 1-831-205-9740
>>&g= t; _______________________________________________
>>> Bloat = mailing list
>>> Bloat@lists.bufferbloat.net
>>>= ; https://lists.bufferbloat.net/listinfo/bloat
>>
> >
> --
>
> Dave T=C3=A4ht
> CTO, Te= kLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740=

_______________________________________________
Ecn-sane m= ailing list
Ecn-sane@lists.bufferbloat.net
https://lists.bufferbl= oat.net/listinfo/ecn-sane

=0A
 ------=_20190315130123000000_84948--