Re: [aqm] think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02

[David Lang <[e-mail]>]

On Fri, 27 Mar 2015, Scheffenegger, Richard wrote:

> Hi David,
>
>
>>> - low latency AND high throughput (compared to low latency OR high
>>> throughput for drop based congestion controllers)
>>
>> I think that you are overstating things when you say that without ECN you
>> are forced to choose between low latency OR high throughput. that doesn't
>> match what people are reporting when they use simple fq_codel without ECN
>
>
> I disagree. At the least when you are using TCP, a drop will cause head-of-line blocking on the receiver, for at least 1 RTT; Agreed, there are ways to mitigate this (FEC-encoded transports).
>
> But the "OR" is exactly the correct description here: FEC has inheritent overhead thus reduced bandwidth, and loss-recovery suffers from head-of-line blocking, thus higher latency (to the application, where it actually matters).
>
> FQ-Codel runs with high bandwidth, but the drops induce latency in the end-hosts nevertheless...
> Thus FQ-Codel with ECN would still be more effective than without ECN.

The key thing is that we are talking about different scales here.

You are talking about a 1RTT latency that will happen if the congestion gets bad 
enough, while I'm looking at the effects of overbuffering that causes the 
effective utilization of links to be well below 50% in practice. In such a case, 
doing something like fq_codel without ECN will get you 90%+ of the theoretical 
best case and is such a massive improvement that the vast majority of the users 
are not going to notice any improvement from ECN marking instead of dropping.

But the discussions here have explicitly said that ECN marking happens at the 
same time that drops happen, so it's not a case of doing ECN instead of 
dropping. While ECN could be used that way, that's not what's being advocated 
(and marking independently of dropping does raise all the fairness issues that 
we discussed a week or so ago)

David Lang