[Bloat] when does the CoDel part of fq_codel help in the real world?

[Jonathan Morton]

> On 27 Nov, 2018, at 1:21 pm, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> 
> It's complicated. I've had people throw in my face that I need 2xBDP in buffer size to smoothe things out. Personally I don't want more than 10ms buffer (max), and I don't see why I should need more than that even if transfers are running over hundreds of ms of light-speed-in-medium induced delay between the communicating systems.

I think we can agree that the ideal CC algo would pace packets out smoothly at exactly the path capacity, neither building a queue at the bottleneck nor leaving capacity on the table.

Actually achieving that in practice turns out to be difficult, because there's no general way to discover the path capacity in advance.  AQMs like Codel, in combination with ECN, get us a step closer by explicitly informing each flow when it is exceeding that capacity while the queue is still reasonably short.  FQ also helps, by preventing flows from inadvertently interfering with each other by imperfectly managing their congestion windows.

So with the presently deployed state of the art, we have cwnds oscillating around reasonably short queue lengths, backing off sharply in response to occasional signals, then probing back upwards when that signal goes away for a while.  It's a big improvement over dumb drop-tail FIFOs, but it's still some distance from the ideal.  That's because the information injected by the bottleneck AQM is a crude binary state.

I do not include DCTCP in the deployed state of the art, because it is not deployable in the RFC-compliant Internet; it is effectively incompatible with Codel in particular, because it wrongly interprets CE marks and is thus noncompliant with the ECN RFC.

However, I agree with DCTCP's goal of achieving finer-grained control of the cwnd, through AQMs providing more nuanced information about the state of the path capacity and/or bottleneck queue.  An implementation that made use of ECT(1) instead of changing the meaning of CE marks would remain RFC-compliant, and could get "sufficiently close" to the ideal described above.

 - Jonathan Morton