= 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.<RFC 896>[The small-packet problem and the proposed unacknowledged-data rule]{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
$$
\boxed{\text{fewer tiny segments, at the cost of waiting to coalesce subsequent small writes}.}
$$
Back to article page
