RFC 1692 (rfc1692) - Page 2 of 12

Transport Multiplexing Protocol (TMux)

RFC 1692                          TMux                       August 1994


   The use of the TMux protocol in any other situation may require some
   modification.

1. Introduction

   When network designers consider which protocols generate the most
   load, they naturally tend to consider protocols which transfer large
   blocks of data (e.g., FTP, NFS).  What is often not considered is the
   load generated by Telnet and Rlogin because of the assumption that
   users type slowly and the packets are very small.  This is a grave
   underestimation of the load on networks and hosts which have many
   Telnet and Rlogin ports on multiple terminal servers.

   The problem stems from the fact that the work a host must do to
   process a 1-octet packet is very nearly as much as the work it must
   do to process a 1500-octet packet.  That is, it is the overhead of
   processing a packet which consumes a host's resources, not the
   processing of the data.

   In particular, communication load is not measured only in bits per
   seconds but also in packets per seconds, and in many situation the
   latter is the true performance limit, not the former.  The proposed
   multiplexing is aimed at alleviating this situation.

   If one assumes that most users connected to a terminal server will be
   connecting to only a few hosts, then it should be obvious that the
   network and host load could be greatly reduced if traffic from
   multiple users, destined for the same host, could be sent in the same
   packet.

   TMux is designed to improve network utilization and reduce the
   interrupt load on hosts which conduct multiple sessions involving
   many short packets.  It does this by multiplexing transport traffic
   onto a single IP datagram [2], thereby resulting in fewer, larger
   packets.  TMux is highly constrained in its method of accomplishing
   this task, seeking simplicity rather than sophistication.

2. Protocol Design

   IP hosts may engage in the use of TMux transparently, and may even
   switch back and forth between use of TMux and carriage of transport
   segments in the usual, independent IP datagrams.

   TMux operates by placing a set of transport segments into the same IP
   datagram.  Each segment is preceded by a TMux mini-header which
   specifies the segment length and the actual segment transport
   protocol.  The receiving host demultiplexes the individual transport
   segments and presents them to the transport layer as if they had been



Cameron, Crocker, Cohen & Postel