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

Re: sysctl should disable ECN by default



Summary:

1) why not disable ECN in kernel-image? it would be cleaner.
2) why not disable ECN in /etc/network/options? it would be 
more relevant and visible than sysctl.conf.
3) can we disable ECN for joe user with the default kernel
while permitting joe custom-kernel-user to enable ECN with
one checkbox? 
4) more than one place to make a configuration change
reuduces ease of use, which is what we're trying to achieve
by disabling ECN in the first place.

The Director's Cut:

> Good. The problem - it is on by default in our precompiled kernel-image
> packages. To disable (by default), (a) you have to remove ECN support from
> kernel or (b) either patch the kernel to make int off-as-default (*) or (c) put
> in in the template of sysctl.conf.
> 
> (*) I doubt Herbert Xu would like such modifications.

(*) wha? no kernel patch is required.  The default
distribution of the kernel, as distributed by Linus Himself
leaves ECN off.  Somewhere, someone decided to turn it on.

Can we just choose option (a) and be done with it?
If Debian isn't going to choose option (a), why are we
talking about option (c)?

I think if Herbert believes that ECN should be enabled
in the kernel, that's an intentional statement about
his confidence in ECN.  A later, standard package that
reconfigures the kernel at runtime seems inelegant when
the same configuration could easily be made just once
in the kernel config.  

> Okay, why not just put the line into sysctl.conf and present a big
> warning in the baseconfig?

I'm sorry, I'm not familiar with what a warning in
baseconfig would mean. Would I see it once? many times?
at upgrade? only on the initial install?  

Would this be printed when kernel-image is installed?
when kernel-package is run?  from netbase?  something at
all related to networking or the kernel?

Behind a default kernel configured with ECN disabled,
I would prefer the patch that puts this behavior in
/etc/network/options, since: 1) it's clear how to print
a message describing that ECN is disabled from there,
2) that configuration file has something to do with
networking, and 3) there's apparently a precedent with
syn_cookies configuration.

> > then you should see the logic in respecting the user's
> > wishes, and not trying to disable what they've knowingly
> > enabled in the kernel configuration.
> 
> Look, we have in general two parts of users:
> 
> - "administrator" kind, people that _may_ need ECN (but mostly don't
>   though). We can expect them to RTFM and remove the hook from
>   sysctl.conf after reading the baseconfig message.
>
> - the "users" - the majority. People that do as less RTFM as possible,
>   that do not need ECN and the should not be bothered with such
>   problems. This people would ignore the warning and have an easier life
>   without getting in touch with sysctl.conf.

It seems our difference is that you think prioritizing
users means choosing for them, and I think prioritizing
users means respecting their (possibly incorrect, possibly
ignorant) choice.  These don't necessarily conflict,
but it requires care to support both.  

I don't think the dichotomy between illiterate idiots and
uber-administrators is realistic: I'm an 'administrator'
who'd rather spend time playing my guitar or doing research
than reading documentation.  There are users of varying
skill levels, including those who have to recompile their
own kernel and will have the opportunity to decide in the
kernel configuration whether to enable ECN.

**When one checkbox should suffice, there should not be two.**

> Is my proposal acceptable now?

"Big warning" + "ECN disabled by default" => acceptable.
Who am I to complain?

All I care about is that whatever legitimate attempts
the user makes to configure his or her system are
respected whenever possible.  If a user configures
a kernel and says "ECN, yes!" he has a reasonable
expectation that ECN will actually be enabled.  If ECN
will not be enabled, this must be clear - not hidden in
/usr/share/doc/{netbase,procps,kernel-image}, not hidden
in the gobs of messages one clicks through when installing
Debian, but shown when a custom kernel is installed or
booted.  Better yet, if the user has enabled it in the
kernel, it should just stay enabled.

I realize these are hard things.  I will tell a short
story to try to justify the effort.  My mother uses a
windows machine, and wanted to configure her printer to
print 360dpi instead of 180dpi.  She found that to do this,
she would have to enter the printer options dialog every
time she wanted to print.  From within an application,
the configuration is not saved; not even for future
use by that application. Only if you enter the identical
printer options dialog from the control panel are settings
saved permanently.  She has every legitimate reason to
believe that the choice made in the options dialog from
an application would be as permanent as from the control
panel, but it is not.  Let's not make it as difficult to
configure a Debian system.

This discussion presumes that Herbert and the decision
makers want ECN configured in the kernel, but don't want
it enabled by default, which seems irreconcilable to me.

-neil



Reply to: