lkml.org 
[lkml]   [2008]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: time for TCP ECN defaulting to on?
On Fri, 7 Nov 2008, Mikael Abrahamsson wrote:

> On Fri, 7 Nov 2008, Ilpo Järvinen wrote:
>
> > On Fri, 7 Nov 2008, Mikael Abrahamsson wrote:
> >
> > > On Wed, 5 Nov 2008, David Miller wrote:
> > >
> > > > This kind of thinking just perpetuates the problem forever.
> > >
> > > 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.
> >
> > That is entirely bogus claim! The different ordering of options cost us
> > nothing, while disabling ECN certainly has an innumerable cost both in
> > performance and in nobody taking the initiative which makes the situation
> > worse for everybody.
>
> I can't comment on "ECN blackhole detection" costing or costing none since I
> haven't been able to find the discussion between Alexey Kuznetsov and Sally
> Floyd that David Miller was referring to. Anything more to go on? A direct
> link to the thread would be great.

No idea about the mail. But anyway some cost comes from the fact that
there is no desired to fix broken things then, nor even to start doing
compliant equipment. Thus losing the potential benefits of ECN. It
has been around for years and we're still having this discussion about
blackhole detection being necessary to keep operating, which is
ridicilous.

And, would there be a need for reorder the TCP headers it would certainly
get done with all breakage associated (not very likely that need will
arise though because those parts of the header are well utilized already).
It would basically be the same as with such things like window scaling,
there's no window scaling blackhole detection in kernel besides one
manually turning it off. Would there be detection why would those window
scaling broken devices ever get fixed (and the corresponding end hosts
would be doomed for 64k window forever)... Not to mention other similar
examples.

> I have sent an email (which will hopefully initiate a discussion) to a
> mailinglist populated by a lot of the operational ISP community and asked
> around about ECN and views on that. I also checked around on core router
> platforms (Cisco 12000 and Cisco CRS-1, which definitely is two of the top
> three core router platforms deployed in the world) and it seems they do not
> support ECN as far as I can discern. This pretty much in the next 5 year
> timeframe ECN widespread support in the major core ISP networks out of the
> question, leaving ECN support on the slower links where it might be deployed
> faster. I doubt it though.

I think you partially miss the point here. In many cases not every single
router has to _support_ ECN to get its benefits, not-supporting is not the
problem in itself (though it would be nice to get that "fixed" as well)
but breaking ecn-enabled connections. I suppose you didn't check that
aspect? I'd guess those mentioned devices will interoperate just fine
since one can mostly connect ok with ecn too besides rare exceptions
rather than things being vice-versa.

The most crucial components are anyway the points of congestion, I don't
know enough isp topologies but I suppose those core routers are not the
ones where towards subscribers device traffic congests?

> Now, IPv6 for me is cruicial to the continuing life and prosperity of the
> Internet (NAT is bad). ECN is "nice to have".

Sure.

> I do see Linux (and Linux users) as leader(s) in deploying new technology,
> with ECN being one of them. Question is how much hurt we're going to take for
> it.

I doubt it any worse than with eg. timestamps.


--
i.
\
 
 \ /
  Last update: 2008-11-07 12:31    [W:0.078 / U:7.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site