On March 15, 2019 6:01:23 PM GMT+01:00, "David P. Reed" <dpr...@deepplum.com> 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. (this is in the Best Practices RFC) >
IMHO it is the Charme of the 2 times 3 bits approach, that carriers get 3 bits they can do with whatever they want. As VLAN tags and MPLS? only support 3 bit priorities this looks to me like a match made in heaven, and we get 3 bits with end to end guarantees. Not that rolling that out would ever work in reality.... Best Regards Sebastian And yes, this is not an idea I came up with, I just forgot who proposed that initially. >And 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 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. > >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. > >So if the responsible network engineers in the carriers cannot agree on >anything, IETF is wasting its time. > > > > >-----Original Message----- >From: "Sebastian Moeller" <moell...@gmx.de> >Sent: Friday, March 15, 2019 11:52am >To: "Dave Täht" <dave.t...@gmail.com> >Cc: ecn-s...@lists.bufferbloat.net, "bloat" ><bloat@lists.bufferbloat.net> >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 <dave.t...@gmail.com> wrote: >> >> 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. > >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. > > >> >> On Fri, Mar 15, 2019 at 6:01 AM Sebastian Moeller <moell...@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 embarrassment 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 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 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. >> >>> 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. >>> 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 >> >> 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 >> anything else, especially not CS1. > >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. 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. Which in turn >probably is this ideas downfall... > > >> >>> 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. >> >> Next up for sce was going to be to find if dctcp could be modified to >> use it. Also, bittorrent. > > YES! I endorse this message. > >> >>> 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. >> >> I have rigorously tried to keep the network neutrality debate out of >> this. > >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 perspective. 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. > > >> 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. > >+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. > >> 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 would be distracting at this time. > > But as I said, L4S aims to change 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 happily 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 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). > > >> 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 "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 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) 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). 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. (I consider this to >be at least somewhat related to the net neutrality debate). > >Best Regards > Sebastian > > >>> >>> 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 <dave.t...@gmail.com> wrote: >>>> >>>> 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 <i...@bobbriscoe.net> >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) ><olivier.tilm...@nokia-bell-labs.com> >>>> To: hackat...@ietf.org <hackat...@ietf.org>, tcppra...@ietf.org ><tcppra...@ietf.org> >>>> CC: dleb...@google.com <dleb...@google.com>, Joakim Misund ><joakim.mis...@gmail.com>, Bob Briscoe <resea...@bobbriscoe.net>, >Quentin De Coninck <quentin.deconi...@uclouvain.be>, François Michel ><francois.mic...@uclouvain.be>, Mirja Kuehlewind ><mirja.kuehlew...@tik.ee.ethz.ch>, Maxime Piraux ><maxime.pir...@uclouvain.be>, Olga Albisser <o...@albisser.org>, Fabien >Duchêne <fabien.duch...@uclouvain.be>, De Schepper, Koen (Nokia - >BE/Antwerp) <koen.de_schep...@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—i.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. >>>> >>>> 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 — https://github.com/L4STeam/tcp-prague >>>> * Requirements — >https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-21 >>>> * Upcoming netdev talk — >https://netdevconf.org/0x13/session.html?talk-tcp-prague-l4s >>>> * Accurate ECN >>>> * Specs — >https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07 >>>> * Implementation for Linux v4.17 — >https://github.com/mirjak/linux-accecn >>>> * Past netdev talk — >https://www.netdevconf.org/2.2/session.html?kuhlewind-accecn-talk >>>> * Paced Chirping * Repository — >https://github.com/JoakimMisund/PacedChirping >>>> * Upcoming netdev talk — >https://netdevconf.org/0x13/session.html?talk-chirp >>>> * L4S architecture >>>> * Specs — https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03 >>>> * DualPI2 AQM >>>> * Specs — >https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08 >>>> * Repository — https://github.com/L4STeam/sch_dualpi2_upstream >>>> * Upcoming netdev talk — >https://netdevconf.org/0x13/session.html?talk-DUALPI2-AQM >>>> * RITE Project — https://riteproject.eu/dctth/#code >>>> _______________________________________________ >>>> tcpPrague mailing list >>>> tcppra...@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpprague >>>> _______________________________________________ >>>> iccrg mailing list >>>> ic...@irtf.org >>>> https://www.irtf.org/mailman/listinfo/iccrg >>>> >>>> >>>> -- >>>> >>>> Dave Täht >>>> 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äht >> CTO, TekLibre, LLC >> http://www.teklibre.com >> Tel: 1-831-205-9740 > >_______________________________________________ >Ecn-sane mailing list >ecn-s...@lists.bufferbloat.net >https://lists.bufferbloat.net/listinfo/ecn-sane -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat