TMux to Proposed Standard

Allison J Mankin <mankin@cmf.nrl.navy.mil> Fri, 12 August 1994 21:18 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10932; 12 Aug 94 17:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10928; 12 Aug 94 17:18 EDT
Received: from basil.xylint.co.uk by CNRI.Reston.VA.US id aa17548; 12 Aug 94 17:18 EDT
Received: from radegond.cmf.nrl.navy.mil ([134.207.7.18]) by xylint.co.uk (5.0/SMI-SVR4) id AA03727; Fri, 12 Aug 1994 21:03:25 +0000
Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id QAA15133; Fri, 12 Aug 1994 16:02:45 -0400
Message-Id: <199408122002.QAA15133@radegond.cmf.nrl.navy.mil>
X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol
To: barnes@xylogics.com, cameron@xylint.co.uk, postel@isi.edu, dcrocker@mordor.stanford.edu, cohen@rand.org
Cc: cmp-id@xylint.co.uk
Subject: TMux to Proposed Standard
Date: Fri, 12 Aug 1994 16:02:38 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Allison J Mankin <mankin@cmf.nrl.navy.mil>
content-length: 5761

Jim, Pete, Jon, Dave and Danny,

Congratulations.  TMux was passed as a Proposed Standard
(with its Applicability Statement) by IESG vote yesterday.

You will see the Protocol Action message before Monday.

Best wishes,

Allison Mankin
Transport Area Director

P.S. Preview of the Protocol Action writeup -- 

-----------------------

  The IESG has approved the Internet-Draft "Transport Multiplexing
  Protocol (TMux)" <draft-cameron-tmux-03.txt> as a Proposed Standard.
  This document is not the product of an IETF working group, but has
  been reviewed in the Transport Area of the IETF.  The IESG contact
  person is Allison Mankin.
 
 
Technical Summary

  One of the problems with the use of terminal servers is the large
  number of small packets they can generate.  Frequently, most of
  these packets are destined for only one or two hosts.  The overhead 
  (interrupt and other) for processing a short packet on a host or
  terminal server can be very high, and terminal server vendors have
  found that TCP/IP without a protocol like TMux performs poorly
  compared with some proprietary protocols such as Digital Equipment
  Corporation's LAT.  TMux is a protocol which allows multiple short 
  transport segments, independent of application type, to be combined
  robustly between a server and host pair.
  
  A TMux message appears as:
 
    | IP hdr | TM hdr | Tport segment | TM hdr | Tport segment| ...|
 
  Where:
 
  TM hdr         is a TMux mini-header and specifies the following
                 Tport segment.
 
  Tport segment  refers to the entire transport segment, including
                 transport headers.
 
  Each 4 octet TMux mini-header has the following general format:
 
                     +-------------------------------+
                     |         Length                |
                     |                               |
                     |                               |
                     +-------------------------------+
                     |         Protocol ID           |
                     +-------------------------------+
                     |          Checksum             |
                     +-------------------------------+
                     |      Transport segment        |
                     |       ...                     |
                     |       ...                     |
 
 
  The Protocol ID field contains the value that would normally have
  been placed in the IP header Protocol field.
 
  The 'Checksum' field is the XOR of the first 3 octets.
 
  TMux operates as an extension to the IP datagram protocol.  Hence, it
  has no impact on most flow control mechanisms, since they operate at
  the transport layer -- above TMux.  This was the subject of careful
  review by the Transport Area.
 
  The specification includes details of a dynamic and stateless method
  of turning TMux operation on and off, as well as a timeout for
  accumulating short segments with suggested value supported by
  performance measurements.
 
  TMux is proposed with an Applicability Statement because it is known
  by experiment to be effective in the case of a large terminal server
  in the local area, and it may not be applicable for other environments.
  Implementations are expected to not use TMux for packets of 700 bytes
  or more.  A robust and fast  mechanism is specified for turning the use 
  of TMux on and off dynamically.  The specification recommends also that 
  routers use protocol filtering to not forward TMux traffic (it is IP 
  protocol type 18).  Hosts or servers that send a TMux ENQuiry message
  and do not receive TMux traffic or a TMUX ENQ in reply simply send 
  unmultiplexed transport over IP datagrams.  

  Performance results for this terminal server case were detailed in
  the TMux BOF at the Houston (November '93) IETF meeting.  In its
  applicability environment, TMux is a valuable optimization.

Working Group Summary

  At the Amsterdam IETF, Peter Cameron and Jim Barnes made an
  initial proposal to address the terminal server problem with
  CMP (connection multiplexing protocol), a layer over TCP.  It 
  was found to have architectural and performance faults, and the
  beginnings of the TMux proposal were offered by Dave Crocker.
  Jon Postel and Danny Cohen had made a very similar proposal to
  TMux in IEN 90 in YEAR.  The strong consensus of those attending
  the Amsterdam CMP BOF was that the TMux approach was superior to
  CMP and highly promising.
 
  A TMux BOF was convened at the Houston IETF, to report on the
  refinement of TMux over email and on implementation experiences.
  Performance improvements fulfilling the goals of the proposal were
  reported.  There was strong consensus in the Houston BOF that the
  protocol proposal was valid and should receive a few more
  corrections and then be submitted to the standards track.
 
  The Transport Area Director requested that an Applicability
  Statement be made with the protocol proposal, because of the
  specialized, though sizeable, constituency for a terminal server
  optimization.  There were several rounds of revision of the protocol
  based on review in the Transport Area and the IETF in general.  The
  Last Call on the Internet-Draft of the specification did not generate
  any responses, and there is consensus in the Transport Area
  Directorate that the proposal merits Proposed Standard status.

Protocol Quality

  The protocol specification was extensively reviewed by the Transport
  Area Directorate, including written reviews by Dave Borman and Greg
  Minshall, and by the area director.  Experimental implementations
  were done by two known groups and two vendors are known to have
  completed product-quality implementations.