<div dir="ltr">I'd hoped to get to where we could test this over wifi this week, but I think too many kernel patches are required as yet ( <a href="https://github.com/chromi/sce/commits/sce">https://github.com/chromi/sce/commits/sce</a> ) , and most of the work is in the tcps and sch_cake. <div><br></div><div>That said basic ecn support is universally enabled in fq_codel, you can enable it in your tcp stack with a sysctl.</div><div><br></div><div>It's not all good news - I've generally found an excess of ecn flows tends to hurt routing protocols lacking ecn (as well as other forms of non-ecn traffic) - batman, not being IP based, is unfixable, babel needs a 1 line patch (and to evolve a notion of CC in the first place, and have a good rtt based metric) - it is generally my hope that we see more rtt based cc's like bbr evolve to replace reno and cubic, also, instead of tons of marks....</div><div><br></div><div>The last graph here is to die for, though.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Jonathan Morton</strong> <span dir="auto"><<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>></span><br>Date: Tue, Jul 9, 2019 at 5:10 PM<br>Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts<br>To: Holland, Jake <<a href="mailto:jholland@akamai.com">jholland@akamai.com</a>><br>Cc: <a href="mailto:ecn-sane@lists.bufferbloat.net">ecn-sane@lists.bufferbloat.net</a> <<a href="mailto:ecn-sane@lists.bufferbloat.net">ecn-sane@lists.bufferbloat.net</a>>, <a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a> <<a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>>, De Schepper, Koen (Nokia - BE/Antwerp) <<a href="mailto:koen.de_schepper@nokia-bell-labs.com">koen.de_schepper@nokia-bell-labs.com</a>><br></div><br><br><div style="word-wrap:break-word;line-break:after-white-space"><blockquote type="cite">On 8 Jul, 2019, at 11:55 pm, Holland, Jake <<a href="mailto:jholland@akamai.com" target="_blank">jholland@akamai.com</a>> wrote:<br><br>Also, I think if the SCE position is "low latency can only be<br>achieved with FQ", that's different from "forcing only FQ on the<br>internet", provided the fairness claims hold up, right? (Classic<br>single queue AQMs may still have a useful place in getting<br>pretty-good latency in the cheapest hardware, like maybe PIE with<br>marking.)<br></blockquote><br><div>In support of this viewpoint, here are some illustrative time-series graphs showing SCE behaviour in a variety of contexts. These are all simple two-flow tests plus a sparse latency probe flow, conducted using Flent, over a 50Mbps, 80ms RTT path under lab conditions.</div><div><br></div><div>First let's get the FQ case out of the way, with Reno-SCE competing against plain old Reno. Here you can see Reno's classic sawtooth, while FQ keeps the latency of sparse flows sharing the link low; the novelty is that Reno-SCE is successfully using almost all of the capacity left on the table by plain Reno's sawtooth. This is basically ideal behaviour, enabled by FQ.</div><div><br></div><div><img id="m_6783374023257361629CB555BF1-3F69-490A-8DEA-F7362169B8FF" src="cid:16bdb175cbb5b206ef61"></div><div><br></div><div>If we then disable FQ and run the same test, we find that Reno-SCE yields very politely to plain Reno, again using only leftover capacity. From earlier comments, I gather that a similar graph was seen by the L4S team at some point in their development. Here we can see some small delay spikes, just before AQM activates to cut the plain Reno flow down.</div><div><br></div><div><img id="m_6783374023257361629324E6052-D634-4874-9B10-339B9CCB38DE" src="cid:16bdb175cbc5b2e86772"></div><div><br></div><div>Conversely, if we begin the SCE marking ramp only when CE marking also begins, we get good fairness between the two flows, in the same manner as with a conventional AQM - because both flows are mostly receiving only conventional AQM signals. The delay spikes also reflect that fact, and a significant amount of capacity goes unused. I gather that this scenario was also approximately seen during L4S development.</div><div><br></div><div><img id="m_67833740232573616291AFE2142-20D0-4F69-901B-99511CB38A8A" src="cid:16bdb175cbc5b3c9df83"></div><div><br></div><div>Our solution - which required only a few days' thought and calculation to define - is to make the SCE ramp straddle the AQM activation threshold, for single-queue situations only. The precise extent of straddling is configurable to suit different network situations; here is the one that works best for this scenario. Fairness between the two flows remains good; mostly the CE marks are going to the plain Reno flow, while the SCE flow is using the remaining capacity fairly effectively. Notice however that the delay plateaus due to the weakened SCE signalling:</div><div><br></div><div><img id="m_67833740232573616299C7E8ED3-2B60-4EE2-ACF1-2CC11F8AD605" src="cid:16bdb175cbc5b4ab5794"></div><div><br></div><div>Compare this to single-queue SCE vs SCE performance in a single queue, using the basic SCE ramp which lies entirely below the AQM threshold:</div><div><br></div><div><img id="m_67833740232573616296687FAAE-347C-4FDE-BCD0-9C6B36F45885" src="cid:16bdb175cbd5b58ccfa5"></div><div><br></div><div>And with the straddling ramp:</div><div><br></div><div><img id="m_678337402325736162903F005D1-B35A-4AA6-B55C-FA517959BB71" src="cid:16bdb175cbd5b66e47b6"></div><div><br></div><div>And with the SCE ramp entirely above the threshold:</div><div><br></div><div><img id="m_6783374023257361629DE3A892E-D35A-4C20-807D-EFCB53A07766" src="cid:16bdb175cbd5b74fbfc7"></div><div><br></div><div>And, finally, the *real* ideal situation - SCE vs SCE with FQ:</div><div><br></div><div><img id="m_67833740232573616292C0B8703-0186-4EF9-BC55-DAAB704BB3A9" src="cid:16bdb175cbd5b83137d8"></div><div><br></div><div>I hope this reassures various people that we do, in fact, know what we're doing over here.</div><div><br></div><div> - Jonathan Morton</div><div><br></div></div>_______________________________________________<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>
</div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>Dave Täht<br>CTO, TekLibre, LLC<br><a href="http://www.teklibre.com" target="_blank">http://www.teklibre.com</a><br>Tel: 1-831-205-9740</div></div></div>