From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 509C120035E for ; Mon, 20 Feb 2012 14:56:16 -0800 (PST) Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1KMtlj4082975 ; Mon, 20 Feb 2012 23:56:00 +0100 (CET) X-Ids: 168 Received: from lanthane.pps.jussieu.fr (lanthane.pps.jussieu.fr [134.157.168.57]) by hydrogene.pps.jussieu.fr (Postfix) with ESMTPS id 2AF22C0BB2; Mon, 20 Feb 2012 23:55:46 +0100 (CET) Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.77) (envelope-from ) id 1Rzc93-0005Vc-Tg; Mon, 20 Feb 2012 23:55:45 +0100 From: Juliusz Chroboczek To: Yuchung Cheng Subject: Re: tcp fast open? References: Date: Mon, 20 Feb 2012 23:55:45 +0100 In-Reply-To: (Yuchung Cheng's message of "Fri, 17 Feb 2012 07:24:32 -0800") Message-ID: <7i39a515e6.fsf@lanthane.pps.jussieu.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Miltered: at jchkmail.jussieu.fr with ID 4F42CF73.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F42CF73.000/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ Cc: Hsiao-keng Jerry Chu , bloat-devel@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:56:16 -0000 > Btw, I am very interested in learning the result of AQM vs > delayed-based CC like ledbat. That's something that I discussed with the creators of LEDBAT a year ago (when they convinced me to implement µTP in Transmission). Here's what I recall of what Shalunov told me -- but it was a long time ago, and I was badly jetlagged, so I could be speaking nonsense. LEDBAT reacts to loss in exactly the same way as Reno does -- it reduces its congestion window by 1/2. Hence, if the bottleneck is running an agressive loss-based AQM such as BLUE, then LEDBAT will behave just the same as NewReno. Note that this is not the case of the variant of LEDBAT implemented in µTP, which on loss divides its window by 1/sqrt(2) (if memory serves). Hence, µTP will, in that case, behave like an aggregate of two Reno flows. However, since µTP doesn't implement slow start or fast recovery, µTP should still end up being far less agressive than Reno. --jch