<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">I do suggest that you try to detect this case and explain the above facts automatically.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>