[PATCH] Add a new TCP_IGNOREIDLE socket option

[Lawrence Stewart]

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.

>> - 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?

Cheers,
Lawrence