> On 27 Nov, 2018, at 1:21 pm, Mikael Abrahamsson <swm...@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

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Reply via email to