On Sun, Jun 14, 2015 at 4:10 PM, Simon Barber <[email protected]> wrote: > 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.
Interval. Not target. Interval defaults to 100ms. Target is 5ms. Dropping behaviors stop when the queue falls below the target. Range of tests from near zero to 300ms RTT codel does quite well with reno, better with cubic, on single flows. 4 flows, better. fq_codel does better than that on more than X flows in general. You can easily do whatever experiments you like with off the shelf hardware and RTTs around half the planet to get the observations you need to confirm your thinking. Remember that a drop tail queue of various sizes has problems of it's own. I have a long overdue rant in progress of being wikified about how to use netem correctly to properly emulate any rtt you like. I note that a main aqm goal is not maximum bandwidth utilization, but maximum bandwidth while still having working congestion avoidance and minimal queue depth so other new flows can rapidly grab their fair share of the link. The bufferbloat problem was the result of wanting maximum bandwidth for single flows. > 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 flight + queue. > 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 Do the experiment? Recently landed in flent is the ability to monitor queue depth while running another test. > 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. And reno is dead. Long live reno! > 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 -- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
