Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi Bob, I note that all the non-dependent claims of US20170019343A1 (claims 1,14,22) seem to assume use of the proportional-integral controller (Note, I am not a lawyer, and especially not a patent lawyer). In Appendix B of draft-briscoe-tsvwg-aqm-dualq-coupled, an alternate algorithm

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Bob, Thanks, this is interesting. As you probably know this patent has come to the attention of the Linux community and caused some concern: https://lwn.net/Articles/784125/ so it's useful to know of a potential workaround. Alex On Mon, Mar 25, 2019 at 1:34 AM Bob Briscoe wrote: > Alex,

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On Sun, Mar 17, 2019 at 6:06 PM Mikael Abrahamsson wrote: > > > > On Sat, 16 Mar 2019, Holland, Jake wrote: > > > > > Granted, it still remains to be seen whether SCE in practice can match > > > the results of L4S, and L4S was here first. But it seems to me L4S comes > > > with some problems

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

That is an interesting point. The goal of that MUST statement is to ensure per-flow-fairness. Since fq provides per-flow-fairness as a guarantee via DRR, there is no need to actively apply that rule, it should just be an emergent property of the scheduling. -Greg From: "Holland, Jake"

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Thanks Greg, But wouldn’t this potentially violate at least one MUST from section 5.2 of l4s-id? The likelihood that an AQM drops a Not-ECT Classic packet (p_C) MUST be roughly proportional to the square of the likelihood that it would have marked it if it had been an L4S packet (p_L)

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Sun, Mar 17, 2019 at 6:06 PM Mikael Abrahamsson wrote: > > On Sat, 16 Mar 2019, Holland, Jake wrote: > > > Granted, it still remains to be seen whether SCE in practice can match > > the results of L4S, and L4S was here first. But it seems to me L4S comes > > with some problems that have not

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

thanks, David - that's the information I was looking for. v On Sun, Mar 17, 2019 at 2:07 PM David P. Reed wrote: > Vint - > > > > BBR is the end-to-end control logic that adjusts the source rate to match > the share of the bolttleneck link it should use. > > > > It depends on getting reliable

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

where does BBR fit into all this? v On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake wrote: > On 2019-03-15, 11:37, "Mikael Abrahamsson" wrote: > L4S has a much better possibility of actually getting deployment into > the > wider Internet packet-moving equipment than anything being

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Roland, On 22/03/2019 13:53, Bless, Roland (TM) wrote: Hi Bob, see inline. Am 21.03.19 um 14:24 schrieb Bob Briscoe: On 21/03/2019 08:49, Bless, Roland (TM) wrote: Hi, Am 21.03.19 um 09:02 schrieb Bob Briscoe: Just to rapidly reply, On 21/03/2019 07:46, Jonathan Morton wrote: The ECN

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Alex, inline... On 24/03/2019 21:15, alex.b...@ealdwulf.org.uk wrote: Hi Bob, I note that all the non-dependent claims of US20170019343A1 (claims 1,14,22) seem to assume use of the proportional-integral controller (Note, I am not a lawyer, and especially not a patent lawyer). Yes, as I

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

For enterprise networks interconnection to the cloud (public or private) can be done with e2e DSCP marking. This is just part of products available at AWS/Azure w/ or w/o their own interconnection network (direct connect, express route) and used regularly to ameliorate QoS of RTC applications such

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi Michael, thanks for the pointer. Looking forward to the talk... Regards Roland On 23.03.19 at 18:48 Michael Welzl wrote: > Hi, > > I’ll do what academics do and add our own data point, below: > >> On Mar 23, 2019, at 4:19 PM, Roland Bless > > wrote: >> >> Hi

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi Jonathan, On 23.03.19 at 16:03 Jonathan Morton wrote: >> On 23 Mar, 2019, at 11:02 am, Mikael Abrahamsson wrote: >> >> On Sat, 23 Mar 2019, Roland Bless wrote: >> >>> I suggest to use an additional DSCP to mark L4S packets. >> >> DSCP doesn't work end-to-end on the Internet, so what you're

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi Mikael, On 23.03.19 at 18:16 Mikael Abrahamsson wrote: > On Sat, 23 Mar 2019, Roland Bless wrote: > >> It's true that DSCPs may be remarked, but RFC 2474 >> already stated >> >>   Packets received with an unrecognized codepoint SHOULD be forwarded >>   as if they were marked for the Default

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Our paper has some data - again, fig. 4. That’s an AS level analysis, for the data that we had (which wasn’t huge - a couple thousand paths). For the majority of measurements, the DSCP survived more than 1 AS hop; in case of IPv6, the majority survived more than 2. Cheers, Michael > On Mar

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Sat, 23 Mar 2019, Luca Muscariello wrote: It the app runs in the cloud and the cloud has direct peering links to your branch office or SP most likely DSCP works. Do you have numbers to back this statement up? In my experience direct peering links has nothing to do with this, instead

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

WebEx, WebRTC they use it. QoS works. To answer the question in the title of Michael’s paper. It the app runs in the cloud and the cloud has direct peering links to your branch office or SP most likely DSCP works. And going back to Roland’s proposal, it seems the most natural approach instead of

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi, I’ll do what academics do and add our own data point, below: > On Mar 23, 2019, at 4:19 PM, Roland Bless wrote: > > Hi Mikael, > > On 23.03.19 at 11:02 Mikael Abrahamsson wrote: >> On Sat, 23 Mar 2019, Roland Bless wrote: >> >>> I suggest to use an additional DSCP to mark L4S packets. >>

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi Mikael, On 23.03.19 at 11:02 Mikael Abrahamsson wrote: > On Sat, 23 Mar 2019, Roland Bless wrote: > >> I suggest to use an additional DSCP to mark L4S packets. > > DSCP doesn't work end-to-end on the Internet, so what you're suggesting > isn't a workable solution. It's true that DSCPs may

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On 23 Mar, 2019, at 11:02 am, Mikael Abrahamsson wrote: > > On Sat, 23 Mar 2019, Roland Bless wrote: > >> I suggest to use an additional DSCP to mark L4S packets. > > DSCP doesn't work end-to-end on the Internet, so what you're suggesting isn't > a workable solution. An interesting

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Sat, 23 Mar 2019, Roland Bless wrote: I suggest to use an additional DSCP to mark L4S packets. DSCP doesn't work end-to-end on the Internet, so what you're suggesting isn't a workable solution. -- Mikael Abrahamssonemail: swm...@swm.pp.se

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

+1 On Sat, Mar 23, 2019 at 9:02 AM Roland Bless wrote: > Hi, > > On 22.03.19 at 19:28 Victor Hou wrote: > > > Broadcom has been deeply involved in developing the Low Latency DOCSIS > > cable industry specification that Bob Briscoe mentioned. We concur with > > the L4S use of ECT(1). L4S can

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi, On 22.03.19 at 19:28 Victor Hou wrote: > Broadcom has been deeply involved in developing the Low Latency DOCSIS > cable industry specification that Bob Briscoe mentioned.  We concur with > the L4S use of ECT(1).  L4S can be implemented either in a dual-queue or > an fq implementation. SCE

[Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Mon Mar 18 21:06:57 EDT 2019, Bob Briscoe said: >>> * In summer 2017 CableLabs started work on Low Latency DOCSIS, and hired me later in the year to help develop and specify it, along with support for L4S o In Jan 2019 the Low Latency DOCSIS spec was published and is now being

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi Bob, see inline. Am 21.03.19 um 14:24 schrieb Bob Briscoe: > On 21/03/2019 08:49, Bless, Roland (TM) wrote: >> Hi, >> >> Am 21.03.19 um 09:02 schrieb Bob Briscoe: >>> Just to rapidly reply, >>> >>> >>> On 21/03/2019 07:46, Jonathan Morton wrote: The ECN field was never intended to be

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Roland, On 21/03/2019 08:49, Bless, Roland (TM) wrote: Hi, Am 21.03.19 um 09:02 schrieb Bob Briscoe: Just to rapidly reply, On 21/03/2019 07:46, Jonathan Morton wrote: The ECN field was never intended to be used as a classifier, except to distinguish Not-ECT flows from ECT flows (which a

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi, Am 21.03.19 um 09:02 schrieb Bob Briscoe: > Just to rapidly reply, > > > On 21/03/2019 07:46, Jonathan Morton wrote: >> The ECN field was never intended to be used as a classifier, except to >> distinguish Not-ECT flows from ECT flows (which a middlebox does need >> to know, to choose

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On Mar 21, 2019, at 07:04, Bob Briscoe wrote: > > [...] > As regards the desire to use SCE instead of the L4S approach of using a > classifier, please answer all the reasons I gave for why that won't work, > which I sent in response to your draft some days ago. Is there any work

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Just to rapidly reply, On 21/03/2019 07:46, Jonathan Morton wrote: The ECN field was never intended to be used as a classifier, except to distinguish Not-ECT flows from ECT flows (which a middlebox does need to know, to choose between mark and drop behaviours). It was intended to be used to

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On 21 Mar, 2019, at 8:04 am, Bob Briscoe wrote: > Congestion controls are tricky to get stable in all situations. So it is > important to separate ideas and research from engineering of more mature > approaches that are ready for more widespread experimentation on the public > Internet. Our

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Jonathan, On 20/03/2019 23:51, Jonathan Morton wrote: On 21 Mar, 2019, at 1:29 am, Bob Briscoe wrote: But more importantly, the L4S usage couples the minimized latency use case to any possibility of getting a high fidelity explicit congestion signal, so the "maximize throughput" use case

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On 21 Mar, 2019, at 1:29 am, Bob Briscoe wrote: > >> But more importantly, the L4S usage couples the minimized latency use >> case to any possibility of getting a high fidelity explicit congestion >> signal, so the "maximize throughput" use case can't ever get it. > Eh? There's definitely a

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Jake, On 20/03/2019 19:04, Holland, Jake wrote: Hi Bob & Greg, I agree there has been a reasonably open conversation about the L4S work, and thanks for all your efforts to make it so. However, I think there's 2 senses in which "private" might be fair that I didn't see covered in your

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On 20 Mar, 2019, at 11:48 pm, Greg White wrote: > > the dual queue mechanism is not the only way to support L4S and TCP Prague. > As we’ve mentioned a time or two, an fq_codel system can also support L4S and > TCP Prague. I’m not aware that anyone has implemented it to test it out yet >

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

I responded to point 2 separately. In response to point 1, the dual queue mechanism is not the only way to support L4S and TCP Prague. As we’ve mentioned a time or two, an fq_codel system can also support L4S and TCP Prague. I’m not aware that anyone has implemented it to test it out yet

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On 2019-03-20, 12:58, "Stephen Hemminger" wrote: Has anyone done a detailed investigation for prior art? I don't know, but for serendipitous reasons I recently came across this, which may be interesting to those who would be interested in digging further on that question:

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Wed, 20 Mar 2019 19:04:17 + "Holland, Jake" wrote: > Hi Bob & Greg, > > I agree there has been a reasonably open conversation about the L4S > work, and thanks for all your efforts to make it so. > > However, I think there's 2 senses in which "private" might be fair that > I didn't see

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi Bob & Greg, I agree there has been a reasonably open conversation about the L4S work, and thanks for all your efforts to make it so. However, I think there's 2 senses in which "private" might be fair that I didn't see covered in your rebuttals (merging forks and including Greg's rebuttal by

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Dear All, > On Mar 20, 2019, at 00:59, Dave Taht wrote: > > On Tue, Mar 19, 2019 at 5:44 AM Greg White wrote: >> [...] >> But, L4S has been demonstrated in real equipment and in simulation, and >> leverages an existing congestion > > Not under circumstances I can control. That's Not

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Tue, Mar 19, 2019 at 5:44 AM Greg White wrote: > > That is ridiculous. > > > > You clearly haven’t read the drafts, and so are speaking from a position of > ignorance. Please get informed before making statements like this. I've read all the drafts, 3 times, and made pithy comments when

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On Mar 19, 2019, at 05:44, Greg White wrote: > If I can boil this down for the people who are jumping into this without > reading the drafts: > > • Both L4S and SCE are attempting to provide congestion-controlled > senders with better congestion signals so that flows can achieve

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On Mar 19, 2019, at 08:10, Jonathan Morton wrote: > >> On 19 Mar, 2019, at 7:52 am, Greg White wrote: >> >> L4S utilizes TCP Prague, which falls back to traditional congestion control >> if the bottleneck link doesn't provide isolation. > > You see, this is the part I find difficult to

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On 19 Mar, 2019, at 7:52 am, Greg White wrote: > > L4S utilizes TCP Prague, which falls back to traditional congestion control > if the bottleneck link doesn't provide isolation. You see, this is the part I find difficult to believe that it will operate reliably. For a start, I have seen

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On 3/18/19, 11:35 PM, "Jonathan Morton" wrote: From my standpoint, the major objection to L4S is that it is not incrementally deployable, because DCTCP starves conventional TCPs unless run through an isolated queue. This is something we quickly realised when L4S was first announced.

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> • SCE will only work if the bottleneck link implements fq. Some > bottleneck network gear will not be able to implement fq or will not > implement it due to its undesirable side effects (see section 6 of RFC 8290). > SCE leverages a paragraph in a draft that describes a first guess

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

That is ridiculous. You clearly haven’t read the drafts, and so are speaking from a position of ignorance. Please get informed before making statements like this. There is *absolutely* nothing cable-specific or “private” about L4S. It is being developed in an open forum, the IETF!! Yes,

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Tue, Mar 19, 2019 at 2:07 AM Bob Briscoe wrote: > > David, > > On 17/03/2019 18:07, David P. Reed wrote: > > Vint - > > > > BBR is the end-to-end control logic that adjusts the source rate to match the > share of the bolttleneck link it should use. > > > > It depends on getting reliable

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

David, On 17/03/2019 18:07, David P. Reed wrote: Vint - BBR is the end-to-end control logic that adjusts the source rate to match the share of the bolttleneck link it should use. It depends on getting reliable current congestion information via packet drops and/or ECN. So the proposal

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Sun, 17 Mar 2019, Luca Muscariello wrote: Fq_codel has an outstanding footprint in terms of deployment. No, it doesn't. A logical next step to me seems to push chipcos to build fq_codel in silicon. It is totally feasible. ... and how do you plan to make that happen? -- Mikael

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Luca Muscariello writes: > To me there is substantial difference from something like fq_codel or > fq_pie where service differentiation is largely implicit > and approches largely based on explicit marking. > > Approaches based on marking face technical and non technical challenges > that have

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

To me there is substantial difference from something like fq_codel or fq_pie where service differentiation is largely implicit and approches largely based on explicit marking. Approaches based on marking face technical and non technical challenges that have been largely mentioned in these lists.

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Vint - BBR is the end-to-end control logic that adjusts the source rate to match the share of the bolttleneck link it should use. It depends on getting reliable current congestion information via packet drops and/or ECN. So the proposal by these guys (not the cable guys) is an attempt to

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

I helped land a more rfc - compliant version of pie into net-next late last year. ironically, we had one open bug re ecn - https://github.com/gautamramk/FQ-PIE-for-Linux-Kernel/issues/2 - docsis pie supported ecn not at all. I actually hold a good opinion of pie - it is a good single queue aqm,

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Sun, 17 Mar 2019, Loganaden Velvindron wrote: is there an open source implementation of PIE which is close to what is used by the DOCSIS modems ? PIE was added to the Linux kernel in 3.14 according to https://www.linux.com/news/linux-314-release-no-pi-new-pie-fights-bufferbloat --

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On 17 March 2019 18:37:27 CET, Loganaden Velvindron wrote: >On Sun, Mar 17, 2019 at 6:06 PM Mikael Abrahamsson >wrote: >> >> On Sat, 16 Mar 2019, Holland, Jake wrote: >> >> > Granted, it still remains to be seen whether SCE in practice can >match >> > the results of L4S, and L4S was here

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Sat, 16 Mar 2019, Holland, Jake wrote: Granted, it still remains to be seen whether SCE in practice can match the results of L4S, and L4S was here first. But it seems to me L4S comes with some problems that have not yet been examined, and that are nicely dodged by a SCE-based approach.

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On Mar 16, 2019, at 22:38, Holland, Jake wrote: > > On 2019-03-15, 11:37, "Mikael Abrahamsson" wrote: >L4S has a much better possibility of actually getting deployment into the >wider Internet packet-moving equipment than anything being talked about >here. Same with PIE as

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Yeah, great question. I don't want to answer for the L4S guys, I don't have a good feel for what they might think. But it does concern me that there seems to be at least one tuning parameter that was picked for Reno, which I think I mentioned on the tsvwg list:

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On 16 Mar, 2019, at 11:38 pm, Holland, Jake wrote: > > SCE needs a lot of details filled in, but it's so much cleaner that it > seems to me there's reasonably obvious answers to all (or almost all) of > those detail questions, and because the semantics are so much cleaner, > it's much easier

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Dear Vint: BBR, along with all "non ect_1 sending L4S compatable" transports, gets relegated to the dualpi "Classic" queue. https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/ On Sat, Mar 16, 2019 at 2:57 PM Vint Cerf wrote: > > where does BBR fit into all this? > > v > > >

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On 2019-03-15, 11:37, "Mikael Abrahamsson" wrote: L4S has a much better possibility of actually getting deployment into the wider Internet packet-moving equipment than anything being talked about here. Same with PIE as opposed to FQ_CODEL. I know it's might not be as good, but

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

The DSCP code points were also supposed to be local to the AS. They are *supposed* to be recoded at the edges. What is missing the diffedge protocol... MS actually implemented this in Win2K. We have no way to signal the ToS we desire with the ISP, and so they are forced to guess, and they do it

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Thanks Nils, I’d seen that PolicyPlus tool before, and while a nice stand-alone option for any Windows version, it is still a tool for admins. I think we need something regular technical users can use to do things like ‘Make DropBox traffic land in the bulk tin’. Also, there is a good thread

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

You can use group policies on standalone clients, however the Local Group Policy Editor is not available on the Windows Home editions (neither is domain membership AFAIK), and so many people resort to applying the changes they require directly to the registry. There are also tools like Policy

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On Mar 16, 2019, at 10:42, Michael Welzl wrote: > > Good question! …. on Windows in particular, I’d really like to know this too. Well, as far as I can tell it is the group policy editor that is the tool to assign DSCPs to applications, IMHO that is exactly the right place,

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Good question! …. on Windows in particular, I’d really like to know this too. The WebRTC Javascript API allows one to influence the DSCP, i.e. browsers normally can do that. Whether that’s true for all OSes, I don’t know. Cheers, Michael > On Mar 16, 2019, at 12:45 AM, David P. Reed wrote:

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi Dave, On March 16, 2019 12:43:58 AM GMT+01:00, "David P. Reed" wrote: > >My point is that the argument for doing such balancing is that somehow >ISPs at the entry points (representing somehow the goals of source and >destination of each flow) will classify their flows correctly based on

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Fri, Mar 15, 2019 at 9:04 PM Jonathan Morton wrote: > > > On 15 Mar, 2019, at 7:01 pm, David P. Reed wrote: > > > > > 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. > > Actually, today I was still

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On 15 Mar, 2019, at 7:01 pm, David P. Reed wrote: > > > 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. Actually, today I was still figuring out how to fit it to CUBIC. I *think* I've succeeded…

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On 16 Mar, 2019, at 1:43 am, David P. Reed wrote: > > Now the other thing that is crucial is that the optimal state almost all of > the time of every link in the network is that a utilization far from max > capacity. The reason for this is the fact that the Internet (like almost all >

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

How many applications used by normal users have "admin" privileges? The Browser? Email? FTP? -Original Message- From: "Dave Taht" Sent: Friday, March 15, 2019 4:31pm To: "Jonathan Foulkes" Cc: ecn-s...@lists.bufferbloat.net, "bloat" Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd:

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

My point is that the argument for doing such balancing is that somehow ISPs at the entry points (representing somehow the goals of source and destination of each flow) will classify their flows correctly based on some criterion, and not select the option that allows them to "beat" all the

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Fri, Mar 15, 2019 at 1:28 PM Jonathan Foulkes wrote: > > All this discussion of DSCP marking brings to mind what happened on the > Windows platform, where the OS had to suppress ALL DSCP marks, as app authors > were trying to game the system. > And even if not trying to ‘game’ it, they have

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

All this discussion of DSCP marking brings to mind what happened on the Windows platform, where the OS had to suppress ALL DSCP marks, as app authors were trying to game the system. And even if not trying to ‘game’ it, they have non-obvious reasons why they don’t mark traffic how one would

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On 15 Mar, 2019, at 9:44 pm, David P. Reed wrote: > > pricing (even dynamic pricing) of different qualities of service is unstable An interesting result, but I should note that the four-way optimisation system I described doesn't rely on pricing, only a sufficiently correct implementation

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Just to throw in one more thing not well understood by engineers. Economists I have discussed this with (real ones, not fringe right-wing true believers that the market "just works"), have observed that pricing (even dynamic pricing) of different qualities of service is unstable and extremely

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

> On 15 Mar, 2019, at 8:36 pm, Mikael Abrahamsson wrote: > > Having a "lower-than-best-effort" diffserve codepoint might work, because it > means worse treatment, not preferential treatment. > > The problem with having DSCP CPs that indicate preferential treatment is > typically a ddos

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Hi Mikael, > On Mar 15, 2019, at 19:36, Mikael Abrahamsson wrote: > > On Fri, 15 Mar 2019, David P. Reed wrote: > >> So if the responsible network engineers in the carriers cannot agree on >> anything, IETF is wasting its time. > > The IETF has already said that anything diffserv is

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Fri, 15 Mar 2019, David P. Reed wrote: So if the responsible network engineers in the carriers cannot agree on anything, IETF is wasting its time. The IETF has already said that anything diffserv is domain-internal only. I have joined the effort of the LE PHB and see if we can get some

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Fri, 15 Mar 2019, Dave Taht wrote: 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

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On March 15, 2019 6:01:23 PM GMT+01:00, "David P. 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:

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

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