Subject: [tcpm] Nagle Algorithm and Delayed ACKs

From: Thomas Narten <[email-masked]>
Date: Fri, 24 Jul 2009 15:52:22 -0400

It has been long known that the Nagle Algorithm and Delayed ACKs
combine in ways that can be problematic. Googling around, I found
Stewart Chesire's writeup
(http://www.stuartcheshire.org/papers/NagleDelayedAck/) as well as an
ancient (!) ID from Greg Minshall
(http://lists.w3.org/Archives/Public/ietf-discuss/1998Dec/0025.html)

The TCP_NODELAY socket option can be used to turn off the Nagle
Algorithm, but applications have to know to enable it -- which they
often don't know, until after they've run into problems and traced
them down to the specific problem.  This can be a long and expensive
process (e.g., involve help desk calls).

What is the current thinking on this problem? Am I right in assuming
that:

 - the Nagle Algorithm is still a SHOULD to implement
 - Delayed ACKs are also a SHOULD to implement?
 - Most everyone provides a TCP_NODELAY type socket option?

Is that all there is to it? Is this considered good enough?

Have there not been in any attempts over the last ten years to update
the above recommendations to make them work together better without an
application needing to set the TCP_NODELAY option, in those cases
where it matters?

Thomas

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 24 Jul 2009 22:47:33 +0200

Hi Thomas,

interesting you bring this up...

For SCTP we have the same problem and we therefore submitted
draft-tuexen-tsvwg-sctp-sack-immediately-02.txt
which was presented at the last TSVWG session.

However, the result of the discussion was that the issue
is minor and there was not much interest in the WG to
adopt the ID.

Best regards
Michael

On Jul 24, 2009, at 9:52 PM, Thomas Narten wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 25 Jul 2009 07:17:26 +0200

On Jul 24, 2009, at 21:52, Thomas Narten wrote:

> TCP_NODELAY

My view would be that this is a well-documented option in the socket  
interface.
Even though the interaction with delayed ACKs is rarely explained  
correctly, there are lots of "Socket FAQ" and "Tuning Guide" documents  
that explain "Nagling" (ouch) and the TCP_NODELAY socket option (I get  
117000 google hits...).
TCP_NODELAY certainly is standard fare in any reasonable socket API  
course.
People already need to think about the number of write/send operations  
they perform for one message.
(Note that Linux also has TCP_CORK.)

In essence, the kernel needs to know whether the programmer was not  
considering the issue (making it likely there will be lots of silly  
small writes) or whether the issue was considered and the program is  
optimized with respect to the writes.
A socket option defaulting to the first case sounds like the right way  
to communicate that information, which is hard to infer.

What would you want to improve?

Gruesse, Carsten