Re: [PATCH] tcp: Implement a two-level initial RTO as per draft RFC 2988bis-02.

[tsuna <tsunanet@gmail.com>]

On Wed, May 18, 2011 at 11:10 PM, Alexander Zimmermann
<alexander.zimmermann@comsys.rwth-aachen.de> wrote:
> Am 19.05.2011 um 06:33 schrieb tsuna:
>> Presumably if the user decides to tweak these knobs, they'll know
>> what's appropriate for their environment.
>
> Are you sure? I'm not. I fully agree with David that minRTO is

s/minRTO/initRTO/, right?

> something that a user shout not control at all

I personally don't like to hold the hand and spoon feed users too
much, I want to trust them to be responsible and know what they're
doing.  Yes, there will always be people who will act stupid and do
stupid things with whatever knobs you expose.  The web is full of
people who advise to tune up all the TCP rmem/wmem parameters to crazy
high level based on the voodoo belief that they're going to improve
their TCP performance, but then as long as you have knobs in your
system, these people will misuse them anyway and shoot themselves in
the foot, what can we do about that.

There's also a good chunk of people who know what they're doing, and
for them compile-time constants are annoying because it's inconvenient
to experiment and iterate quickly when you need to recompile your
kernel to change a value.  If turning the compile time constant into a
knob leaves the code reasonably straightforward and doesn't incur too
much overhead, then why not do it?

Regarding this knob in particular, I can imagine that people who are
in environment where RTT easily gets around 1s will be upset by the
change in the default value, and doubly upset that they have to
recompile their kernel to change the value back to 3s.  I'm in favor
of the reduction of initRTO, for the same reason Google is, but I can
also understand that the direction we're taking might not be
appropriate for everyone.

-- 
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com