[lkml]   [2008]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: time for TCP ECN defaulting to on?
On Wed, 5 Nov 2008, David Miller wrote:

> This kind of thinking just perpetuates the problem forever.

Well, I also think IPv6 breaks things for some people (mostly buggt DNS
resolvers) but I wholly support this being default on. The ISP business is
going in the direction of faster links and smaller interface buffers,
meaning WRED is used less and less, thus lessening the benefit of ECN.

I see that in
<> there
is a recommendation to not use ECN on retransmits, is there code right now
(or planned) to do some kind of "ECN blackhole detection", ie if no
response is received to SYN with ECN set, continue by sending the second
SYN without ECN and keep this information for the duration of the TCP

If there is, I do agree with you that enabling ECN by default is a good
idea. Without such code, I still believe there are enough broken devices
out there that will create problems for people.

It's like the TCP option order "bug", where some devices would drop the
packets because of buggy implementations, that was changed in Linux to
work around others buggy code, and I see "ECN blackhole detection" as a
similar measure.

Mikael Abrahamsson email:

 \ /
  Last update: 2008-11-07 05:49    [W:0.070 / U:0.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site