[PATCH] Add a new TCP_IGNOREIDLE socket option

[Lawrence Stewart]

On 02/21/13 20:20, Sepherosa Ziehau wrote:
> On Wed, Feb 20, 2013 at 11:59 AM, Lawrence Stewart <lstewart at freebsd.org> wrote:
>> Hi Sephe,
>>
>> On 02/20/13 13:37, Sepherosa Ziehau wrote:
>>> On Wed, Feb 20, 2013 at 9:46 AM, Lawrence Stewart <lstewart at room52.net> wrote:
>>>> *crickets chirping*
>>>>
>>>> Time to move this discussion forward...
>>>>
>>>>
>>>> If any robust counter-arguments exist, now is the time for us to hear
>>>> them. I haven't read anything thus far which convinces me that we should
>>>> not provide knobs to tune our stack's dynamics.
>>>>
>>>> In the absence of any compelling counter-arguments, I would like to
>>>> propose the following:
>>>>
>>>> - We rename the net.inet.tcp.experimental sysctl node introduced in
>>>> r242266 for IW10 support to net.inet.tcp.nonstandard, and re-parent the
>>>> initcwnd10 sysctl under this node.
>>
>> I should also add that I think initcwnd10 should be changed to initcwnd
>> and take the number of segments as a value.
> 
> Yeah, I would suggest the same.
> 
>>
>>>> - We introduce a new net.inet.tcp.nonstandard.allowed sysctl variable
>>>> and default it to 0. Only when it is changed to 1 will we allow starkly
>>>> non standards compliant behaviour to be enabled in the stack. As a more
>>>> complex but expressive alternative, we can make the sysctl take a bit
>>>> mask or CSV string which specifies which non-standard options the sys
>>>> admin permits (I'd prefer this as we can easily test non-standard
>>>> options like IW10 in head without blanket enabling all non standard
>>>> behaviour).
>>
>> To be clear, my proposal is that specifying an allowed option in
>> net.inet.tcp.nonstandard.allowed would not enable it as the default on
>> all connections, but would allow the per-application mechanism we define
>> to set the option. Setting net.inet.tcp.nonstandard.option_x to 1 would
>> enable the option as default for all connections.
>>
>>>> - We introduce a new net.inet.tcp.nonstandard.noidlereset sysctl
>>>> variable, and use it to enable/disable window-reset-after-idle behaviour
>>>> as proposed by John.
>>>>
>>>> - We don't introduce a TF_IGNOREIDLE sockopt, and instead introduce a
>>>> more generic sockopt and/or mechanism for per-application tuning of all
>>>> options which affect stack dynamics (both standard and non-standard
>>>> options). I'm open to suggestions on what this could/should look like.
>>>
>>> Lawrence,
>>>
>>> A route metric?  BTW, as for IW10, it could also become a route metric
>>> (as proposed by the draft author's presentation
>>> http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf)
>>
>> Are you suggesting having the ability to set knobs as route metrics in
>> addition to sysctl and a per-app mechanism? If so then I am very much in
>> favour of this. Assuming an option has been allowed in
>> net.inet.tcp.nonstandard.allowed, it should be able to be set by an
>> application or on a route, perhaps with a precedence hierarchy of app
>> request trumps route metric trumps system default setting?
> 
> I suggest using route metrics in addition to the global sysctls;

Agreed.

> route metrics take precedence over global sysctls. 

Agreed.

> I don't object the per-socket settings though.  However, IMHO, these
> options (IW10 and ignoring idle restart, and probably others) are
> administrative, so applications probably should not mess with them.

Messing with individual options like IW10 on a per-socket basis is
definitely in the "generally should not" basket, but I would not want to
stop an application from doing so subject to the option being specified
by the administrator in the net.inet.tcp.nonstandard.allowed option list.

What I expect applications would want to do more frequently is hint the
socket with a higher level goal e.g. "I want maximum throughput", "I
want low latency", etc. This can come later though. I think we have
enough agreement on the basic infrastructure to move forward at this
point with some patches.

I would initially like to get the basic sysctl infrastructure to support
all this sorted, then look at supporting these options as route metrics,
and finally look at the higher level API.

Anyone else with further input, please speak up!

Cheers,
Lawrence