tmux bof minutes

Jim Barnes <barnes@xylogics.com> Fri, 19 November 1993 20:04 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11193; 19 Nov 93 15:04 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11189; 19 Nov 93 15:04 EST
Received: from basil.xylint.co.uk by CNRI.Reston.VA.US id aa27466; 19 Nov 93 15:04 EST
Received: from atlas.xylogics.com by basil.xylint.co.uk (4.1/SMI-4.1) id AA00141; Fri, 19 Nov 93 19:28:09 GMT
Received: from spock.xylogics.com by atlas.xylogics.com with SMTP id AA10282 (5.65c/UK-2.1-930726); Fri, 19 Nov 1993 14:33:29 -0500
Received: by spock.xylogics.com id AA20832 (4.1/UK-2.1-921215); Fri, 19 Nov 93 14:28:03 EST
Message-Id: <20832.9311191928@spock.xylogics.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Jim Barnes <barnes@xylogics.com>
Date: Fri, 19 Nov 1993 14:28:02 -0500
X-Mailer: Mail User's Shell (7.1.0 4/25/90)
To: cmp-id@xylint.co.uk
Subject: tmux bof minutes

Reported by Jim Barnes/Xylogics

Minutes of the TMux BOF (tmux)

Agenda

  Introduction
  How we got here
  TMux Overview and implementation experience
  Issues from the mailing list
  What now?


Peter Cameron presented a short overview of the TMux protocol.  He
then gave a summary of the implementation experiences to date.  TMux
has been implemented in Unix System V.4 streams and BSD 4.3 systems.
The total number of implementations to date is six.  Peter noted that
since the interface between the IP and TCP layers is not well defined,
implementing a portable TMux module can be difficult.  A problem with
FTP traffic was also noted when there was a single FTP session.  The
implementations of TMux now do not attempt to multiplex FTP traffic.
Only Telnet and Rlogin data is multiplexed now.

The results from some performance tests simulating multiple Telnet sessions
were then given.  The following discussion resulted in requests for
additional performance information including perceived response times
for TMux vs. non-TMux situations.  Peter Cameron took the action item
to send additional performance numbers to the mailing list.

After the prepared presentation, a general discussion followed.  The
following were the significant points raised:

  - Since we want to prevent intermediate nodes from fragmenting
	and reconstructing TMux frames, the "do not fragment" flag
	should be set.

  - The document needs to include an applicability statement.

  - If the TMux implementation begins to see timeouts with exactly
	one datagram in the packet (that is, there is little traffic
	to multiplex), TMux should be turned off.

  - A packet with the IP OPTIONS field is not a candidate for multiplexing
	with TMux.

  - Check the test implementations to make sure everything that was
	done to overcome an implementation problem is reflected in the
	draft document.

After that, discussion moved on to consider specific points raised
on the mailing list.

  - Length field: The consensus is that the length field should be 16 bits.

  - Checksums: After considerable discussion, no real consensus was
	reached, so the checksum field will stay in.

A lengthy message from Don Eastlake was posted to the mailing list
just before the BOF.  The issues raised and the consensus reached during
the BOF were as follows:

  - The document is too terminal server centric.

	The consensus of the BOF attendees was that TMux was a simple
	solution for a very specific problem.  The problem definition
	should remain tightly focussed.

  - Type of Service concerns:

	TMux should ensure that all datagrams within the multiplexed
	packet have the same TOS.

  - Broadcast packets

	Only unicast addresses should be allowed.

  - Larger limit on the maximum size of TMux datagrams

	The maximum size of 30 will be replaced with information gained
	during implementation.  This max datagram size probably should
	be configurable.

  - Use TMux only in congested situations

	Agreed.

  - The section on security needs clarification

	Agreed.


The attendees were asked if there were any blocking issues that would
prevent TMux from being put on the standards track.  No one raised any
such issue and the consensus was that TMux could be recommended to the
IESG for further action.