From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 29884200256 for ; Fri, 7 Oct 2011 10:25:46 -0700 (PDT) Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g1t0026.austin.hp.com (Postfix) with ESMTP id A1309C444; Fri, 7 Oct 2011 17:25:44 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g1t0038.austin.hp.com (Postfix) with ESMTP id 5007030095; Fri, 7 Oct 2011 17:25:44 +0000 (UTC) Message-ID: <4E8F3617.5080001@hp.com> Date: Fri, 07 Oct 2011 10:25:43 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: =?ISO-8859-1?Q?David_T=E4ht?= Subject: Re: Asserting ECN from userspace? References: <4E8BF6B2.6030101@gmail.com> In-Reply-To: <4E8BF6B2.6030101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 07 Oct 2011 17:25:46 -0000 On 10/04/2011 11:18 PM, David Täht wrote: > > No sooner had I noted (with pleasure) the kernel's new ability to > correctly set the dscp bits on IPv6 TCP streams without messing with the > negotiated ECN status, that I found several use cases where being able > to assert ECN from userspace (for either ipv4, or ipv6) would be useful. > ... > 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. > ... > As for 3... perhaps a grantable network capability? A proxy could > acquire privs to twiddle those bits before dropping root privs. For 3, couldn't/shouldn't the proxy simply stop draining the appropriate socket buffer to cause TCP's existing flow control to slow down that side? rick jones