On Fri, 26 Aug 2016, Kathleen Nichols wrote:

On 8/26/16 4:20 PM, David Lang wrote:
On Fri, 26 Aug 2016, Kathleen Nichols wrote:

I think it might be useful to say these tests measure the maximum
*potential* for
bufferbloat. That is, they plumb the depths of the buffers in the path.
I tried running
dslreports while I was running a video and though dslreports ramps
delays up to 700ms,
before and after that peak delay is more like 45ms. I don't think large
buffers are going
to go away, what matters is whether they are getting filled up.

So, is "bufferbloat" the existence of large buffers or the existence of
large queues? I think
the latter.

large buffers that never fill up may as well be small buffers.

it's the fact that the large buffers fill that's the problem.

Yes, that's the point.

so you can call it large queues instead of large buffers, but the result
is that packets end up being 'in transit' for a long time.

No, a large queue is a bunch of packets waiting in a queue (which is contained in a buffer). A large buffer with zero or a small number of packets in it is not going to result in packets being in transit for a long time.

Is a large buffer that is never used really a large buffer? or does whatever prevents it from being used really turn it into a small buffer?

The problem has never been a matter of the number of bytes the buffers hold, but rather the number of bytes relative to the data rate (also known as the time that data can wait in the buffer). A buffer that's the right size for a 1Gb/s connection is horribly bloated if the data rate is only 10Mb/s

We've found that the solution isn't just to shrink the size of the buffers (even if we first change from X packets to X bytes), and instead the proper solution is some form of active queue management that has the side effect of keeping the queues small.

I don't understand what you are trying to call out by trying to change the terminology.

David Lang
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat

Reply via email to