From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: TCP delayed ACK heuristic Date: Wed, 19 Dec 2012 15:08:24 -0800 Message-ID: <1355958504.21834.1088.camel@edumazet-glaptop> References: <270756364.27707018.1355842632348.JavaMail.root@redhat.com> <2088500005.27728019.1355843484620.JavaMail.root@redhat.com> <1355900436.6665.16.camel@cr0> <50D209E9.2000504@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Cong Wang , David Laight , netdev@vger.kernel.org, Ben Greear , David Miller , Stephen Hemminger , Thomas Graf To: Rick Jones Return-path: Received: from mail-pb0-f47.google.com ([209.85.160.47]:51962 "EHLO mail-pb0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751926Ab2LSXI1 (ORCPT ); Wed, 19 Dec 2012 18:08:27 -0500 Received: by mail-pb0-f47.google.com with SMTP id un1so1529707pbc.20 for ; Wed, 19 Dec 2012 15:08:27 -0800 (PST) In-Reply-To: <50D209E9.2000504@hp.com> Sender: netdev-owner@vger.kernel.org List-ID: 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