[Bloat] queuebloat

[Richard Scheffenegger]

Hi Bob,

I agree; nevertheless, there are still ways to improve the timeliness of 
loss recovery [over what is standardized in IETF] and reduce the dependency 
on RTO for TCP. Obviously other transport protocols could also use some of 
the same ideas.

For example, see Linux - lost retransmission detection, which is relevant 
when you run into burst loss scenarios, is only available there, but not 
specified anywhere. Or the recent addition to rfc3751-bis to improve SACK 
loss recovery at end-of-stream. Or some ideas (partially implemented in 
Linux already) to use synergistic information available to address spurious 
retransmissions or early lost retransmission recovery...

Thus loss is IMHO less of an issue - if all possible indications are used to 
deal with them in a timely (RTT) manner - than increasing RTT needlessly to 
a few times the base RTT. Of course, a decent AQM and ECN marking scheme 
would improve things even further, no question about that!

Best regards,
   Richard


----- Original Message ----- 
From: "Bob Briscoe" <bob.briscoe at bt.com>

> A reasonable* sized buffer is still needed to absorb bursts without loss. 
> If builders of kit make their buffers smaller in response to our 
> criticism, during bursts users will experience loss rather than delay. 
> That will lead transports to wait for a timeout to detect these losses. So 
> small buffers would just introduce a new cause of poor responsiveness. The 
> focus should be on small queues, not small buffers.