Yes, it looks like typical head-of-line blocking with a multi-second
buffer.  To smooth it out, you would need an averaging window wider than
the effective (bloated) RTT.

A tell-tale symptom is that the width of the gap, in which little or no
progress is made at the application layer, is approximately the measured
RTT at the left edge of the valley (or, equivalently, the peak RTT). It
takes that long for the retransmitted packets to traverse the stuffed
queue, even though the sender also reduces its send rate at the same time.

The latter should cause the RTT to reduce somewhat after the right edge of
the valley - this is part of the classic sawtooth.  Another tell-tale is
therefore that the valleys are regularly spaced on a lengthened test,
though there are other possible causes of that.

Your user should be able to reproduce the effect on a big, single stream
download, by watching the progress and noting that it periodically stalls
and then jumps ahead.  The average progress rate remains 50Mbps, but the
instantaneous progress rate regularly falls to zero.

I do suggest that you try to detect this case and explain the above facts

- Jonathan Morton
Bloat mailing list

Reply via email to