<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><blockquote type="cite" class="">On 8 Jul, 2019, at 11:55 pm, Holland, Jake <<a href="mailto:jholland@akamai.com" class="">jholland@akamai.com</a>> wrote:<br class=""><br class="">Also, I think if the SCE position is "low latency can only be<br class="">achieved with FQ", that's different from "forcing only FQ on the<br class="">internet", provided the fairness claims hold up, right? (Classic<br class="">single queue AQMs may still have a useful place in getting<br class="">pretty-good latency in the cheapest hardware, like maybe PIE with<br class="">marking.)<br class=""></blockquote><br class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><img apple-inline="yes" id="CB555BF1-3F69-490A-8DEA-F7362169B8FF" src="cid:134960E5-8D27-440D-A59D-0E4A47CC7173@lan" class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><img apple-inline="yes" id="324E6052-D634-4874-9B10-339B9CCB38DE" src="cid:3101A5EF-C21B-4594-B31A-99036D2C072C@lan" class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><img apple-inline="yes" id="1AFE2142-20D0-4F69-901B-99511CB38A8A" src="cid:811B80B7-A93E-4616-8F3E-11E7BE63DDC0@lan" class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><img apple-inline="yes" id="9C7E8ED3-2B60-4EE2-ACF1-2CC11F8AD605" src="cid:49345B23-A8EA-422C-B8DC-B3FC2730009E@lan" class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><img apple-inline="yes" id="6687FAAE-347C-4FDE-BCD0-9C6B36F45885" src="cid:33F752F8-EB61-4280-8299-C96971443115@lan" class=""></div><div class=""><br class=""></div><div class="">And with the straddling ramp:</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="03F005D1-B35A-4AA6-B55C-FA517959BB71" src="cid:72690B90-BD96-414D-B912-DFE12D4279BE@lan" class=""></div><div class=""><br class=""></div><div class="">And with the SCE ramp entirely above the threshold:</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="DE3A892E-D35A-4C20-807D-EFCB53A07766" src="cid:816C0074-CF4D-4580-9FB7-9326C3026B70@lan" class=""></div><div class=""><br class=""></div><div class="">And, finally, the *real* ideal situation - SCE vs SCE with FQ:</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="2C0B8703-0186-4EF9-BC55-DAAB704BB3A9" src="cid:741F7839-B599-4F48-B784-F3A53BF40EDD@lan" class=""></div><div class=""><br class=""></div><div class="">I hope this reassures various people that we do, in fact, know what we're doing over here.</div><div class=""><br class=""></div><div class=""> - Jonathan Morton</div><div class=""><br class=""></div></body></html>