On Mon, 12 Feb 2007 12:32:40 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> From: "Ian McDonald" <[EMAIL PROTECTED]> > Date: Tue, 13 Feb 2007 09:13:52 +1300 > > > 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 <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
