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 05D9E20067D for ; Thu, 13 Oct 2011 04:30:54 -0700 (PDT) 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 p9DBUMBm028924 ; Thu, 13 Oct 2011 13:30:36 +0200 (CEST) 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 C27EEC08E7; Thu, 13 Oct 2011 13:30:21 +0200 (CEST) Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.76) (envelope-from ) id 1REJUT-0001lx-Kp; Thu, 13 Oct 2011 13:30:21 +0200 From: Juliusz Chroboczek To: David =?iso-8859-1?Q?T=E4ht?= Subject: Re: Asserting ECN from userspace? References: <4E8BF6B2.6030101@gmail.com> Date: Thu, 13 Oct 2011 13:30:21 +0200 In-Reply-To: <4E8BF6B2.6030101@gmail.com> ("David =?iso-8859-1?Q?T=E4ht=22?= =?iso-8859-1?Q?'s?= message of "Tue, 04 Oct 2011 23:18:26 -0700") Message-ID: <7izkh5m8mq.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 X-Miltered: at jchkmail.jussieu.fr with ID 4E96CBCE.007 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4E96CBCE.007/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ Cc: netdev@vger.kernel.org, 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: Thu, 13 Oct 2011 11:30:55 -0000 Dave, I'm not sure what you are getting at. ECN is designed for routers, not for end-points. Assering ECN congestion-experienced at the sender will cause the sender to react to the congestion indication after a whole RTT (after the ECN-echo is received). For end-to-end flow control, it is both simpler and more efficient to reduce the sending rate immediately, without going over the network. There's a good reason why we're careful to distinguish congestion control (router-to-endpoint) and flow control (endpoint-to-endpoint). The latter is much easier. > 1) Applications such as bittorrent (transmission, etc) that are much > more aware of their overall environment could assert ECN on their UDP > streams to indicate congestion. The sender can react to congestion by simply reducing the sending rate. The receiver can react to congestion by pipelining fewer chunk requests to the sender. > 3) Web Proxies. A web proxy could note when it was experiencing > congestion on one side of the proxied connection (or another) and signal > the other side to slow down. It can cause the other side to slow down by simply stopping reading, thus causing the normal TCP flow control (not congestion control) to kick in. What would be useful, on the other hand, would be the ability to set the ECN enabled codepoint on UDP packets, and have some means to reliably check whether the Congestion-Experienced codepoint has been set by some intermediate router. But that's different from what you appear to be suggesting. -- Juliusz