<font face="arial" size="3"><p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Vint -</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">BBR is the end-to-end control logic that adjusts the source rate to match the share of the bolttleneck link it should use.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">It depends on getting reliable current congestion information via packet drops and/or ECN.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">THe cable guys are trying to get a "private" field in the IP header for their own use.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">-----Original Message-----<br />From: "Vint Cerf" <vint@google.com><br />Sent: Saturday, March 16, 2019 5:57pm<br />To: "Holland, Jake" <jholland@akamai.com><br />Cc: "Mikael Abrahamsson" <swmike@swm.pp.se>, "David P. Reed" <dpreed@deepplum.com>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, "bloat" <bloat@lists.bufferbloat.net><br />Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104<br /><br /></p>
<div id="SafeStyles1552845686">
<div dir="ltr">where does BBR fit into all this?
<div>v</div>
</div>
<br />
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake <<a href="mailto:jholland@akamai.com">jholland@akamai.com</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;">On 2019-03-15, 11:37, "Mikael Abrahamsson" <<a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a>> wrote:<br /> L4S has a much better possibility of actually getting deployment into the <br /> wider Internet packet-moving equipment than anything being talked about <br /> here. Same with PIE as opposed to FQ_CODEL. I know it's might not be as <br /> good, but it fits better into actual silicon and it's being proposed by <br /> people who actually have better channels into the people setting hard <br /> requirements.<br /><br /> I suggest you consider joining them instead of opposing them.<br /><br /><br /> Hi Mikael,<br /><br /> I agree it makes sense that fq_anything has issues when you're talking<br /> about the OLT/CMTS/BNG/etc., and I believe it when you tell me PIE<br /> makes better sense there.<br /><br /> But fq_x makes great sense and provides real value for the uplink in a<br /> home, small office, coffee shop, etc. (if you run the final rate limit<br /> on the home side of the access link.) I'm thinking maybe there's a<br /> disconnect here driven by the different use cases for where AQMs can go.<br /><br /> The thing is, each of these is the most likely congestion point at<br /> different times, and it's worthwhile for each of them to be able to<br /> AQM (and mark packets) under congestion.<br /><br /> One of the several things that bothers me with L4S is that I've seen<br /> precious little concern over interfering with the ability for another<br /> different AQM in-path to mark packets, and because it changes the<br /> semantics of CE, you can't have both working at the same time unless<br /> they both do L4S.<br /><br /> SCE needs a lot of details filled in, but it's so much cleaner that it<br /> seems to me there's reasonably obvious answers to all (or almost all) of<br /> those detail questions, and because the semantics are so much cleaner,<br /> it's much easier to tell it's non-harmful.<br /><br /> <aside regarding="non-harmful"><br /> The point you raised in another thread about reordering is mostly<br /> well-taken, and a good counterpoint to the claim "non-harmful relative<br /> to L4S".<br /><br /> To me it seems sad and dumb that switches ended up trying to make<br /> ordering guarantees at cost of switching performance, because if it's<br /> useful to put ordering in the switch, then it must be equally useful to<br /> put it in the receiver's NIC or OS.<br /><br /> So why isn't it in all the receivers' NIC or OS (where it would render<br /> the switch's ordering efforts moot) instead of in all the switches?<br /><br /> I'm guessing the answer is a competition trap for the switch vendors,<br /> plus "with ordering goes faster than without, when you benchmark the<br /> switch with typical load and current (non-RACK) receivers".<br /><br /> If that's the case, it seems like the drive for a competitive advantage<br /> caused deployment of a packet ordering workaround in the wrong network<br /> location(s), out of a pure misalignment of incentives.<br /><br /> RACK rates to fix that in the end, but a lot of damage is already done,<br /> and the L4S approach gives switches a flag that can double as proof that<br /> RACK is there on the receiver, so they can stop trying to order those<br /> packets.<br /><br /> So point granted, I understand and agree there's a cost to abandoning<br /> that advantage.<br /> </aside><br /><br /> But as you also said so well in another thread, this is important. ("The<br /> last unicorn", IIRC.) How much does it matter if there's a feature that<br /> has value today, but only until RACK is widely deployed? If you were<br /> convinced RACK would roll out everywhere within 3 years and SCE would<br /> produce better results than L4S over the following 15 years, would that<br /> change your mind?<br /><br /> It would for me, and that's why I'd like to see SCE explored before<br /> making a call. I think at its core, it provides the same thing L4S does<br /> (a high-fidelity explicit congestion signal for the sender), but with<br /> much cleaner semantics that can be incrementally added to congestion<br /> controls that people are already using.<br /><br /> Granted, it still remains to be seen whether SCE in practice can match<br /> the results of L4S, and L4S was here first. But it seems to me L4S comes<br /> with some problems that have not yet been examined, and that are nicely<br /> dodged by a SCE-based approach.<br /><br /> If L4S really is as good as they seem to think, I could imagine getting<br /> behind it, but I don't think that's proven yet. I'm not certain, but<br /> all the comparative analyses I remember seeing have been from more or<br /> less the same team, and I'm not convinced they don't have some<br /> misaligned incentives of their own.<br /><br /> I understand a lot of work has gone into L4S, but this move to jump it<br /> from interesting experiment to de-facto standard without a more critical<br /> review that digs deeper into some of the potential deployment problems<br /> has me concerned.<br /><br /> If it really does turn out to be good enough to be permanent, I'm not<br /> opposed to it, but I'm just not convinced that it's non-harmful, and my<br /> default position is that the cleaner solution is going to be better in<br /> the long run, if they can do the same job.<br /><br /> It's not that I want it to be a fight, but I do want to end up with the<br /> best solution we can get. We only have the one internet.<br /><br /> Just my 2c. <br /><br /> -Jake<br /><br /><br /> _______________________________________________<br /> Ecn-sane mailing list<br /><a href="mailto:Ecn-sane@lists.bufferbloat.net" target="_blank">Ecn-sane@lists.bufferbloat.net</a><br /><a rel="noreferrer" href="https://lists.bufferbloat.net/listinfo/ecn-sane" target="_blank">https://lists.bufferbloat.net/listinfo/ecn-sane</a></blockquote>
</div>
<br />-- <br />
<div class="gmail_signature" dir="ltr">
<div dir="ltr">New postal address:
<div>Google<br />
<div>1875 Explorer Street, 10th Floor</div>
<div>Reston, VA 20190</div>
</div>
</div>
</div>
</div></font>