Indeed - I believe that Codel will drop too much to allow maximum
bandwidth utilization, when there are very few flows, and RTT is
significantly greater than target. The theory is - with a Reno based CC
the cwind gets cut in half on a drop. If the drop in cwind is greater
than the number of packets in the queue, then the queue will empty out,
and the link will then be idle for a while. If you want data to keep the
data flowing uninterrupted, then you must have a full unloaded RTT's
worth of data in the queue at that point. A drop will happen, the cwind
will be halved (assuming a Reno TCP), and the sender will stop sending
until one (unloaded) RTT's worth of data has been received. At that
point the queue will just hit empty as the sender starts sending again.
Simon
On 6/9/2015 10:30 AM, Jonathan Morton wrote:
Wouldn't that be a sign of dropping too much, in contrast to your
previous post suggesting it wouldn't drop enough?
In practice, statistical multiplexing works just fine with fq_codel,
and you do in fact get more throughput with multiple flows in those
cases where a single flow fails to each adequate utilisation.
Additionally, utilisation below 100% is really characteristic of Reno
on any worthwhile AQM queue and significant RTT. Other TCPs,
particularly CUBIC and Westwood+, do rather better.
- Jonathan Morton
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
