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]

Date:	Tue, 24 Aug 2010 00:01:29 +0200
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Chris Snook <chris.snook@...il.com>
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

* 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

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