<div dir="ltr"><div dir="ltr">On Fri, Apr 5, 2019 at 12:20 PM Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On 5 Apr, 2019, at 6:10 pm, 'Neal Cardwell' via BBR Development <<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 slide says "Linux codel with ECN ce_threshold at 242us sojourn time" I literally 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 standard CE marking behaviour, only with the sort of signal that DCTCP requires.  Is that accurate?<br></blockquote><div><br></div><div>Yes, that's correct. Thus far BBR v2 is targeting only DCTCP/L4S-style ECN.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
SCE allows providing that sort of high-fidelity congestion signal without losing interoperability with RFC-3168 compliant flows.<br></blockquote><div><br></div><div>Noted, thanks.</div><div><br></div><div>neal</div><div><br></div></div></div>