<div dir="ltr">where does BBR fit into all this?<div><br></div><div>v</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake <<a href="mailto:jholland@akamai.com">jholland@akamai.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">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 href="https://lists.bufferbloat.net/listinfo/ecn-sane" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/ecn-sane</a><br>
</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>