[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sysctl should disable ECN by default

On Wed, 5 Sep 2001, Steve Langasek wrote:

> > Do *you* do that for all the things that don't work as they should?
> Yes, quite frankly.  Personally, I use only Free Software and software
> that runs on top of Free OSes.  Professionally, I work for an ISP, and
> we expect our vendors to live up to the promises they make.

If that's the case then shouldn't we disable all those kernel
compatibility hacks by default? Don't tell me your machine is clean, and
all those components are 100% protocol compliant.

Btw. since you are connected through alternet which servers you through
*Cisco* routers:

  tpo2:/home/tpo/# traceroute www.netexpress.net
  traceroute to shamu.netexpress.net (, 30 hops max, 40 byte
  12  netexpress-gw.customer.ALTER.NET ( 187 ms 173 ms 187 ms
  13  shamu.netexpress.net (  174 ms  189 ms  170 ms
  tpo2:/home/tpo/# xprobe
  FINAL:[ Cisco IOS 11.x-12.x ]

please live up to your claim and sue Cisco for their bloody CiscoPPP which
in the "early days" wouldn't allow you to connect a standard PPP device to
it, will you?

> At least this way, users who have broken routers will find out about the
> problem early, can easily disable the ECN behavior if they need to, and
> can set about finding a solution to the real problem.
> Professionally, I work for an ISP, and we expect

Yup. So did I. And that's why I was able to find out in the first place.
But let's see how "easy" that is. Please take an average Debian user. Give
it a machine that run's a 2.4 kernel behind an ECN-broken router and see
how long it takes for him to figure out what's wrong.

Or in other words, please take the same default install of Debian with a
2.4 kernel and then do this:

	# find / -exec grep -i "ECN" \{\} \;

And tell me how many pointers to ECN you'll find. Easy?

> In addition, ECN provides some significant advantages for users who aren't
> afflicted with Zylex routers.

Why is it that you are mixing up Zyxel and Zylex. Let me guess: you don't
have ISDN around. Now let me tell you that possibly Zyxel is the biggest
SOHO ISDN router vendor in Europe. So what? At least it's a nice exercise
for the users isn't it? It gives them deep insight into networking. So in
the end you are doing a favour to everybody, right? Where is the
semi-professional network admin that hasn't wished his whole life through
to be able to spend two days debuging a newly arived Debian box that *as
only machine* in the whole LAN isn't able to route out?

> I don't dispute that there are many cases where software authors are willing
> to accomodate broken client / server behavior, whether their goal is market
> share or mind share.  I just disagree that authors/maintainers have any
> *obligation* to accomodate software or hardware which is not
> standards-conformant.
> The solutions proposed to date all seem to be either contrary to policy, or
> contrary to the wishes of the maintainers of the affected packages.  Under
> such circumstances, I don't see where there's cause for questioning the
> maintainers' decisions.

You are right. A package maintainer - even if it's a fundamental package
as dpkg or the kernel or whatever can go and screw his users. It's up to
him. I wouldn't go as far as saying that this is precisely happening here,
at least not consciously because I doubt anybody who's pro ECN in the
kernel has had to debug a situtation such as described above.

But you can sure tell from my enthusiasm, and I'm no networking idiot,
that I *do* feel strong about it and that's exactly because I had fun
lately with it and I don't think it's necessary for everybody who happens
to have the bad luck to find itself in the same position to forcibly
repeat that lovely experience. And you can be certain that if the
situation stays as it is, I will not be the last one.

But tell me *one* thing:

	Why is it so hard to change a few lines and have the default be
	set to *off* and let whoever feels like it enable it?



             Tomas Pospisek
	     SourcePole   -  Linux & Open Source Solutions
	     Elestastrasse 18, 7310 Bad Ragaz, Switzerland
	     Tel: +41 (81) 330 77 11

Reply to: