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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinb_tjcz=AF1-2i7MK=Bgm7aEtozjb3Ds0swi8q@mail.gmail.com>
Date:	Mon, 23 Aug 2010 18:19:45 -0400
From:	Chris Snook <chris.snook@...il.com>
To:	Hagen Paul Pfeifer <hagen@...u.net>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
	acme@...hat.com, Stephen Hemminger <shemminger@...tta.com>
Subject: Re: [PATCH] tcp: make TCP quick ACK behavior modifiable

On Mon, Aug 23, 2010 at 6:01 PM, Hagen Paul Pfeifer <hagen@...u.net> wrote:
> * 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.

Just because we've allowed stupid TCP sysctls in the past does not
mean we should continue to do so now.  We recently made delayed ack a
per-route tunable, so consistency would suggest we do the same here.
Per-route tunables are more flexible, and as with the delayed ack
patch, there are use cases where that granularity gives a clear
advantage over a sysctl.  For example, you may want to disable quick
ack on a high-MTU path and enable it on a low-MTU path.

If you need a hint for how to implement the per-route tunable, look
for the delayed ack patch from early 2009.

-- Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html