From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by lists.bufferbloat.net (Postfix) with SMTP id 4F4282E07B3 for ; Sat, 23 Apr 2011 01:00:55 -0700 (PDT) Received: (qmail invoked by alias); 23 Apr 2011 08:00:53 -0000 Received: from unknown (EHLO srichardlxp2) [213.143.107.142] by mail.gmx.net (mp056) with SMTP; 23 Apr 2011 10:00:53 +0200 X-Authenticated: #20720068 X-Provags-ID: V01U2FsdGVkX19p1jMjWKxpNqZDKBYql/+sN9ocatDjjMVo1f/PEc wSUD79nL3wr3vw Message-ID: From: "Richard Scheffenegger" To: , "Bob Briscoe" References: <201104131119.p3DBJIBu025003@bagheera.jungle.bt.co.uk> Date: Sat, 23 Apr 2011 09:55:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Y-GMX-Trusted: 0 Subject: Re: [Bloat] queuebloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 08:00:56 -0000 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" > 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.