<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
font-variant:normal !important;
color:windowtext;
text-transform:none;
text-decoration:none none;
vertical-align:baseline;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Yeah, great question.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I don't want to answer for the L4S guys, I don't have a good feel for<o:p></o:p></p>
<p class="MsoNormal">what they might think. But it does concern me that there seems to be at<o:p></o:p></p>
<p class="MsoNormal">least one tuning parameter that was picked for Reno, which I think I<o:p></o:p></p>
<p class="MsoNormal">mentioned on the tsvwg list:<o:p></o:p></p>
<p class="MsoNormal">https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08#section-2.1<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">For SCE, I would assume they'll want to make use of it at some point,<o:p></o:p></p>
<p class="MsoNormal">and so they'll have to write a draft for how BBR will handle it.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think there's an open question of what exactly the rate of SCE<o:p></o:p></p>
<p class="MsoNormal">markings would look like for a SCE-capable AQM, and presumably this also<o:p></o:p></p>
<p class="MsoNormal">needs to be nailed down before it can be useful. My initial instinct is<o:p></o:p></p>
<p class="MsoNormal">a probabilistic SCE setting based on current queue length, either when<o:p></o:p></p>
<p class="MsoNormal">forwarded or when enqueued, but I think this will take some more<o:p></o:p></p>
<p class="MsoNormal">thought, and I'm not sure that's best.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">But whatever the most informative schedule we can figure out is, if that<o:p></o:p></p>
<p class="MsoNormal">info can get back to sender, it can essentially do whatever it thinks is<o:p></o:p></p>
<p class="MsoNormal">right, according to the cc it’s running, is my understanding.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Jake<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Vint Cerf <vint@google.com><br>
<b>Date: </b>2019-03-16 at 14:57<br>
<b>To: </b>"Holland, Jake" <jholland@akamai.com><br>
<b>Cc: </b>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>
<b>Subject: </b>Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">where does BBR fit into all this? <o:p>
</o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">v<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake <<a href="mailto:jholland@akamai.com">jholland@akamai.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-left:.5in">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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.bufferbloat.net_listinfo_ecn-2Dsane&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=Z6SbAUystZUjAZ76eHgzuX1g5MhoKi4Ich8EPHag2YY&s=wSu1I5Whay2ozL9k8eMyqhqN-SQVdMnbPzCRx6tyEZ8&e=" target="_blank">https://lists.bufferbloat.net/listinfo/ecn-sane</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:.5in"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in">-- <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">New postal address: <o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">Google<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">1875 Explorer Street, 10th Floor<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Reston, VA 20190<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>