Connected: An Internet Encyclopedia
RFC 1122 - 4.2.3.2 When to Send an ACK Segment

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1122
Up: 4. TRANSPORT PROTOCOLS
Up: 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP
Up: 4.2.3 SPECIFIC ISSUES
Prev: 4.2.3.1 Retransmission Timeout Calculation
Next: 4.2.3.3 When to Send a Window Update

### 4.2.3.2 When to Send an ACK Segment

A host that is receiving a stream of TCP data segments can increase efficiency in both the Internet and the hosts by sending fewer than one ACK (acknowledgment) segment per data segment received; this is known as a "delayed ACK" [TCP:5].

A TCP SHOULD implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment.

DISCUSSION:

  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 [TCP:5]. However, excessive delays on ACK's can disturb the round-trip timing and packet "clocking" algorithms [TCP:7].

Next: 4.2.3.3 When to Send a Window Update

Connected: An Internet Encyclopedia
RFC 1122 - 4.2.3.2 When to Send an ACK Segment