[lkml]   [2000]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] document ECN in 2.4

On Mon, 6 Nov 2000, Andi Kleen wrote:

> On Mon, Nov 06, 2000 at 11:02:47AM +0000, Alan Cox wrote:
> > > with the TCP ECN_ECHO and CWR flags set, to indicate
> > > ECN-capability, then the sender should send its second
> > > SYN packet without these flags set. This is because
> >
> > Now that is nice. The end user perceived effect is that folks with faulty
> > firewalls have horrible slow web sites with a 3 or 4 second wait for each
> > page. The perfect incentive. If only someone could do the same to path mtu
> > discovery incompetents.
> And it penalizes good guys.
> If the host cannot answer to the first SYN for some legitimate reason
> then it'll never be able to use ECN.

The problem with ECN, unlike path MTU discovery, is not stupid
administrators who set the wrong things in the firewall; rather it is
stupid firewal/content-switch/intrusion-detector implementations.
With Sally's and KK's clout and enough noise from users vendors will fix
CISCO has already done it. Raptor is next. Nortel products do/will not
have this problem.

There is no reason to make the deployment more complex than it is and i am
not sure how wise it is to make the Mark Handley extension part of the
RFC. Not just because of complexity, but also because of holes such as the
one Andi points out.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.059 / U:2.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site