netdev - Re: TCP delayed ACK heuristic

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:	Wed, 19 Dec 2012 15:08:24 -0800
From:	Eric Dumazet <erdnetdev@...il.com>
To:	Rick Jones <rick.jones2@...com>
Cc:	Cong Wang <amwang@...hat.com>,
	David Laight <David.Laight@...LAB.COM>, netdev@...r.kernel.org,
	Ben Greear <greearb@...delatech.com>,
	David Miller <davem@...emloft.net>,
	Stephen Hemminger <shemminger@...tta.com>,
	Thomas Graf <tgraf@...hat.com>
Subject: Re: TCP delayed ACK heuristic

On Wed, 2012-12-19 at 10:39 -0800, Rick Jones wrote:
> On 12/18/2012 11:00 PM, Cong Wang wrote:
> > On Tue, 2012-12-18 at 16:39 +0000, David Laight wrote:
> >> There are problems with only implementing the acks
> >> specified by RFC1122.
> >
> > Yeah, the problem is if we can violate this RFC for getting better
> > performance. Or it is just a no-no?
> >
> > Although RFC 2525 mentions this as "Stretch ACK Violation", I am still
> > not sure if that means we can violate RFC1122 legally.
> 
> The term used in RFC1122 is "SHOULD" not "MUST."  Same for RFC2525 when 
> it talks about "Stretch ACK Violation."   A TCP stack may have behaviour 
> which differs from a SHOULD so long as there is a reasonable reason for it.

Generally speaking, there are no reasonable reasons, unless you control
both sender and receiver, and the path between.

ACK can be incredibly useful to recover from losses in a short time.

The vast majority of TCP sessions are small lived, and we send one ACK
per received segment anyway at beginning [1] or retransmits to let the
sender smoothly increase its cwnd, so an auto-tuning facility wont help
them that much.

For long and fast sessions, we have the LRO/GRO heuristic.

This leaves a fraction of flows where the ACK rate should not really
matter.


[1] This refers to the quickack mode



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