On Fri, May 15, 2015 at 9:09 AM, Bill Ver Steeg (versteb) <versteb@cisco.com> wrote:

Lars-

You make some good points. It boils down to the fact that there are several things that you can measure, and they mean different things.

Bvs

-----Original Message-----
From: Eggert, Lars [mailto:lars@netapp.com]
Sent: Friday, May 15, 2015 8:44 AM
To: Bill Ver Steeg (versteb)
Cc: Aaron Wood; cake@lists.bufferbloat.net; Klatsky, Carl; cerowrt-devel@lists.bufferbloat.net; bloat
Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs cablemodems

I disagree. You can use them to establish a lower bound on the delay an application over TCP will see, but not get an accurate estimate of that (because socket buffers are not included in the measurement.) And you rely on the network to not prioritize ICMP/UDP but otherwise leave it in the same queues.

On recent versions of Linux and Mac, you can get most of the socket buffers to "go away". I forget the socket option offhand.

And TCP small queues in Linux means that Linux no longer gratuitously generates packets just to dump them into the queue discipline system where they will rot.

How accurate this now can be is still an interesting question: but has clearly improved the situation a lot over 3-4 years ago.

> If you can instrument TCP in the kernel to make instantaneous RTT available to the application, that might work. I am not sure how you would roll that out in a timely manner, though.

Well, the sooner one starts, the sooner it gets deployed.

Jim