[Bloat] Goodput fraction w/ AQM vs bufferbloat

["Richard Scheffenegger" <rscheff@gmx.at>]

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