Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: "David Täht" <dave.taht@gmail.com>
To: netdev@vger.kernel.org, bloat-devel@lists.bufferbloat.net
Subject: Asserting ECN from userspace?
Date: Tue, 04 Oct 2011 23:18:26 -0700	[thread overview]
Message-ID: <4E8BF6B2.6030101@gmail.com> (raw)


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)


             reply	other threads:[~2011-10-06  9:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-05  6:18 David Täht [this message]
2011-10-06 23:52 ` Andi Kleen
2011-10-07  5:23 ` Eric Dumazet
2011-10-07 17:25 ` Rick Jones
2011-10-13 11:30 ` Juliusz Chroboczek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E8BF6B2.6030101@gmail.com \
    --to=dave.taht@gmail.com \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox