lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070212.124734.07455258.davem@davemloft.net>
Date:	Mon, 12 Feb 2007 12:47:34 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	shemminger@...ux-foundation.org
Cc:	ian.mcdonald@...di.co.nz, baruch@...en.org, netdev@...r.kernel.org
Subject: Re: [patch 3/3] tcp: remove experimental variants from default list

From: Stephen Hemminger <shemminger@...ux-foundation.org>
Date: Mon, 12 Feb 2007 12:37:13 -0800

> My patches weren't reactionary. Going to pure old Reno is reactionary.
> It was more looking at the state of the code on the flight back
> and cleaning house. Others were/are reactionary. 

Ok.

The only patch I have a real problem with is the DEFAULT_*
removals, the choices are frankly arbitrary.

Vegas is buggy, that's nice, why don't we simply fix the
bugs in our implementation?

Westwood is very conservative, frankly, and I therefore see
no reason it cannot be offered as a default either.

HTCP doesn't do anything earth shattering either.

I think the whole suite of algorithms in that list are
reasonable.

And even re-reading your patch, you're messing with the
DEFAULT_* setting for the case where the user selected
TCP_CONG_ADVANCED.

I think TCP_CONG_ADVANCED implies an intention by the user,
and if he wants to choose one of those listed as a default
why should we stop them?

The distributions take the default we recommend, and that's
all that matters for wide deployment.

> I push the problem back in their court: "Why do you not have a process
> that causes consensus?" IETF has done nothing to create any incentive
> for long term cooperation.

Yep, this is a good point.

> Do I need to dig out the "Why Reno sucks" graphs?

Hehe :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ