 Solution

Nagle's algorithm prevents the small-packet problem: an application that writes one or a few bytes at a time could generate a separate TCP TCP segment for each write, with transport/link overhead and router work far larger than the useful data. This is a sender-side cause of the silly window syndrome family of inefficient tiny transmissions.

When no data are outstanding, send the first small TCP segment promptly. While data remain unacknowledged, accumulate further small writes instead of emitting another short TCP segment. Release the accumulated data when either enough are available for a full-sized TCP segment, subject to the allowed send window, or the outstanding data have been acknowledged. This makes the waiting adapt to the round-trip time, rather than imposing one fixed batching interval.^[ref]

The penalty is extra network latency for later small writes. A short application message split across writes may have its second piece delayed awaiting the acknowledgement of the first. If the receiver uses a delayed acknowledgement while its application awaits that second piece, progress can wait for the acknowledgement timer. It is a delay interaction, not a permanent deadlock while that timer works. Latency-sensitive applications can request that Nagle's algorithm be disabled, accepting the possible extra packets. The tradeoff is