Revision history [back]

RFC 1122 Section 4.2.3.2, states "in a stream of full-sized segments there SHOULD be an ACK for at least every second segment. As you probably are aware, per the Delayed Ack algorithm, most TCP implementations send an ACK for every two or three full-sized segments. It seeks to limit the number of ACKs because, among other things, they can cause excessive interrupts on the sender. In cases where the latency introduced by this method reduces throughput to unacceptable levels, the delayed ACK period can be reduced.

Most implementations immediately ACK segments with the PSH bit set. The PSH bit essentially indicates "I've got no more data to send right now." This may cause the receiver to immediately ACK that segment regardless of the Delayed ACK period, and immediately transfer the data to the upper layer protocol; however, at least some implementations provide an option to ignore PSH bits.

Nagle is designed to coalesce short segments. If there is unACKed data, the sender buffers all outgoing data on a given TCP connection regardless of the PSH bit until all outstanding data has been ACKed or the sender can transmit a full-sized segment. In some environments where short segments are the norm, Nagle can be disabled if it results in poor performance. Nagle can be especially harmful with data streaming applications.

Here are some possible explanations for the behavior you mentioned: o The Delayed ACK timer has been reduced or set to zero. o The sender is setting the PSH bit in every segment and the receiver ACKs every PSH bit segment.
o The receiver's TCP provides an option ACK every segment regardless of its size, PSH bit, or Delayed ACK timer.

If performance is unacceptable, I would check the capture to see if every segment has the PSH bit set. If so, the receiver TCP might have an option to ignore them. If Nagle is disabled on the sender, it could be enabled. If the Delayed ACK period has been set to a very low value on the receiver, it could be increased. Of course, these measures should be tested individually and depending on the behavior seen in a capture, tested in prescribed combinations.

RFC 1122 Section 4.2.3.2, states "in a stream of full-sized segments there SHOULD be an ACK for at least every second segment. As you probably are aware, per the Delayed Ack algorithm, most TCP implementations send an ACK for every two or three full-sized segments. It seeks to limit the number of ACKs because, among other things, they can cause excessive interrupts on the sender. In cases where the latency introduced by this method reduces throughput to unacceptable levels, the delayed ACK period can be reduced.

Most implementations immediately ACK segments with the PSH bit set. The PSH bit essentially indicates "I've got no more data to send right now." This may cause the receiver to immediately ACK that segment regardless of the Delayed ACK period, and immediately transfer the data to the upper layer protocol; however, at least some implementations provide an option to ignore PSH bits.

Nagle is designed to coalesce short segments. If there is unACKed data, the sender buffers all outgoing data on a given TCP connection regardless of the PSH bit until all outstanding data has been ACKed or the sender can transmit a full-sized segment. In some environments where short segments are the norm, Nagle can be disabled if it results in poor performance. Nagle can be especially harmful with data streaming applications.

Here are some possible explanations for the behavior you mentioned: mentioned:

o The Delayed ACK timer has been reduced or set to zero. zero.

o The sender is setting the PSH bit in every segment and the receiver ACKs every PSH bit segment.

o The receiver's TCP provides an option to ACK every segment regardless of its segment size, PSH bit, bit, or Delayed ACK timer.

If performance is unacceptable, I would check the capture to see if every segment has the PSH bit set. If so, the receiver TCP might have an option to ignore them. If Nagle is disabled on the sender, it could be enabled. If the Delayed ACK period has been set to a very low value on the receiver, it could be increased. Of course, these measures should be tested individually and depending on the behavior seen in a capture, the captures, tested in prescribed combinations.

RFC 1122 Section 4.2.3.2, states "in a stream of full-sized segments there SHOULD be an ACK for at least every second segment. segment." As you probably are aware, per the Delayed Ack algorithm, most TCP implementations send an ACK for every two or three full-sized segments. It seeks to limit the number of ACKs because, among other things, they can cause excessive interrupts on the sender. In cases where the latency introduced by this method reduces throughput to unacceptable levels, the delayed ACK period can be reduced.

Most implementations immediately ACK segments with the PSH bit set. The PSH bit essentially indicates "I've got no more data to send right now." This may cause the receiver to immediately ACK that segment regardless of the Delayed ACK period, and immediately transfer the data to the upper layer protocol; however, at least some implementations provide an option to ignore PSH bits.

Nagle is designed to coalesce short segments. If there is unACKed data, the sender buffers all outgoing data on a given TCP connection regardless of the PSH bit until all outstanding data has been ACKed or the sender can transmit a full-sized segment. In some environments where short segments are the norm, Nagle can be disabled if it results in poor performance. Nagle can be especially harmful with data streaming applications.

Here are some possible explanations for the behavior you mentioned:

o The Delayed ACK timer has been reduced or set to zero.

o The sender is setting the PSH bit in every segment and the receiver ACKs every PSH bit segment.

o The receiver's TCP provides an option to ACK every segment regardless of segment size, PSH bit, or Delayed ACK timer.

If performance is unacceptable, I would check the capture to see if every segment has the PSH bit set. If so, the receiver TCP might have an option to ignore them. If Nagle is disabled on the sender, it could be enabled. If the Delayed ACK period has been set to a very low value on the receiver, it could be increased. Of course, these measures should be tested individually and depending on the behavior seen in the captures, tested in prescribed combinations.