From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 1F96D3BA8E; Fri, 15 Mar 2019 13:45:06 -0400 (EDT) Received: from [192.168.1.133] ([77.189.129.198]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MWQSM-1hWpEb0Svy-00XcDQ; Fri, 15 Mar 2019 18:45:03 +0100 Date: Fri, 15 Mar 2019 18:45:00 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <1552669283.555112988@apps.rackspace.com> References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: "David P. Reed" CC: =?ISO-8859-1?Q?Dave_T=E4ht?= , ecn-sane@lists.bufferbloat.net, bloat From: Sebastian Moeller Message-ID: <3024926A-8F0C-46A6-AF25-C0B81C13799F@gmx.de> X-Provags-ID: V03:K1:0K2f5t92/Kewpvkm00A0WdEsUBJ6V+dOXD0/F4bpMpqg2ZHKhL1 8HIsd/ZvAAEyZDu1NYUuzwhIRmqwopm+PAhhO0zt3RHjHZYKHO8JfLoTvB7aOPiJl8/vajX fsILDsZVBOy5tqLPkkSMYVA2CBOPpsw1Y/h5iSyjDa2VKEfspubUNcif8FPy7s69lmaFipw ch1ylPGHo7E4iIxaJZcdA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:xPAF0lZAKKs=:IWlNsN9e/G+xkXvrMiCeol ExtthNiRQFyEU59YTUAzzb9o7CL+0ru7bXYwOhJL9QPQSiy04wnt1oMXBG7bCrx1OwiEdzPz1 aqdFg+/+oBF9rylXR2zAnXzWYNinswtpD5Qidr8Fpf38iRPFUm7OJVTaUFeElBV4+szW2v+a5 1dPn0hZkoqNvUd/GVVEAlkSizY6OokmeVoNWh0/Tk6brgXuf3IF52iglCLkm2kJ2hIC4C1ByB naphEmoigBBcbqmy62Bde/6F3yeW4xm4YGY0Ilwf7ncOSIA7dw0aIbrY+fJGgv8GPK2Q5uMYO MdXrCxNQX6MlBL+69VQvlWWHSFUJav6cbUMTmcsL8X/bmqoIvlxlHnamGt0XssNkaJn5mBPsP RDG/ZgnSNxPA3oNiAzIMFGV9gBDRAh8rpu+w6VZ6E41ycECfM+SSozlqIjzkSzZje6OtPgf6t Z72ozAvPO0gsp4zFvtocoC8lGwPssuou787ncGXKShgeckZejarDxQqb0VCKI1EOGo7nJYAch ewnvakb0pa3OMzkFGquOfw5xlaXHmAjEoUsUdD43I9CMTkZ7Kp8T7eAWslDINI9Qt+8zjPXLJ ks9IbLhcBomODUQxIebRh0GdqI+1RcYCIwjp/JqTpiH0MJdIFP9cr62SKte7TkSKnbiVtEbtp iRqZg6XVpmz8MjRu3Inlme01mdwyEDFjd+RM1HZ3UDVB1xuC8eOmHdx/dlPiuHsn2dge3EcXA SMVpp4oaUq9liCzpeyEb0U9nMs8xRwsB5xCtAFT4DmTTmPUa4kRuWcPMQ3MZokiAnnYoD3iRi H78tT9nZ4WqreuqkbusGBSR0osuz8RU7yp1VDHPTUEFrxJzhWV5/3ZZXEfJU8Cn3mLKAu6JG7 E76/+ClKSPXwwNp6LqJLT/gzTULTPrQF2Dqzp6nTEXbDoZcjBcrqh17wmwjQoqGExMIbeU0LK NQbdxFFbWSQ== Subject: Re: [Bloat] [Ecn-sane] [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 17:45:07 -0000 On March 15, 2019 6:01:23 PM GMT+01:00, "David P=2E Reed" wrote: > >The absolute fundamental 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=2E (this is in the Best Practices RFC) >=20 IMHO it is the Charme of the 2 times 3 bits approach, that carriers get 3 = bits they can do with whatever they want=2E As VLAN tags and MPLS? only sup= port 3 bit priorities this looks to me like a match made in heaven, and we = get 3 bits with end to end guarantees=2E Not that rolling that out would ev= er work in reality=2E=2E=2E=2E Best Regards Sebastian And yes, this is not an idea I came up with, I just forgot who proposed th= at initially=2E >And it's not for lack of trying=2E 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 was 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=2E >=20 >They couldn't even agree (after about 18 months of meetings) about what >the bullshit English intent was, much less what operational semantics >in the packet forwarding network had to be=2E >=20 >So if the responsible network engineers in the carriers cannot agree on >anything, IETF is wasting its time=2E >=20 >=20 >=20 >=20 >-----Original Message----- >From: "Sebastian Moeller" >Sent: Friday, March 15, 2019 11:52am >To: "Dave T=C3=A4ht" >Cc: ecn-sane@lists=2Ebufferbloat=2Enet, "bloat" > >Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation >and experimentation of TCP Prague/L4S hackaton at IETF104 > > > >Hi Dave, > > >> On Mar 15, 2019, at 15:06, Dave Taht wrote: >>=20 >> 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=2E >>=20 >> I'm going to keep cc-ing that list in the hope that we can keep >better >> track of the discussion here=2E > >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=2E > > >>=20 >> On Fri, Mar 15, 2019 at 6:01 AM Sebastian Moeller >wrote: >>>=20 >>> Hi Dave, >>>=20 >>> 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=2E >>=20 >> IMHO, your work on educating the OpenWrt community over the years on >> how to use sqm, makes you much more than "only a grasshopper"=2E You >> have a firm grip on what can be achieved in the real world=2E >>=20 >>>=20 >>> 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=2E >>=20 >> I am so glad someone other than I has now read it=2E >>=20 >>> 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)=2E 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=2E=2E=2E >>> 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=2E >>> IMHO they would do more good if they actually fought for a better >use of the 6 DSCP bits instead=2E (say by splitting into two groups of 3 >bits, one group for reduced diffserv and one group for new features, >that would even >>=20 >> The existing diffserv deployment is a failure=2E > > Which is a shame, but one RFC's failure is another one's opportunity=2E > > >> 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=2E One big >battle >> at a time=2E > >:) > >> 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=2E > >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 be >conveyed lossless to the receiver; my gut feeling is that throwing the >transport people a bone here might work better, as in the end they are >the one that will carry the "burden" of the change=2E IMHO this has the >additional advantage that it will make "tabula rasa" of the existing >distict set of bit patterns used in the real world=2E Which in turn >probably is this ideas downfall=2E=2E=2E > > >>=20 >>> allow for concurrent use of the inevitable L5S and L6S ;) )=2E >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=2E >>=20 >> Next up for sce was going to be to find if dctcp could be modified to >> use it=2E Also, bittorrent=2E > > YES! I endorse this message=2E > >>=20 >>> If I sound a bit miffed, it is because after reading >https://tools=2Eietf=2Eorg/html/draft-ietf-tsvwg-l4s-arch-03 I do not hav= e >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=2E >>=20 >> I have rigorously tried to keep the network neutrality debate out of >> this=2E > >And I really do not want to start this here, as I agree that this is >about a technical question=2E That said, I had hoped more out of the l4s >promises from an end-user perspective=2E 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=2E > > >> 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=2E > >+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 >realistically will never need for fq even on an busy core router=2E > >> The use of ect_1 in dualpi for it is nuts IMHO, > > At least it is unclean=2E=2E=2E > >> 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=2E > > But as I said, L4S aims to change everything so why stop there ;) > >>=20 >> 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=2E > >I will happily look at specific sections of code if pointed to, but I >will not actively search for=2E At least the European net neutrality >rules do not make any 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 best-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 extent if one is such inclined)=2E > > >> 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=2E > > I see a nice art-house movie coming up=2E > > >>=20 >> I wish I knew a lawyer willing to take on "bufferbloat=2Enet vs the >> state of california", though, as it may come down to that=2E >>=20 >> I blew up on this part of the issue here: >> http://blog=2Ecerowrt=2Eorg/post/net_neutrality_customers/ > >I read that, but it does not reflect to well on the situation this side >of the pond=2E We had situations where ISPs worked hard (but without >success) to switch from their flat-rate access to introduce volume >caps, that served a dual purpose, a) extracting more revenue from >customers and b) allowing to make "zero-rating" deals with >content-providers (which in the end are also payed for by the >end-users, indirectly)=2E Sure, this is all normal in business, but that >does not necessarily mean that I do need to like being a pawn in a >business transaction between global corporations=2E (I consider this to >be at least somewhat related to the net neutrality debate)=2E > >Best Regards > Sebastian > > >>>=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=2E >>>=20 >>> Best Regards >>> Sebastian >>>=20 >>>> On Mar 15, 2019, at 11:46, Dave Taht wrote: >>>>=20 >>>> Bufferbloat=2Enet's ecn-sane working group members have a >co-ordinated response to your efforts brewing but it's not ready yet=2E >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=2E >>>>=20 >>>> That draft is under continuous revision, here: >>>>=20 >>>> >https://github=2Ecom/dtaht/bufferbloat-rfcs/blob/master/sce/draft-morton-= taht-tsvwg-sce=2Etxt >>>>=20 >>>> Our Linux and FreeBSD team is also flying into prague for SCE >presentations at netdevconf and ietf=2E >>>>=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=2Enet project members >publicly formed our own working group to look into the problems with >ecn, back in august of last year=2E >>>>=20 >>>> Its charter is here: >https://www=2Ebufferbloat=2Enet/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=2E >>>>=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=2E tcp-prague is subtly incompatible with that, and >dualpi, more so=2E 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=2E >>>>=20 >>>> In either case, either approach essentially permanently redefines >the ECT_1 codepoint incompatibly, once and for all, and for all time=2E >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=2Eietf=2Eorg/rfc/ien/ien137=2Etxt - I would really, really, >really prefer that they stay technical and not veer into politics, but >I have little hope for that=2E >>>>=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=2Eorg '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=2E 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=2E Flent has some basic dctcp tests, >but nothing that can get down below a 20ms sample rate on modern >hardware=2E (currently=2E 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=2E >>>>=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=2Eozlabs=2Eorg/patch/1054521= / >) , and I do hope that a corrected version lands soon, so we can safely >test it with current versions of OpenWrt, etc=2E >>>>=20 >>>> Finally, running code=2E Will we find consensus? >>>>=20 >>>> Thx! >>>>=20 >>>>=20 >>>> [1] https://tools=2Eietf=2Eorg/html/rfc8290 >>>> [2] sch_cake was available for 3 years out of tree and was >mainlined last august, in linux 4=2E19=2E It is partially described by >"Piece of CAKE: A Comprehensive Queue Management Solution for Home >Gateways" "https://arxiv=2Eorg/pdf/1804=2E07617=2Epdf >>>>=20 >>>> A second paper describing its fq_codel-derived "cobalt" AQM >algorithm is awaiting publication in a peer reviewed journal=2E 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=2E >>>>=20 >>>> Cake has a docsis specific mode which we longed for cablelabs to >evaluate=2E >>>>=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=2E >>>>=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=2E This is his request for >more people to get involved=2E >>>>=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=2Eorg , tcpprague@ietf=2Eorg > >>>> CC: dlebrun@google=2Ecom , Joakim Misund >, Bob Briscoe , >Quentin De Coninck , Fran=C3=A7ois Mi= chel >, Mirja Kuehlewind >, Maxime Piraux >, Olga Albisser , Fa= bien >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=2E >>>> 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=2Ee=2E, meet the safety requirements and have >supporting materials (e=2Eg=2E, VMs, labs) to let people experiment with >it=2E Depending on people's interest, prototyping something similar for >QUIC is another possible output=2E >>>>=20 >>>> Details and links to resources/supporting drafts are available at >https://trac=2Eietf=2Eorg/trac/ietf/meeting/wiki/104hackathon#tcp-prague >and copied below=2E >>>> Additionally, few topics will presented during netdev 0x13 the week >before=2E >>>>=20 >>>> See you in Prague=2E >>>>=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=2Ex * Build tooling around L4S to let people >experiment with the technology (e=2Eg=2E, virtual machine, or mininet lab= s) >>>> * Work towards "QUIC Prague" >>>> * Resources >>>> * TCP Prague >>>> * Repository =E2=80=94 https://github=2Ecom/L4STeam/tcp-prague >>>> * Requirements =E2=80=94 >https://tools=2Eietf=2Eorg/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-21 >>>> * Upcoming netdev talk =E2=80=94 >https://netdevconf=2Eorg/0x13/session=2Ehtml?talk-tcp-prague-l4s >>>> * Accurate ECN >>>> * Specs =E2=80=94 >https://tools=2Eietf=2Eorg/html/draft-ietf-tcpm-accurate-ecn-07 >>>> * Implementation for Linux v4=2E17 =E2=80=94 >https://github=2Ecom/mirjak/linux-accecn >>>> * Past netdev talk =E2=80=94 >https://www=2Enetdevconf=2Eorg/2=2E2/session=2Ehtml?kuhlewind-accecn-talk >>>> * Paced Chirping * Repository =E2=80=94 >https://github=2Ecom/JoakimMisund/PacedChirping >>>> * Upcoming netdev talk =E2=80=94 >https://netdevconf=2Eorg/0x13/session=2Ehtml?talk-chirp >>>> * L4S architecture >>>> * Specs =E2=80=94 https://tools=2Eietf=2Eorg/html/draft-ietf-tsvwg-l4= s-arch-03 >>>> * DualPI2 AQM >>>> * Specs =E2=80=94 >https://tools=2Eietf=2Eorg/html/draft-ietf-tsvwg-aqm-dualq-coupled-08 >>>> * Repository =E2=80=94 https://github=2Ecom/L4STeam/sch_dualpi2_upstr= eam >>>> * Upcoming netdev talk =E2=80=94 >https://netdevconf=2Eorg/0x13/session=2Ehtml?talk-DUALPI2-AQM >>>> * RITE Project =E2=80=94 https://riteproject=2Eeu/dctth/#code >>>> _______________________________________________ >>>> tcpPrague mailing list >>>> tcpPrague@ietf=2Eorg >>>> https://www=2Eietf=2Eorg/mailman/listinfo/tcpprague >>>> _______________________________________________ >>>> iccrg mailing list >>>> iccrg@irtf=2Eorg >>>> https://www=2Eirtf=2Eorg/mailman/listinfo/iccrg >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Dave T=C3=A4ht >>>> CTO, TekLibre, LLC >>>> http://www=2Eteklibre=2Ecom >>>> Tel: 1-831-205-9740 >>>> _______________________________________________ >>>> Bloat mailing list >>>> Bloat@lists=2Ebufferbloat=2Enet >>>> https://lists=2Ebufferbloat=2Enet/listinfo/bloat >>>=20 >>=20 >>=20 >> -- >>=20 >> Dave T=C3=A4ht >> CTO, TekLibre, LLC >> http://www=2Eteklibre=2Ecom >> Tel: 1-831-205-9740 > >_______________________________________________ >Ecn-sane mailing list >Ecn-sane@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/ecn-sane --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E