Summary

  • Nagle's rule allows a first short send when no earlier data is outstanding, then buffers further small writes until an acknowledgment arrives or enough bytes accumulate for a full-sized segment.
  • The rule is separate from receiver delayed acknowledgments and sender Silly Window Syndrome avoidance; TCP standards also require applications to be able to disable it per connection.

Imagine a TCP sender after two keystrokes. The first character has already left in a short segment. Before its acknowledgment returns, the application supplies a second character. The sender's usable window may be open, the path may be healthy, and no retransmission timer may be near expiry. Yet the second character does not necessarily become another packet. The decisive state is much narrower: SND.NXT is greater than SND.UNA, so some transmitted data remains unacknowledged. Under the Nagle algorithm, the new byte waits unless the queue grows large enough to form a full Eff.snd.MSS segment.

That small decision answered a conspicuous problem in the early Internet. RFC 896, published in January 1984, described TCP applications that emitted one character at a time. A byte of useful data could travel with forty bytes of TCP and IP headers. On lightly loaded networks, the inefficiency might merely look untidy. Across heterogeneous, heavily loaded links and gateways, a stream of such packets could consume scarce packet-processing and transmission capacity, compound congestion, and invite loss and retransmission.

Earlier systems often tried to gather characters with a short timer. RFC 896 described delays in the range of 200 to 500 milliseconds, sometimes bypassed for control characters. The weakness was not that every timer was too long or too short. It was that a single time interval could not express the conditions of both a low-delay local network and a congested long-haul path whose round trip might take seconds. A setting that felt responsive in one environment might do little aggregation in another; a setting that reduced packet frequency on the long path could make the local interaction feel sluggish.

The proposed alternative removed the packetization timer from the core decision. If previously transmitted data remained unacknowledged, the sender would hold new user data. It could release that data when an incoming acknowledgment cleared the outstanding flight or when the queued bytes became sufficient for a full-sized segment. If the connection had been idle, there was no outstanding data, so the first new write could go immediately. The mechanism therefore did not impose a fixed pause on every small write. It permitted one short segment per acknowledgment cycle while allowing full segments whenever enough data accumulated.

This is an important distinction because the algorithm is often reduced to the slogan “wait for an ACK.” That is incomplete. An ACK is one release condition; a full segment is another. The first short segment after an idle period is not held behind a predecessor that does not exist. Nor is the rule a message-framing mechanism: TCP still exposes a byte stream, and application write boundaries do not become durable record boundaries merely because several writes are coalesced.

RFC 1122 later placed the idea inside the host requirements. It said that a TCP implementation should implement the Nagle algorithm to coalesce short segments. It also imposed a stronger companion requirement: an application must be able to disable the algorithm for an individual connection. The pairing matters. The standard valued reduced packet multiplication, but it did not make that benefit an irreversible system-wide policy. An application with a communication pattern harmed by waiting behind outstanding data retained authority to opt out for that connection.

The state description in RFC 1122 is direct. When SND.NXT > SND.UNA, the sender has unacknowledged data. It buffers user data, regardless of the PSH bit, until the outstanding data is acknowledged or it can send an Eff.snd.MSS-sized segment. This makes the mechanism adaptive without requiring it to estimate a special aggregation delay. Faster acknowledgment progress can release short writes sooner; slower progress naturally reduces their rate. But the algorithm does not claim that acknowledgment speed measures application urgency, and it does not promise a particular latency.

RFC 9293, the consolidated TCP specification, preserves that structure. A TCP implementation should implement Nagle; an application must be able to disable it per connection; and sending remains constrained by slow start as well. The packetization rule grants no exemption from congestion control. It answers whether another short segment should be formed from queued data, not whether the network has granted unlimited authority to transmit.

The same specification also keeps Nagle separate from Silly Window Syndrome avoidance. Both can reduce small segments, but they respond to different causes. Nagle addresses application data arriving in small increments while earlier bytes remain outstanding. Sender SWS avoidance addresses a receive window whose right edge advances in small increments, leaving only a small usable opening. One watches the relationship between queued writes and the outstanding flight; the other watches how much of the advertised window can usefully be filled. Calling both “small packet fixes” conceals the different state that activates each control.

Nor does Nagle define when the receiver sends an acknowledgment. That belongs to delayed-ACK policy, the subject of a different control surface. RFC 9293 explicitly notes that the two mechanisms can interact poorly. A sender can be waiting for acknowledgment progress before releasing another short write while a receiver is intentionally delaying its acknowledgment in hope of acknowledging more data or combining the ACK with its own traffic. The resulting pause can be real even though each endpoint follows a locally reasonable rule.

That interaction is not a license to rewrite the history as a simple defect story. The standards preserve both mechanisms and acknowledge variations. The defensible conclusion is narrower: composition matters. A sender-side restraint tied to ACK progress and a receiver-side restraint tied to ACK timing can add delay at their boundary. The required per-connection disable control gives applications a way to change one side of that composition when their traffic pattern demands it, but the RFCs do not establish one universal setting for every workload.

Sources