Following the WGLC there was some further discussion of the AQM WG
recommendations draft. Some of this has suggested further updates to this
draft. This is a list of the key points we noted, and our proposed action
to update draft -04.
1) DOCUMENT FLOW
COMMENT BB: The two halves of the document s
In the other long thread, gorry said something that didn't quite ring
true with me:
"Our goal should be AQM in every buffer".
Well, that's somewhat desirable but not doable (at least in my world) -
1) The device has sufficient buffering to get at least one packet out.
2) There's a tx ring which
I’d be interested in comments on this.
> From:
> Subject: New Version Notification for
> draft-baker-aqm-sfq-implementation-00.txt
> Date: June 13, 2014 at 2:52:07 PM PDT
> To: Fred Baker , Rong Pan , Fred Baker
> , Rong Pan
>
>
> A new version of I-D, draft-baker-aqm-sfq-implementation-00.t
Really excellent, Fred, on a first reading!
nit 1) drops tend to happen in bursts on a tail drop queue (not
necessarily on this bottleneck, but elsewhere on the network). By
breaking up flows into sequences of distinctly different packets, this
applies minor damage to more flows, instead of severe
doing this privately...
" The weakness of a WRR approach is the search time
expended when the queuing system is relatively empty, which the
calendar queue model obviates."
This is a little strong.
Fq_codel (and DRR) is darn close to O(1) on the dequeue side for
sparse numbers of flows. I w
