Re: [aqm] New Version Notification for draft-baker-aqm-sfq-implementation-00.txt

[Daniel Havey <[e-mail]>]

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) <[e-mail]> wrote:

 Subject: Re: [aqm] New Version Notification for draft-baker-aqm-sfq-implementation-00.txt
 To: "[e-mail]" <[e-mail]>
 Cc: "RichardScheffenegger" <[e-mail]>, "[e-mail]" <[e-mail]>, "grenville armitage" <[e-mail]>
 Date: Tuesday, June 24, 2014, 1:01 PM
 
 
 On
 Jun 24, 2014, at 12:45 PM, Daniel Havey <[e-mail]>
 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.