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 current congestion information via packet > drops and/or ECN. > > > > So the proposal by these guys (not the cable guys) is an attempt to > improve the quality of the congestion signal inserted by the router with > the bottleneck outbound link. > > > > THe cable guys are trying to get a "private" field in the IP header for > their own use. > > > > > > -----Original Message----- > From: "Vint Cerf" > Sent: Saturday, March 16, 2019 5:57pm > To: "Holland, Jake" > Cc: "Mikael Abrahamsson" , "David P. Reed" < > dpreed@deepplum.com>, "ecn-sane@lists.bufferbloat.net" < > ecn-sane@lists.bufferbloat.net>, "bloat" > Subject: Re: [Ecn-sane] [Bloat] [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 talked >> about >> here. Same with PIE as opposed to FQ_CODEL. I know it's might not be >> as >> good, but it fits better into actual silicon and it's being proposed >> by >> people who actually have better channels into the people setting hard >> requirements. >> >> I suggest you consider joining them instead of opposing them. >> >> >> Hi Mikael, >> >> I agree it makes sense that fq_anything has issues when you're talking >> about the OLT/CMTS/BNG/etc., and I believe it when you tell me PIE >> makes better sense there. >> >> But fq_x makes great sense and provides real value for the uplink in a >> home, small office, coffee shop, etc. (if you run the final rate limit >> on the home side of the access link.) I'm thinking maybe there's a >> disconnect here driven by the different use cases for where AQMs can go. >> >> The thing is, each of these is the most likely congestion point at >> different times, and it's worthwhile for each of them to be able to >> AQM (and mark packets) under congestion. >> >> One of the several things that bothers me with L4S is that I've seen >> precious little concern over interfering with the ability for another >> different AQM in-path to mark packets, and because it changes the >> semantics of CE, you can't have both working at the same time unless >> they both do L4S. >> >> 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 to tell it's non-harmful. >> >> >> >> But as you also said so well in another thread, this is important. ("The >> last unicorn", IIRC.) How much does it matter if there's a feature that >> has value today, but only until RACK is widely deployed? If you were >> convinced RACK would roll out everywhere within 3 years and SCE would >> produce better results than L4S over the following 15 years, would that >> change your mind? >> >> It would for me, and that's why I'd like to see SCE explored before >> making a call. I think at its core, it provides the same thing L4S does >> (a high-fidelity explicit congestion signal for the sender), but with >> much cleaner semantics that can be incrementally added to congestion >> controls that people are already using. >> >> 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. >> >> If L4S really is as good as they seem to think, I could imagine getting >> behind it, but I don't think that's proven yet. I'm not certain, but >> all the comparative analyses I remember seeing have been from more or >> less the same team, and I'm not convinced they don't have some >> misaligned incentives of their own. >> >> I understand a lot of work has gone into L4S, but this move to jump it >> from interesting experiment to de-facto standard without a more critical >> review that digs deeper into some of the potential deployment problems >> has me concerned. >> >> If it really does turn out to be good enough to be permanent, I'm not >> opposed to it, but I'm just not convinced that it's non-harmful, and my >> default position is that the cleaner solution is going to be better in >> the long run, if they can do the same job. >> >> It's not that I want it to be a fight, but I do want to end up with the >> best solution we can get. We only have the one internet. >> >> Just my 2c. >> >> -Jake >> >> >> _______________________________________________ >> Ecn-sane mailing list >> Ecn-sane@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/ecn-sane > > > -- > New postal address: > Google > 1875 Explorer Street, 10th Floor > Reston, VA 20190 > -- New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190