Re: [tcpm] Nagle Algorithm and Delayed ACKs

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:

> 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
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>