[PATCH] Add a new TCP_IGNOREIDLE socket option

[Lawrence Stewart]

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.
>>>
>>> Again I'd like to point out that this sort of modification should
>>> be implemented as a congestion control module.  All the hook points
>>> are already there and can readily be used instead of adding more special
>>> cases to the generic part of TCP.  The CC algorithm can be selected per
>>> socket.  For such a special CC module it'd get a nice fat warning that
>>> it is not suitable for Internet use.
>>
>> As a local hack, sure, a CC module would do the job assuming you were
>> happy to use a single algorithm as the base. John's patch transcends the
>> algorithm in use on a particular connection, so it has wider
>> applicability than a CC module.
> 
> The algorithm is becoming somewhat meaningless when your goal is to
> have an open pipe and push data as fast as possible without regard
> to other traffic.  NewReno, Cubic and what have you is becoming
> meaningless.

But that's not the goal. We're not discussing unbounded or unreactive
congestion windows. If a burst causes drops, we still back off. The
algorithm does still matter.

>> I would also strongly oppose the inclusion of such a module in FreeBSD
>> proper - it's the wrong way to implement the functionality. The patch as
>> posted is technically appropriate, though I'm interested in discussing
>> whether the public API should be tweaked to capture higher level goals
>> instead e.g. "low delay at all costs" or "maximum throughput".
> 
> I strongly disagree.  The patch is a hack. 

I agree it's hacky in its current form, but for different reasons to you
as outlined in my previous email. You are arguing that idle window
resetting is an intrinsic and non negotiable part of TCP. This is
demonstrably not true.

As long as something doesn't change the wire format, then it is fair
game for being tunable. How we make something tunable and what we set as
defaults are where we need to be conservative.

> From the description John gave on his use-case I read that he would actually take more than just
> ignoring idle-cwnd-reset.  And actually if I were in his situation I
> would use a very aggressive congestion control algorithm doing away with
> more than idle-cwnd-reset.

Congestion control is only one aspect of what we're discussing.

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

>>> Additionally I speculate that for the use-case of John he may also be
>>> willing to forgo congestion avoidance and always operate in (ill-named)
>>> "slow start" mode.  With a special CC module this can easily be tweaked.
>>
>> John already has the functionality he needs in this local tree - this
>> discussion is no longer about John per se, but rather about other people
>> who may want the functionality John has implemented.
> 
> That's what I'm worried most about.  So far no real "other people" have
> spoken out, only cheering from the sidelines.

We surely don't need them to speak out explicitly - the use case is not
obscure enough that I am having difficulty imagining other places it
would be useful.

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

Cheers,
Lawrence