From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ww0-f47.google.com (mail-ww0-f47.google.com [74.125.82.47]) (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 098AB200256 for ; Thu, 6 Oct 2011 22:23:18 -0700 (PDT) Received: by wwe5 with SMTP id 5so4661112wwe.28 for ; Thu, 06 Oct 2011 22:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=XeWgZxrTyw4K3QcYosSMlR6RYakAwjJEsqF7NPxvNDg=; b=gOUZcuLkEeMc0juqG/Uj2JlC1jOi1xQMCq9N722OtDW2EQUwncofeylvSvDvpFLHaz cWKvzazpUSGPQBWjDybe5NBhDD4QrUUw4TI++qN7/eg5ozUVyeRiRsb3fz493D336JN3 ZlpfdrQqq9OTnsNetWmrotT7Xk+tU6XIYS9q4= Received: by 10.216.230.73 with SMTP id i51mr232270weq.89.1317964996629; Thu, 06 Oct 2011 22:23:16 -0700 (PDT) Received: from [192.168.1.32] (68.144.72.86.rev.sfr.net. [86.72.144.68]) by mx.google.com with ESMTPS id n21sm13994920wbp.2.2011.10.06.22.23.11 (version=SSLv3 cipher=OTHER); Thu, 06 Oct 2011 22:23:13 -0700 (PDT) Subject: Re: Asserting ECN from userspace? From: Eric Dumazet To: David =?ISO-8859-1?Q?T=E4ht?= In-Reply-To: <4E8BF6B2.6030101@gmail.com> References: <4E8BF6B2.6030101@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 Oct 2011 07:23:09 +0200 Message-ID: <1317964989.3457.39.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 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 05:23:19 -0000 Le mardi 04 octobre 2011 à 23:18 -0700, David Täht a écrit : > 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) > For UDP, its really easy to set ECT(0) or ECT(1) in your outgoing frames, and test as well ECT(0),ECT(1),ECN in incoming frames. For the sending part: int tos = 0x2; /* ECT(1) */ setsockopt(fd, IP_PROTOIP, IP_TOS, &tos, sizeof(tos)); To be able to get the TOS value : int on = 1; setsockopt(fd, IP_PROTOIP, IP_RECVTOS, &on, sizeof(on)); RECVTOS (since Linux 2.2) If enabled the IP_TOS ancillary message is passed with incoming packets. It contains a byte which specifies the Type of Service/Precedence field of the packet header. Expects a boolean integer flag.