Subject: [aqm] draft-ksubram-lmap-router-buffer-sizes

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 30 Oct 2014 12:12:40 +0000

Folks from AQM may be interested to comment on draft-ksubram-lmap-router-buffer-sizes on the lmap list.

---

From: Dave Taht <[email-masked]>
Date: Thu, 30 Oct 2014 06:49:08 -0700

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-masked]> wrote:
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 30 Oct 2014 15:40:58 +0000

That might be a comment to make.

---

From: David Collier-Brown <[email-masked]>
Date: Thu, 30 Oct 2014 22:00:28 -0400

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

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
[email-masked]           |                      -- Mark Twain

---

From: Daniel Havey <[email-masked]>
Date: Fri, 31 Oct 2014 14:58:44 +0000 (UTC)

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-masked]> 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

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-masked]> wrote: 
>Folks from AQM may be interested to comment on draft-ksubram-lmap-router-buffer-sizes on the lmap list. _______________________________________________
aqm mailing list [email-masked] 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-masked] |                      -- Mark Twain

---

From: David Collier-Brown <[email-masked]>
Date: Fri, 31 Oct 2014 14:03:39 -0400

It's OK, we just need to write it up as informational material and cite 
it a lot. Maybe as an appendix to a congestion-related rfc, maybe as a 
little bitty one on it's own.

Having said that, I guess I've just volunteered to write it.

Therefor: If someone says where it should go, so people will find it 
when looking for the expected behaviour, I'll compose a draft and help 
make it fit.

--dave