[PATCH] Add a new TCP_IGNOREIDLE socket option

[Lawrence Stewart]

*crickets chirping*

Time to move this discussion forward...

On 02/14/13 12:36, Lawrence Stewart wrote:
> On 02/14/13 01:48, Andre Oppermann wrote:
>> On 13.02.2013 15:26, Lawrence Stewart wrote:
>>> On 02/13/13 21:27, Andre Oppermann wrote:
>>>> On 13.02.2013 09:25, Lawrence Stewart wrote:
>>>>> The idea is useful. I'd just like to discuss the implementation
>>>>> specifics a little further before recommending whether the patch should
>>>>> go in as is to provide a stop gap, or we rework the patch to be a
>>>>> little
>>>>> less specific in readiness for the future work I have in mind.
[snip]
>>> We could initially map "low delay at all costs" to a TCP stack meaning
>>> of "disable idle window reset" and expand the meaning later (e.g.
>>> relaxing the silly window checks as briefly discussed in the other
>>> thread).
>>
>> Ugh, if you go that far fork it, obtain a fresh protocol number and don't
>> call it TCP anymore.
> 
> You're channelling Joe Touch ;)
> 
> What exactly is TCP? As far as interop is concerned, it's just a wire
> protocol - as long as I format my headers/segments correctly and ignore
> options I don't understand, I can communicate with other TCP stacks,
> many of which implement a different set of TCP features and options.
> 
> The dynamics of the protocol have evolved significantly over time and
> continue to do so because of its ubiquity - it flows freely across the
> public internet and gets used for all manner of things it wasn't
> initially designed to handle (well). A lot of the dynamics are also
> controlled by optional parameters.
> 
> So no, we don't need a new protocol number. We need to provide knobs
> that allow people to tune TCP dynamics to their particular use case.
[snip]
>>> We need to figure out how to provide the functionality in FreeBSD
>>> proper, and a CC module is not the answer.
>>
>> I totally disagree.  This functionality (removal) is not at all a part
>> of TCP and should not be supported directly.
> 
> I don't understand how you can argue that idle window resetting is an
> intrinsic and non negotiable part of TCP. There is no one true set of
> options and features that is TCP. It is not only one idea.
> 
> Let's work on providing a rich set of knobs to tune every aspect of our
> TCP stack's dynamics and operation that don't break wire format, set
> conservative defaults and document everything thoroughly.

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.

- 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).

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

Thoughts?

Cheers,
Lawrence