netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: David Miller <davem@davemloft.net>
Cc: hagen@jauu.net, jheffner@psc.edu, netdev@vger.kernel.org
Subject: Re: [PATCH] tcp: don't allow unfair congestion control to be built without warning
Date: Fri, 27 Oct 2006 15:21:49 -0700	[thread overview]
Message-ID: <20061027152149.42bcb539@dxpl.pdx.osdl.net> (raw)
In-Reply-To: <20061027.151238.59655130.davem@davemloft.net>

On Fri, 27 Oct 2006 15:12:38 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@osdl.org>
> Date: Fri, 27 Oct 2006 14:59:13 -0700
> 
> > On Fri, 27 Oct 2006 14:37:01 -0700 (PDT)
> > David Miller <davem@davemloft.net> wrote:
> > 
> > > From: Stephen Hemminger <shemminger@osdl.org>
> > > Date: Fri, 27 Oct 2006 14:24:02 -0700
> > > 
> > > > Only some (very few) have any bad consequences. So the typical
> > > > distribution should be able to switch with most available for everyone,
> > > > and only a few needing special privileges.
> > > 
> > > I would strongly disagree as we've had several OOPS'er class bugs in
> > > the less frequently used algorithms.
> > > 
> > 
> > Then tag those as restricted.  Why should we keep app's away from
> > the simple ones.
> 
> You can't predict bugs, but what you can do is know that the lesser
> used algorithms are by definition less tested and therefore more
> likely to have bugs.  Everything except the default and Reno are
> lesser used.

If they aren't usable they should be marked BROKEN or something
like that. The stability argument doesn't really work, we don't
like to let root kill the system either.
 
> Safe by default, there is no other choice.  You fail to respond to
> THAT part of my email.  That's the important point.  Let me
> reiterate:
> 
> > It's bad enough that people are all over us for the default algorithm
> > we have choosen, so it'd be extremely irresponsible and even worse if
> > we allowed users to select any of the other "research" algorithms for
> > their TCP connections by default just because those modules happened
> > to be configured into the kernel.

Make it hard for them to configure then.  I don't want your
distro to ship with the risky ones turned on.  But we should allow
use of reno, bic, cubic, lp, htcp, and westwood (maybe) by regular
users if admin allows.

> > This userspace convenience argument holds zero water.
> >
> > Provide a way for the administrator to control the situation fully,
> > and choose a sane default which errs on the side of caution for the
> > sake of internet stability.
> 
> Please reread this and consider why it's important.

The current situation is fine. You have to ask for them in the configuration,
and root has to either load the module or set it as default.

The restricted flag patch which you have ignored, would be a way to
allow them to be configured but tag the "bad apples" for only
root usage.





  reply	other threads:[~2006-10-27 22:22 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-25 18:08 [RFC] tcp: setsockopt congestion control autoload Stephen Hemminger
2006-10-25 23:21 ` Patrick McHardy
2006-10-26  5:22 ` Evgeniy Polyakov
2006-10-26 14:34   ` Stephen Hemminger
2006-10-26 14:57     ` Evgeniy Polyakov
2006-10-26 15:23       ` Stephen Hemminger
2006-10-26 17:05         ` Patrick McHardy
2006-10-26 20:55       ` David Miller
2006-10-26 17:29 ` John Heffner
2006-10-26 20:57   ` David Miller
2006-10-26 22:44   ` Hagen Paul Pfeifer
2006-10-26 22:53     ` John Heffner
2006-10-26 23:52     ` [PATCH] Check if user has CAP_NET_ADMIN to change congestion control algorithm Hagen Paul Pfeifer
2006-10-26 23:59       ` Ian McDonald
2006-10-27  0:07         ` David Miller
2006-10-27  0:20           ` Ian McDonald
2006-10-27  0:02       ` David Miller
2006-10-27 10:43         ` Hagen Paul Pfeifer
2006-10-27 14:41           ` Stephen Hemminger
2006-10-27 15:21             ` Hagen Paul Pfeifer
2006-10-27 15:48               ` Stephen Hemminger
2006-10-27 17:30                 ` [PATCH] tcp: don't allow unfair congestion control to be built without warning Stephen Hemminger
2006-10-27 17:43                   ` John Heffner
2006-10-27 17:59                     ` [PATCH] tcp: allow restricting congestion control choices Stephen Hemminger
2006-10-27 21:17                   ` [PATCH] tcp: don't allow unfair congestion control to be built without warning David Miller
2006-10-27 21:24                     ` Stephen Hemminger
2006-10-27 21:37                       ` David Miller
2006-10-27 21:59                         ` Stephen Hemminger
2006-10-27 22:12                           ` David Miller
2006-10-27 22:21                             ` Stephen Hemminger [this message]
2006-10-27 22:24                               ` David Miller
2006-10-28  0:48                                 ` Stephen Hemminger
2006-10-28  3:10                                   ` [RFC] tcp: available congetsion control Stephen Hemminger
2006-10-27 21:22             ` [PATCH] Check if user has CAP_NET_ADMIN to change congestion control algorithm David Miller
2006-10-27  1:03       ` Stephen Hemminger
2006-10-27 18:14 ` [PATCH] tcp: setsockopt congestion control autoload Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061027152149.42bcb539@dxpl.pdx.osdl.net \
    --to=shemminger@osdl.org \
    --cc=davem@davemloft.net \
    --cc=hagen@jauu.net \
    --cc=jheffner@psc.edu \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).