So far in my observations (admittedly a very small sample size) it's more of an annoyance than a problem. We get an unwanted congestion event and lose a little bandwidth, but, after that the queue is drained and can begin building up again.
But yeah, I see your concern. There may be scenarios where the interaction of the interval, the RTT and the bandwidth cause this to happen recurringly constantly underflowing the bandwidth. ...Daniel -------------------------------------------- On Tue, 6/24/14, Fred Baker (fred) <[email protected]> wrote: Subject: Re: [aqm] New Version Notification for draft-baker-aqm-sfq-implementation-00.txt To: "[email protected]" <[email protected]> Cc: "RichardScheffenegger" <[email protected]>, "[email protected]" <[email protected]>, "grenville armitage" <[email protected]> Date: Tuesday, June 24, 2014, 1:01 PM On Jun 24, 2014, at 12:45 PM, Daniel Havey <[email protected]> wrote: > So IMHO it really doesn't matter except in the weird corner case where a a running flow has already bloated the queue and then we switch on the AQM. That actually has me a little worried with the 100 ms delay built into codel. Imagine, if you will, that you have a deep buffer at the bottleneck and a relatively short RTT, and are moving a large file. I could imagine codel’s delay allowing a session to build a large backlog and then “suddenly turning on AQM”. on a 10 MS link with O(200) packets queue depth, for example, you could build 100 ms plus of data in the queue, spend the delay mostly emptying it, and then drop the last queued packet because 100 ms had gone by, there was still data in the queue, and the next packet had sat there longer than 5 ms. _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
