Summary

  • RFC 1692 proposed TMux to combine many small Telnet or Rlogin transport segments bound for the same host into one IP datagram, reducing packet-processing and interrupt work.
  • The same wrapper concealed the inner TCP ports from routers that filtered by port. The RFC told such routers to block TMux or unpack and inspect each segment. RFC 4450 later placed TMux among old Proposed Standards moved to Historic.

A user types one character into a terminal session. The host may spend almost as much effort processing that one-octet packet as it spends on a packet carrying 1,500 octets. That was the provocation in the August 1994 TMux specification: a busy terminal server could generate a storm of tiny packets to one or two hosts while a bandwidth chart looked calm. Count packets per second, the authors said, not just bits.

Peter Cameron, David Crocker, Danny Cohen and Jon Postel proposed putting several short transport segments into one IP datagram for a server-host pair. TMux placed a four-octet mini-header before each segment, recording its length, original protocol and a small checksum. The outer IP packet carried Protocol 18. At the destination, TMux opened the bundle and handed each segment to TCP or UDP as if it had arrived alone. The application did not need to know its packets had shared an envelope.

Bundling took time. When the first segment arrived, a timer began; segments collected before expiry shared the packet. The RFC suggested a configurable 20–30 milliseconds, with roughly a tenth of a second as a likely upper limit because an interactive echo could not wait forever. A full buffer sent immediately. Large segments, such as those above 700 octets, were better left as ordinary datagrams. The economy depended on enough small traffic heading to the same host at the same time. One lonely segment in every bundle bought an extra delay and almost no saving.

The sender also had to know the receiver understood TMux. A valid inbound TMux message could establish that fact. To start the exchange, the RFC offered an empty Protocol 18 enquiry packet, with unanswered enquiries backed off over time. Ordinary datagrams could continue meanwhile. TMux's packing decision could change per direction and over a connection's life; a capability learned yesterday was not an eternal license after a host reboot.

Then came the catch in the security section. A router filtering by TCP port sees the outer Protocol 18 packet, not the inner port numbers. Larger segments from that same TCP connection might travel separately in visible IP/TCP packets and meet a different rule. The RFC's answer was blunt: a port-filtering router that could not understand TMux should refuse TMux traffic in both directions; a router that did understand it could inspect the bundled segments and remove those that failed its filter. The saved packet headers came with a bill for inspection authority.

TMux entered the standards track as a Proposed Standard. A 2004–2005 review of older proposals asked whether implementers would write or maintain them; RFC 4450 listed TMux among the documents moved to Historic. The RFC Editor now records that status. No named bypass incident or universal performance result is in these records. The lesson is more exact: the same wrapper that makes a host process fewer packets can make a router see less of each one.

Sources