TCP Initial Window 10 MFC

Wed Mar 5 03:38:13 UTC 2014

On 03/04/14 13:10, Kubilay Kocak wrote:
> On 5/03/2014 6:39 AM, hiren panchasara wrote:
>> On Wed, Aug 14, 2013 at 8:46 PM, Lawrence Stewart <lstewart at freebsd.org> wrote:
>>> On 08/15/13 02:44, Andre Oppermann wrote:
>>>> On 14.08.2013 04:36, Lawrence Stewart wrote:
>>>>> Hi Andre,
>>>>>
>>>>> [RE team is BCCed so they're aware of this discussion]
>>>>>
>>>>> On 07/06/13 00:58, Andre Oppermann wrote:
>>>>>> Author: andre
>>>>>> Date: Fri Jul  5 14:58:24 2013
>>>>>> New Revision: 252789
>>>>>> URL: http://svnweb.freebsd.org/changeset/base/252789
>>>>>>
>>>>>> Log:
>>>>>>    MFC r242266:
>>>>>>
>>>>>>     Increase the initial CWND to 10 segments as defined in IETF TCPM
>>>>>>     draft-ietf-tcpm-initcwnd-05. It explains why the increased initial
>>>>>>     window improves the overall performance of many web services without
>>>>>>     risking congestion collapse.
>>>>>>
>>>>>>     As long as it remains a draft it is placed under a sysctl marking it
>>>>>>     as experimental:
>>>>>>      net.inet.tcp.experimental.initcwnd10 = 1
>>>>>>     When it becomes an official RFC soon the sysctl will be changed to
>>>>>>     the RFC number and moved to net.inet.tcp.
>>>>>>
>>>>>>     This implementation differs from the RFC draft in that it is a bit
>>>>>>     more conservative in the case of packet loss on SYN or SYN|ACK
>>>>>> because
>>>>>>     we haven't reduced the default RTO to 1 second yet.  Also the
>>>>>> restart
>>>>>>     window isn't yet increased as allowed.  Both will be adjusted with
>>>>>>     upcoming changes.
>>>>>>
>>>>>>     Is is enabled by default.  In Linux it is enabled since kernel 3.0.
>>>>>
>>>>> I haven't been fully alert to FreeBSD happenings this year so apologies
>>>>> for bringing this up so long after the MFC.
>>>>>
>>>>> I don't think this change should have been MFCed, at least not in its
>>>>> current form. Enabling the switch to IW=10 on a stable branch is
>>>>> inappropriate IMO. I also think the "net.inet.tcp.experimental" sysctl
>>>>> branch is poorly named as per the important discussion we had back in
>>>>> February [1]. I would really prefer we didn't get stuck having to keep
>>>>> it around by making a stable release with it being present.
>>>>>
>>>>> I think this commit should be backed out of stable/9 and more
>>>>> importantly, 9.2-RELEASE.
>>>>
>>>> Backing out the patch isn't really necessary, just flip the switch to
>>>> off having it revert to the RFC5681 defaults.  Those who want it anyway
>>>> can simply enable it again.
>>>
>>> That doesn't address the sysctl tree naming concern or mechanism issue -
>>> please refer back to the Feb discussion; specifically the proposal to
>>> rename the experimental branch to "net.inet.tcp.nonstandard" and add an
>>> "allowed" leaf which takes a list of non-standard behaviours to allow
>>> tweaking in the stack.
>>>
>>> Leaving the sysctl branch named "experimental" conveys that the things
>>> which live under the branch are being evaluated in some way for becoming
>>> a default, which is very different to "nonstandard" which conveys that
>>> the user is twiddling things in a way which normally shouldn't be. IW=10
>>> may become a FreeBSD default at some point, but the mechanism for
>>> enabling it should be to specify the initial window as a value in
>>> segments, and as such by allowing any non-standard value (IW=7, IW=50),
>>> I strongly argue in favour for changing the branch name from
>>> "experimental" to "nonstandard".
>>>
>>> In order to continue this discussion in the context of what we started
>>> in Feb, I still request that this change be backed out of releng/9.2 so
>>> that 9.2-RELEASE doesn't ship with it. We can continue discussion for
>>> it's future in stable/9 and head after the backout so that 9.2 isn't
>>> held up.
>>>
>>>> IW10 has become RFC6928 (experimental) in April 2013.
>>>
>>> Great for the draft authors, but irrelevant for this discussion.
>>>
>>>>> As an aside, I am intending to follow up to the Feb discussion with a
>>>>> patch that implements the basic infrastructure I proposed so that we can
>>>>> continue that discussion.
>>>>
>>>> Again I'm deeply concerned and opposed to giving end users direct control
>>>> over the IW value.  I've had and seen too many cases of totally bogus
>>>> "tuning"
>>>> by cranking up random sysctls to insane values and then complaining about
>>>> FreeBSD being slow compared to Linux (and then ditching FreeBSD).
>>>
>>> Sorry, but referring to unspecified cases of stupidity resulting in loss
>>> of unquantified numbers of users as a reason against providing a
>>> controlled mechanism to change a default system parameter in a
>>> potentially harmful way is not a rational argument.
>>
>> I do not subscribe to the idea of "Let's not make life of 98% of users
>> better because 2% may do something stupid".
>>
>> I am revisiting this thread because at $work, we need to tweak
>> initcwnd (other than 10) to see how it behaves but there is no easy
>> way to tune it. (or am I missing something?)
>>
>> Can we please make initcwnd a sysctl tunable?
>>
>> cheers,
>> Hiren
> 
> +1 - We'd like to at least be able to measure the difference and impact
> of different values @ work, with the choice to make informed
> configuration decisions too.

I lost the battle of wills on this topic and 10.0 shipped with IW10
enabled by default :(

As for having it configurable, it is a trivial patch which perhaps,
Hiren, you might be willing to take a stab at? I obviously did not
manage to carve out the time last year to push forward with the agenda I
proposed in this thread, but I will get back to it at some point.

Cheers,
Lawrence