From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id ECA9E200ABA for ; Thu, 6 Oct 2011 02:33:27 -0700 (PDT) Received: by bkas6 with SMTP id s6so4814447bka.16 for ; Thu, 06 Oct 2011 02:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=GnZ+SC1vwm9GrTcVjMYIxHmDtaUEeuJmIT61Hrfx7bw=; b=kzWAyqy5CCEAR+zTfY/hT8qPR49J6zZF2FZpuxbyOCmMNJCUDk0RiPIdcDNLaemMR6 FNMchgfObSkcLBdphjofld6KAt5dbOqOUjjpVOlvjS7M7VH7ialqplcj3OA/Tqr0Olzh ErUh2wsqp4+IgcylBKJnVTtXhhDhTR1Aee4WY= Received: by 10.204.129.143 with SMTP id o15mr415727bks.286.1317893605442; Thu, 06 Oct 2011 02:33:25 -0700 (PDT) Received: from [132.227.127.58] ([132.227.127.58]) by mx.google.com with ESMTPS id ex8sm4763896bkc.2.2011.10.06.02.33.23 (version=SSLv3 cipher=OTHER); Thu, 06 Oct 2011 02:33:24 -0700 (PDT) Message-ID: <4E8BF6B2.6030101@gmail.com> Date: Tue, 04 Oct 2011 23:18:26 -0700 From: =?ISO-8859-1?Q?David_T=E4ht?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: netdev@vger.kernel.org, bloat-devel@lists.bufferbloat.net Subject: Asserting ECN from userspace? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 06 Oct 2011 09:33:28 -0000 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. 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. 2) Test tools. It would be nice to be able, from userspace, to easily diagnose if ECN was working on a stream, end to end, and being able to set and receive the ECN bits on a less algorithmic basis (ie, not wedged deep within a kernel aqm such as RED or SFB) 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. Ah, ECN, we hardly know ye. as for item 1 I'm hard pressed to think of a case where setting the ECN bits on udp streams would introduce a security problem. As for 2, can live without. As for 3... perhaps a grantable network capability? A proxy could acquire privs to twiddle those bits before dropping root privs. That begs the question of how to see those bits in the first place. OOB data? And twiddling them, on a per stream basis, for a single packet, would seem to require something more robust than setsockopt/getsockopt (although that would work for udp streams)