Re: hotmail not dealing with ECN

Drago Goricanec
2001-01-26T17:37:57Z

At Fri, 26 Jan 2001 15:08:21 +0000 (GMT),
James Sutherland <jas88@cam.ac.uk> wrote:
>
> On Fri, 26 Jan 2001, David S. Miller wrote:
> > James Sutherland writes:
> > > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > > RST packet as "go away and never ever send traffic to this host again" -
> > > i.e. trying another TCP connection, this time with ECN disabled, would be
> > > acceptable.
> >
> > The connection failed, RST means connection reset. RST means all
> > state is corrupt and this connection must die. It cannot be
> > interpreted in any other way.
>
> Obviously. The connection is now dead. However, trying to make a new
> connection with different settings is perfectly reasonable.

Yes for the application, but not for the kernel. The kernel should
not make any assumptions about the reason for a RST.

Can you just picture if we implement what you are suggesting? Now
every single outgoing connection to a non-existant port or for any
other reason that returns a RST will have two complete connect cycles.
That's bad behavior and will not be tolerated.

On top of that, we would have to maintain extra state to decide
whether the previous request was a SYN with ECN or some other scenario
to avoid reacting to every RST we get. Unnecessary bloat!

> > Using it as a metric for ECN enabling is thus unacceptable.
>
> Why? The connection is dead, but there is nothing to prevent attempting
> another connection.

I fully support David Miller on this issue. Let Linux lead the path
to full adoption of ECN, and we'll all be better for it in the long
run.

Drago