From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-23-ewr.dyndns.com (mxout-188-ewr.mailhop.org [216.146.33.188]) by lists.bufferbloat.net (Postfix) with ESMTP id C74442E044B for ; Fri, 4 Feb 2011 02:04:59 -0800 (PST) Received: from scan-21-ewr.mailhop.org (scan-21-ewr.local [10.0.141.243]) by mail-23-ewr.dyndns.com (Postfix) with ESMTP id 4CFA842B9E for ; Fri, 4 Feb 2011 10:04:58 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 213.186.56.95 Received: from witko.kerneis.info (witko.kerneis.info [213.186.56.95]) by mail-23-ewr.dyndns.com (Postfix) with ESMTP id 9DC71427E9 for ; Fri, 4 Feb 2011 10:04:53 +0000 (UTC) Received: from bob75-11-78-249-231-16.fbx.proxad.net ([78.249.231.16] helo=trurl.pps.jussieu.fr) by witko.kerneis.info with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1PlIX6-0000AL-7j; Fri, 04 Feb 2011 11:04:52 +0100 Received: from jch by trurl.pps.jussieu.fr with local (Exim 4.72) (envelope-from ) id 1PlIX0-0000dU-Hp; Fri, 04 Feb 2011 11:04:46 +0100 From: Juliusz Chroboczek To: Luca Dionisi References: <87mxmcdtvh.fsf@trurl.pps.jussieu.fr> Date: Fri, 04 Feb 2011 11:04:46 +0100 Message-ID: <87ei7odsjl.fsf@trurl.pps.jussieu.fr> MIME-Version: 1.0 Content-Type: text/plain X-SA-Exim-Connect-IP: 78.249.231.16 X-SA-Exim-Mail-From: jch@pps.jussieu.fr X-SA-Exim-Scanned: No (on witko.kerneis.info); SAEximRunCond expanded to false Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] =?iso-8859-1?q?About_LEDBAT=2C_=B5TP_and_BitTorrent?= 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: Fri, 04 Feb 2011 10:05:00 -0000 > I think that the 2 things have to be carried on independently, Yes. > The problem is that one cannot make sure that end users will act > fairly, by adjusting their sending rate. The only way to do this is > dropping packets, so that they are obliged to send again. Well, the issues of increased delay and greedy, unresponsive flows are, to a certain extent, distinct. One can image AQMs that are only concerned with penalising unresponsive flows but don't do anything to reduce buffer size when all flows are well-behaved. Conversely, one can imagine solving the buffer bloat problem on the assumption that all flows are TCP-friendly. --Juliusz