> On 15 May, 2015, at 14:27, Bill Ver Steeg (versteb) <vers...@cisco.com> wrote: > > But the TCP timestamps are impacted by packet loss. You will sometimes get an > accurate RTT reading, and you will sometimes get multiples of the RTT due to > packet loss and retransmissions. I would hate to see a line classified as > bloated when the real problem is simple packet loss. Head of line blocking, > cumulative acks, yada, yada, yada.
TCP stacks supporting Timestamps already implement an algorithm to get a relatively reliable RTT measurement out of them. The algorithm is described in the relevant RFC. That’s the entire point of having Timestamps, and it wouldn’t be difficult to replicate that externally by observing both directions of traffic past an intermediate point; you’d get the partial RTTs to each endpoint of the flow, the sum of which is the total RTT. But what you’d get is the RTT of that particular TCP flow. This is likely to be longer than the RTT of a competing sparse flow, if the bottleneck queue uses any kind of competent flow isolation. - Jonathan Morton _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
