questions about nagle vs. delayed ack

Solution 1:

They are not the same thing but are somehow related and when used together some pitfalls and problems may arise.

Delayed ACK

Delayed ACK can be seen as something implemented on the receiving side. With delayed ACK, ACKs are not sent immediately but delayed for some time (usually 200 ms.) in the hope that the ACK it needs to send can be combined or "piggybacked" with some data the local application wishes to send in the other direction.

A delayed ACK gives the application an opportunity to update the window and perhaps to send an immediate response. In particular, in the case of character-mode remote login, a delayed ACK can reduce the number of segments sent by the server by a factor of 3 (ACK, window update, and echo character all combined in one segment).

In addition, on some large multi-user hosts, a delayed ACK can substantially reduce protocol processing overhead by reducing the total number of packets to be processed. However, excessive delays on ACK's can disturb the round-trip timing and packet "clocking" algorithms. rfc1122

Delayed ACK is used to avoid these kind of situations:

Client              Server
  |                   |
  |----- Request ---->|
  |                   |
  |<------ ACK -------|
  |                   |
  |<---- Response ----|
  |                   |
  |------- ACK ------>|

With delayed ACK TCP will send Request ACK and Response in a single segment.

Client              Server
  |                   |
  |----- Request ---->|
  |                   |
  |<-- Response/ACK---|
  |                   |
  |------- ACK ------>|

John Nagle mentions in this forum

A delayed ACK is a bet that the other end will reply to what you just sent almost immediately. Except for some RPC protocols, this is unlikely. So the ACK delay mechanism loses the bet, over and over, delaying the ACK, waiting for a packet on which the ACK can be piggybacked, not getting it, and then sending the ACK, delayed.

Nagle Algorithm

The Nagle algorithm can be seen as something implemented on the sending side to improve efficiency trying to always send full-sized TCP data packets.

Taken from TCP/IP illustrated (vol. 1): the protocols by W. Richard Stevens

The Nagle algorithm says that when a TCP connection has outstanding data that has not yet been acknowledged, small segments (those smaller than the SMSS) cannot be sent until all outstanding data is acknowledged. Instead, small amounts of data are collected by TCP and sent in a single segment when an acknowledgment arrives. This procedure effectively forces TCP into stop-and-wait behavior, it stops sending until an ACK is received for any outstanding data.

In practical terms, as John Nagle mentions in this forum.

If you turn off the Nagle algorithm and then rapidly send single bytes to a socket, each byte will go out as a separate packet. This can increase traffic by an order of magnitude or two, with throughput declining accordingly.

Delayed ACK and Nagle Algorithm Interaction

Delayed ACK and Nagle algorithm interaction is described in TCP/IP illustrated (vol. 1): the protocols by W. Richard Stevens

Consider a client using delayed ACKs that sends a request to a server, and the server responds with an amount of data that does not quite fit inside a single packet.

Here we see that the client, after receiving two packets from the server, withholds an ACK, hoping that additional data headed toward the server can be piggybacked. Generally, TCP is required to provide an ACK for two received packets only if they are full-size, and they are not here. At the server side, because the Nagle algorithm is operating, no additional packets are permitted to be sent to the client until an ACK is returned because at most one “small” packet is allowed to be outstanding. The combination of delayed ACKs and the Nagle algorithm leads to a form of deadlock (each side waiting for the other).

You can also read about the problems caused by interaction between Nagle’s Algorithm and Delayed ACK in this paper by Stuart Cheshire.