<div dir="ltr">Another bit to this.<div>A router queue is supposed to serve packets no matter what is running at the controlled end-point, BBR, Cubic or else.</div><div>So, delay-based congestion controller still get hurt in today Internet unless they can get their portion of buffer at the line card.</div><div>FQ creates incentives for end-points to send traffic in a smoother way because the reward to the application is immediate and </div><div>measurable. But the end-point does not know in advance if FQ is there or not.</div><div><br></div><div>So going back to sizing the link buffer, the rule I mentioned applies. And it allows to get best completion times for a wider range of RTTs.</div><div>If you, Mikael don't want more than 10ms buffer, how do you achieve that? You change the behaviour of the source and hope flow isolation is available.</div><div>If you just cut the buffer down to 10ms and do nothing else, the only thing you get is a short queue and may throw away half of your link capacity.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018 at 1:17 PM Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On 27 Nov, 2018, at 1:21 pm, Mikael Abrahamsson <<a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a>> wrote:<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
 - Jonathan Morton<br>
<br>
</blockquote></div>