Thread (29 messages) flat view 29 messages, 7 authors, 2007-02-13

Re: [patch 3/3] tcp: remove experimental variants from default list

From: Stephen Hemminger <hidden>
Date: 2007-02-12 20:37:29

On Mon, 12 Feb 2007 12:32:40 -0800 (PST)
David Miller [off-list ref] wrote:
From: "Ian McDonald" <redacted>
Date: Tue, 13 Feb 2007 09:13:52 +1300
quoted
Unless of course the papers you saw at PFLDNET showed that Cubic was a
really good choice and you want to point us to those papers.
I heavily dislike all of these "reactionary" patches from Stephen
after he attended PFDLNET.

If he never went there, none of these patches would have been
proposed.  He went to the sermon and he became converted :-)
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. 

We want people to play with this stuff, and they can experiment
regardless of whatever options or even code we put into the kernel.
Every user can muck with the congestion control on their computer
however they want, and THAT'S GOOD!

Sure we indirectly recommend to distribution vendors what to use
by default by the Kconfig defaults we put into the vanilla tree,
and that's fine too.

Even after reading all of the papers, I still think CUBIC or even BIC
by default is not all that controbersal or radical thing to use by
default.

I'm sorry if the researchers and IETF folks don't like this.  Too bad,
get over it.
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.
If you use RENO you're stupid, since performance is going to stink for
absolutely normal connections.  Fact: high BDP pipes are everywhere,
even grandma has one.  So just taking out the best solution we have
for that problem currently because it's not perfect is not the answer.
Do I need to dig out the "Why Reno sucks" graphs?

-- 
Stephen Hemminger [off-list ref]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help