I'm curious, has anyone done some simulations to check if the following
qualitative statement holds true, and if, what the quantitative effect is:
With bufferbloat, the TCP congestion control reaction is unduely delayed.
When it finally happens, the tcp stream is likely facing a "burst loss"
event - multiple consecutive packets get dropped. Worse yet, the sender with
the lowest RTT across the bottleneck will likely start to retransmit while
the (tail-drop) queue is still overflowing.
And a lost retransmission means a major setback in bandwidth (except for
Linux with bulk transfers and SACK enabled), as the standard (RFC
documented) behaviour asks for a RTO (1sec nominally, 200-500 ms typically)
to recover such a lost retransmission...
The second part (more important as an incentive to the ISPs actually), how
does the fraction of goodput vs. throughput change, when AQM schemes are
deployed, and TCP CC reacts in a timely manner? Small ISPs have to pay for
their upstream volume, regardless if that is "real" work (goodput) or
unneccessary retransmissions.
When I was at a small cable ISP in switzerland last week, surely enough
bufferbloat was readily observable (17ms -> 220ms after 30 sec of a bulk
transfer), but at first they had the "not our problem" view, until I started
discussing burst loss / retransmissions / goodput vs throughput - with the
latest point being a real commercial incentive to them. (They promised to
check if AQM would be available in the CPE / CMTS, and put latency bounds in
their tenders going forward).
Best regards,
Richard
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
