<div dir="ltr">thanks, David - that's the information I was looking for.<div><br></div><div>v</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 17, 2019 at 2:07 PM David P. Reed <<a href="mailto:dpreed@deepplum.com">dpreed@deepplum.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="arial" size="3"><p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">Vint -</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">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:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">It depends on getting reliable current congestion information via packet drops and/or ECN.</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">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:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">THe cable guys are trying to get a "private" field in the IP header for their own use.</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">-----Original Message-----<br>From: "Vint Cerf" <<a href="mailto:vint@google.com" target="_blank">vint@google.com</a>><br>Sent: Saturday, March 16, 2019 5:57pm<br>To: "Holland, Jake" <<a href="mailto:jholland@akamai.com" target="_blank">jholland@akamai.com</a>><br>Cc: "Mikael Abrahamsson" <<a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a>>, "David P. Reed" <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>>, "<a href="mailto:ecn-sane@lists.bufferbloat.net" target="_blank">ecn-sane@lists.bufferbloat.net</a>" <<a href="mailto:ecn-sane@lists.bufferbloat.net" target="_blank">ecn-sane@lists.bufferbloat.net</a>>, "bloat" <<a href="mailto:bloat@lists.bufferbloat.net" target="_blank">bloat@lists.bufferbloat.net</a>><br>Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104<br><br></p>
<div id="gmail-m_-1685192762944396139SafeStyles1552845686">
<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" target="_blank">jholland@akamai.com</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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-m_-1685192762944396139gmail_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></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">New postal address:<div>Google<br><div>1875 Explorer Street, 10th Floor</div><div>Reston, VA 20190</div></div></div></div>