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

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

* Stephen Hemminger | 2010-08-23 12:14:49 [-0700]:

>If this is configurable (still not sure about having yet more
>TCP knobs). It should either be per-socket or a route metric so it can
>be controlled on a per-path basis.

Hello Stephen,

I thought about this too. But IMHO it makes no sense because interactive/bulk
characteristic do not depend on the "path". Rather it depends on application
level. Furthermore, how should an administrator configure this on a per path
basis? The administrator knows that he runs a WEB server - great . And then
SHOULD disable Quick ACK and everything is fine, think about typical server
setup.

The only remunerating alternative is to disable TCP quick ACK at all for the
_first_ server ACK. So that the standard delayed ACK is active and therefore
the mechanism can detect if the flow is interactive or not. The drawback is
that for bulk data flows the first ACK is "artificial" delayed. This is the
superior solution IMHO.

Anyway, I think that for most server setup these days (HTTP, SMTP, ...) the
TCP Quick ACK mechanism is contra-productive. Vanilla bulk data transfer
protocols are rarer these days.

Hagen