Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

[Jonathan Morton <[e-mail]>]

> On 11 Aug, 2019, at 5:03 am, Wesley Eddy <[e-mail]> wrote:
> 
> I created tickets in the TSVWG "trac" tool in order to help keep track of the individual things that look like they should be addressed in progressing L4S document set:
> 
> https://trac.ietf.org/trac/tsvwg/report/1?sort=ticket&asc=1&page=1
> 
> I'll try to update these based on the ongoing discussions, updates, etc., but it will make it very easy if you happen to mention the ticket numbers or some key words in threads and messages, when significant.

Thanks for that; most of the issues seem to be well described and understood.  But there is one exception in the form of #17.

The issue I was trying to raise is not that L4S has any particular difficulty with FQ, that it would not have with an equivalent non-FQ qdisc.  Rather I was responding to the proposed point on the slide *about* FQ, and identifying a situation where FQ could be defeated by L4S' poor behaviour in an RFC-3168 environment.

Since this is a relatively subtle point, I'll try to expand upon it here to avoid confusion.  Fundamentally though, this is strongly related to points A, F & G, which is why I raised the four together.

First, let's define a non-issue.  If the first significant bottleneck that an L4S flow encounters is the true one, and that bottleneck is equipped with FQ, then the worst effect that L4S can have on the network is self-inflicted.  The ability of FQ to isolate badly-behaved flows from other traffic traversing the same link is well-known, and there is nothing special about L4S that would defeat that property, on its own.  This is what I meant when I described FQ as being "pretty robust".

Where the problems arise is where the true bottleneck, supporting FQ-AQM, is preceded by a dumb FIFO (or, without very much loss of generality, a single-queue RFC-3168 AQM).  This is what I might refer to as "Sebastian's topology", and reflects the current practice of placing bufferbloat mitigation in the CPE downstream of the last-mile link.  Even with current RFC-compliant traffic, managing overall latency in this topology is challenging; in practice it requires a reservation of some percentage of the last-mile link capacity to ensure the latter's dumb queue drains into the CPE's smarter queue.

For example, the IQrouter automatically measures the last-mile link capacity, using speed tests, and sets its own FQ-AQM shaper to about 95% of that measurement.  But this still means that if a sudden flood of traffic arrives, only a twentieth part of that traffic will immediately collect in the IQrouter's queue, as opposed to the dumb queue at the last-mile link.  The effectiveness of the FQ-AQM thus depends on avoiding large floods of that sort, by quickly and effectively signalling congestion to external senders; only when the dumb FIFO is kept empty do the flow isolation properties of FQ take effect.

So you can see from this why the 4-second ramp up needed for Codel to effectively control an L4S flow with a relatively short RTT is problematic.  Indeed, as the RTT gets shorter, the time needed to gain control using a Codel ramp gets longer, because the signalling frequency needs to be proportionately higher.  Luckily, there is a practical lower limit to this trend in the form of the Codel 'target' parameter, which sets a floor on the effective RTT that needs to be controlled.

Conversely, an RFC-3168 compliant flow responds to a single CE mark after 1 RTT with a Multiplicative Decrease, so its response actually gets *faster* with shorter RTTs.  This is a property that Codel relies on to make its performance less sensitive to the precise choice of 'interval' parameter relative to path RTT.

I can walk you through the maths for the Codel response if you like.  It's reasonably straightforward, but might not be obvious from a cursory reading of the raw RFC.

 - Jonathan Morton