Re: [PATCH] tcp: make TCP quick ACK behavior modifiable

[Hagen Paul Pfeifer <hagen@jauu.net>]

* Chris Snook | 2010-08-23 17:10:19 [-0400]:

>A year and a half ago, we merged a patch to tune the delayed ack
>behavior.  While the proof of concept was a sysctl interface that a
>relative novice to the TCP code like myself could write, the consensus
>was that we already had a glut of TCP sysctls, and there was a
>potential benefit to doing it on a per-route basis, so we could both
>make the feature more flexible and avoid sysctl pollution by making it
>a per-route tunable.  I think all of the same arguments apply to this
>feature, as well as the argument that it surely makes sense to be
>tuning delayed ack and quick ack in the same place.  I'm CCing acme,
>because he wrote the final patch.

Chris, but I don't support the argument to do this on a per path basis. Why? I
mean it makes sense for RTT, IW and other variables. But quick ack is at
application level and it makes no sense at a per path level. And yes there are
too many sysctl knobs but should we restrict ourself because of this argument?
I mean there are some knobs which are more _special_ then this knob.

The best mechanism is to automatically detect this but it is impossible if the
server had no change to reply. Therefore the idea of disabling the quick ack
mechanism for the _first_ ACK packet, analyze the flow and categorize to bulk
or interactive. But this is another topic and not trivial.

Hagen