Re: Asserting ECN from userspace?

[Juliusz Chroboczek <jch@pps.jussieu.fr>]

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