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

["De Schepper, Koen (Koen)" <[e-mail]>]

Hi David,

There seem to be some misunderstandings:

> (and marking independently of dropping does raise all the fairness
> issues that we discussed a week or so ago)
What I proposed is to add the benefits of marking differently than dropping in the AQM, more specific to apply for dropping p^2 and for marking just p. This will run fair, as Reno (and others fair to Reno) have a steady state rate that is proportional to 1/p^0.5 and many improved congestion controllers all advocate to have a rate proportional to 1/p. So marking ECN different (with squared p) than dropping allows to deploy the better 1/p schemes for marking. They can still be drop compatible (behave as reno/cubic on experiencing drop).

So the advantages I described were in the context of doing the better marking and better congestion control for marking: 

>> - 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
I was not comparing ECN with non-ECN, but ECN+Reno and for example ECN+DCTCP.
You can have a much more frequent marking probability than dropping probability, so we should use that.
DCTCP which has a rate = 2/(p.rtt) when controlled with an AQM that calculates a p. It can have full utility with a very small buffer, as it reduces its window only with a very small amount when receiving a mark (it needs around 2 marks per RTT at steady state). If a window is halved as with reno, you need a buffer of 1 BDP, if a window is set to 70% as with cubic you still need a buffer of 43% of BDP.

>> - reduced variability in flow fairness between competing flows
>> because of the high marking rate
> This is plausable, but how unfair do things get in practice?
> Especially if you have a large number of flows so that you are
> statistically unlikely to keep picking on the same flow.
If marking is more frequent, it is indeed statistically unlikely to keep picking on the same flow even with 2 flows (no need for many flows).

>> - scalability to higher throughputs because the marking rate is 
>> independent from the throughput
> The drop rate is also independent of the throughput, so I don't
> see how this works unless you are doing statistical dropping.
In case of reno, for a specific RTT, the drop rate (rate*p) will be 1.22*p^0.5/RTT (drops become very seldom), while for DCTCP it is 2/RTT (marks always twice per RTT, independent from p).

>> Disadvantage is that congestion controllers that are optimized for 
>> drop signals cannot use ECN without experiencing high throughput
>> unfairness.
> This is being disputed heavily by others here who are saying that
> adding ECN cannot possibly cause unfairness (in either direction)
I meant that if we mark more often than dropping, flows that use ECN and are not adapted to behave different to marking will reduce their window too much which results in reduced throughput.

Hope this clarifies.

Regards,
Koen.


-----Original Message-----
From: David Lang [mailto:[e-mail]] 
Sent: vrijdag 27 maart 2015 20:09
To: Scheffenegger, Richard
Cc: De Schepper, Koen (Koen); [e-mail]; Michael Welzl; [e-mail]
Subject: RE: [aqm] think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02

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