<p dir="ltr">I think he may be seeing a complex interaction of various different queue components and bottlenecks, which in total manages to confuse TCP congestion control sufficiently to cause reduced throughput.</p>
<p dir="ltr">I suspect that there is a shaper at the ISP end which limits the bandwidth available to any single subscriber. This is separate from the queue serving the tower itself, which is what has been admitted to be periodically overloaded. However, "overloaded" in network engineer parlance just means a multi-user link that is saturated. There might well be enough elasticity to allow one subscriber their full allocation by pushing others out of the way. In this condition, the tower queue will be full and so will the shaper queue. I imagine the shaper queue contributes the most to induced latency.</p>
<p dir="ltr">However, this "pushing others out of the way" on a drop-tail queue is done by allowing the congestion window to grow to large values, facilitated by the deep ISP shaper queue. This effect is defeated (by design) by running an ingress AQM shaper, which keeps the ISP shaper queue empty.</p>
<p dir="ltr">A useful exercise might be to log the idle latency over a long period of time, and correlate it to peak load periods, as A&A do. <a href="http://aa.net.uk/kb-broadband-cqm.html">http://aa.net.uk/kb-broadband-cqm.html</a> .</p>
<p dir="ltr">- Jonathan Morton<br>
</p>