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.
