<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 6, 2019 at 10:38 AM Sebastian Moeller <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</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">Hii Neal,<br>
<br>
<br>
On April 6, 2019 1:56:06 PM GMT+02:00, Neal Cardwell <<a href="mailto:ncardwell@google.com" target="_blank">ncardwell@google.com</a>> wrote:<br>
>On Fri, Apr 5, 2019 at 12:20 PM Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>><br>
>wrote:<br>
><br>
>> > On 5 Apr, 2019, at 6:10 pm, 'Neal Cardwell' via BBR Development <<br>
>> <a href="mailto:bbr-dev@googlegroups.com" target="_blank">bbr-dev@googlegroups.com</a>> wrote:<br>
>> ><br>
>> > Right. I didn't mean setting the codel target to 242us. Where the<br>
>slide<br>
>> says "Linux codel with ECN ce_threshold at 242us sojourn time" I<br>
>literally<br>
>> mean a Linux machine with a codel qdisc configured as:<br>
>> ><br>
>> > codel ce_threshold 242us<br>
>><br>
>> I infer from this that BBR's new ECN support won't work properly with<br>
>> standard CE marking behaviour, only with the sort of signal that<br>
>DCTCP<br>
>> requires. Is that accurate?<br>
>><br>
><br>
>Yes, that's correct. Thus far BBR v2 is targeting only DCTCP/L4S-style<br>
>ECN.<br>
<br>
Out of curiosity, given that BBR intentionally interprets lost packets as a lossy path instead of a signal send by an AQM to slow down, why do think that dctcp style ECN is a good fit? In classic ECN the CE mark is exactly the signal BBR should get to have a higher confidence that ignoring lost packets is acceptable, in dctcp it will take a while to convey the same signal, no? I wonder if one is willing to change ECN semantics already, by making CELighter weight than a packetdrop, why not also using an explicit signal for emergency brake? I can't help but notice that both dctcp and tcpprague face the same problem, but at least they seem to be willing to take a Paket drop at face value...<br></blockquote><div><br></div><div>I think the L4S team has done a nice job of outlining the problems with RFC-3168-style ECN, so I will just quote their explanation:</div><div><br></div><div><a href="https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-01#section-5.1">https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-01#section-5.1</a><br></div><div><br></div><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><span class="gmail-h2" style="line-height:0pt;display:inline;font-size:1em;font-weight:bold"><h2 style="line-height:0pt;display:inline;font-size:1em"><a class="gmail-selflink" name="section-5" href="https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-01#section-5" style="color:black;text-decoration-line:none">5</a>. Rationale</h2></span>
<span class="gmail-h3" style="line-height:0pt;display:inline;font-size:1em;font-weight:bold"><h3 style="line-height:0pt;display:inline;font-size:1em"><a class="gmail-selflink" name="section-5.1" href="https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-01#section-5.1" style="color:black;text-decoration-line:none">5.1</a>. Why These Primary Components?</h3></span>
Explicit congestion signalling (protocol): Explicit congestion
signalling is a key part of the L4S approach. In contrast, use of
drop as a congestion signal creates a tension because drop is both
a useful signal (more would reduce delay) and an impairment (less
would reduce delay). Explicit congestion signals can be used many
times per round trip, to keep tight control, without any
impairment. Under heavy load, even more explicit signals can be
applied so the queue can be kept short whatever the load. Whereas
state-of-the-art AQMs have to introduce very high packet drop at
high load to keep the queue short. Further, TCP's sawtooth
reduction can be smaller, and therefore return to the operating
point more often, without worrying that this causes more signals
(one at the top of each smaller sawtooth). The consequent smaller
amplitude sawteeth fit between a very shallow marking threshold
and an empty queue, so delay variation can be very low, without
risk of under-utilization.
All the above makes it clear that explicit congestion signalling
is only advantageous for latency if it does not have to be
considered 'the same as' drop (as required with Classic ECN </pre><div><span style="color:rgb(0,0,0);font-size:13.3333px"> <font face="monospace, monospace"> [</font></span><font face="monospace, monospace"><a href="https://tools.ietf.org/html/rfc3168" title=""The Addition of Explicit Congestion Notification (ECN) to IP"" style="font-size:13.3333px">RFC3168</a><span style="color:rgb(0,0,0);font-size:13.3333px">]).</span> ...</font></div><div><br></div><div>best,</div><div>neal</div><div><br></div></div></div>