Yeah, I have encountered this type of problem in many forms. It seems that there are fundamental misunderstandings of the problem. This seems prevalent in expert networking communities from people who have the knowledge, but, perhaps have not thought the problem through thoroughly.
I guess we are just working at cross-purposes with other communities. Perhaps there is no cure for this problem and maybe we just have to accept and embrace it. ...Daniel On Thursday, October 30, 2014 7:00 PM, David Collier-Brown <[email protected]> wrote: Yup: author makes a classic, and I fear common, wrong assumption about tradeoffs in queuing systems. Latency is minimized throughout the operating range if a queue is not allowed to form. TCP consciously sees a queue as congestion and avoids having it. Bufferboat causes queuing, and degrades both (low) latency and throughput, trying to drive the link toward congestive collapse. The worst of all possible worlds! In this case it also tries to drive Dave Taht's circulation system into collapse, which is doubly ungood. --dave On 10/30/2014 09:49 AM, Dave Taht wrote: I didn't get past the first sentence. "The question boils down to quantify buffer sizes and yet achieve 100% utilization on links with maximum throughput at a feasible cost. " My goal has always been to have minimal induced latency and reasonable utilization, and also to keep my blood pressure low. Reading further strikes me as damaging to both goals. On Thu, Oct 30, 2014 at 5:12 AM, Fred Baker (fred) <[email protected]> wrote: >Folks from AQM may be interested to comment on >draft-ksubram-lmap-router-buffer-sizes on the lmap list. >_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest [email protected] | -- Mark Twain _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
