The small-packet problem

There is a special problem associated with small packets. When TCP is used for the transmission of single-character messages originating at a keyboard, the typical result is that 41 byte packets (one byte of data, 40 bytes of header) are transmitted for each byte of useful data. This 4000% overhead is annoying but tolerable on lightly loaded networks. On heavily loaded networks, however, the congestion resulting from this overhead can result in lost datagrams and retransmissions, as well as excessive propagation time caused by congestion in switching nodes and gateways. In practice, throughput may drop so low that TCP connections are aborted.

This classic problem is well-known and was first addressed in the Tymnet network in the late 1960s. The solution used there was to impose a limit on the count of datagrams generated per unit time. This limit was enforced by delaying transmission of small packets until a short (200-500ms) time had elapsed, in hope that another character or two would become available for addition to the same packet before the timer ran out. An additional feature to enhance user acceptability was to inhibit the time delay when a control character, such as a carriage return, was received.

This technique has been used in NCP Telnet, X.25 PADs, and TCP Telnet. It has the advantage of being well-understood, and is not too difficult to implement. Its flaw is that it is hard to come up with a time limit that will satisfy everyone. A time limit short enough to provide highly responsive service over a 10M bits per second Ethernet will be too short to prevent congestion collapse over a heavily loaded net with a five second round-trip time; and conversely, a time limit long enough to handle the heavily loaded net will produce frustrated users on the Ethernet.

• The solution to the small-packet problem