From: Eric Dumazet <erdnetdev@gmail.com>
To: Rick Jones <rick.jones2@hp.com>
Cc: Cong Wang <amwang@redhat.com>,
David Laight <David.Laight@ACULAB.COM>,
netdev@vger.kernel.org, Ben Greear <greearb@candelatech.com>,
David Miller <davem@davemloft.net>,
Stephen Hemminger <shemminger@vyatta.com>,
Thomas Graf <tgraf@redhat.com>
Subject: Re: TCP delayed ACK heuristic
Date: Wed, 19 Dec 2012 15:08:24 -0800 [thread overview]
Message-ID: <1355958504.21834.1088.camel@edumazet-glaptop> (raw)
In-Reply-To: <50D209E9.2000504@hp.com>
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
prev parent reply other threads:[~2012-12-19 23:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <270756364.27707018.1355842632348.JavaMail.root@redhat.com>
2012-12-18 15:11 ` TCP delayed ACK heuristic Cong Wang
2012-12-18 16:30 ` Eric Dumazet
2012-12-19 6:54 ` Cong Wang
2012-12-18 16:39 ` David Laight
2012-12-18 17:54 ` Rick Jones
2012-12-19 9:52 ` David Laight
2012-12-19 7:00 ` Cong Wang
2012-12-19 18:39 ` Rick Jones
2012-12-19 20:59 ` David Miller
2012-12-20 3:23 ` Cong Wang
2012-12-20 9:57 ` David Laight
2012-12-20 12:41 ` Cong Wang
2012-12-19 23:08 ` Eric Dumazet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1355958504.21834.1088.camel@edumazet-glaptop \
--to=erdnetdev@gmail.com \
--cc=David.Laight@ACULAB.COM \
--cc=amwang@redhat.com \
--cc=davem@davemloft.net \
--cc=greearb@candelatech.com \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
--cc=shemminger@vyatta.com \
--cc=tgraf@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox