[Top] [All Lists]

Re: CONFIG_INET_ECN creates problems

To: Rusty Russell <rusty@xxxxxxxxxxxxxxxx>
Subject: Re: CONFIG_INET_ECN creates problems
From: jamal <hadi@xxxxxxxxxx>
Date: Tue, 7 Nov 2000 23:25:49 -0500 (EST)
Cc: "David S. Miller" <davem@xxxxxxxxxx>, netdev@xxxxxxxxxxx, kuznet@xxxxxxxxxxxxx
In-reply-to: <20001108033116.3ADCF8120@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

On Wed, 8 Nov 2000, Rusty Russell wrote:

> I think someone said we used to blindly echo the ECN bits, though.

That was around 2.0.25 days, IIRC. The current implementation/RFC catches

>    We could generalize the Floyd solution
>    to N transmits (I suggest N >= 2, rather than one, but it's just a
>    inverse of the ECN sysctl), and use two bits in the route cache: one
>    to indicate that we've spoken to the host with ECN flags set, and one
>    to indicate that we've received a RST for an ECN packet.

If we are going to help avoid ECN turning into a fiasco like NAT (your
favorite ;->) then we need to hammer now. If we dont:
-The broken boxen will never be fixed. They violate RFCs and do not help
in making a better internet (ECN is a good thing). 
- ECN will never really take off. Why would i wanna wait for 2 SYNs 
before realizing that there's some stupid box in between me and I can already see the postings "you get faster page loadup
if you disable ECN"
Yes, the internet is an anarchy, and it's that bad bad wolf your mama
warned you about yadayadayada and we must learn to play well with
others, etc ....

There are several things that could be done:
1) complain to your vendor. Bad mouth them if they dont react.
It happens to be very effective.
2) complain to the sites that you cant get to. Point them to a general
site which shows they are violating some internet principles.

I realize what i am saying might not be as effective as having a dynamic
solution built into the stack... 

> Actually, I didn't propose ignoring RST packets; I didn't realize that
> Floyd suggested this.  That would be completely unacceptable.
> > How about we ship it on by default as is? :-)
> The distributions will all have to disable it.  I'd prefer that not to
> be the case.
> I repeat:
> Bogocode:
>       #define IPECN_RT_OK  0x01  /* Set if we ever got CE from them */
>       #define IPECN_RT_RST 0x02  /* Set if we ever got a RST from them */
>       if (sysctl_ecn_disable &&
>           (trans(rt) > sysctl_ecn_disable || IPECN_RT(rt) == IPECN_RT_RST)) {
>               ... no ECN ...
>       } else {
>               ... ECN ...
>       }

A route based solution might not be too bad. Your list will probably
grow too big.
What is bad is this extra bagage of trying to "better" understand RSTs

This is not a very smart idea, but here it is anyways:
- A known list of bad sites sitting somewhere. This is something along 
the same lines as a "known spammers list". The list gets new additions and
removal of repentant sites. some list already exists.

- A tool that will take this list and populate your route table or at
least your favorites amongst them (eg you could choose only

- a per-route attribute which says the route is not ecn friendly.
You dont bother negotiating ECN with the bad sites.

The list stays public and hopefully will be used to pressure site owners
to deploy fixes.
The kernel fix is very small and you dont screw around with TCP dynamics.


<Prev in Thread] Current Thread [Next in Thread>