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
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
