draft-cameron-tmux-01.txt

"Beast (Donald E. Eastlake 3rd)" <beast@world.std.com> Mon, 01 November 1993 08:30 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27755; 1 Nov 93 3:30 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27751; 1 Nov 93 3:30 EST
Received: from basil.xylint.co.uk by CNRI.Reston.VA.US id aa24405; 1 Nov 93 3:30 EST
Received: from world.std.com by basil.xylint.co.uk (4.1/SMI-4.1) id AA00600; Mon, 1 Nov 93 08:06:34 GMT
Received: from localhost by world.std.com (5.65c/Spike-2.0) id AA21373; Mon, 1 Nov 1993 03:08:12 -0500
Message-Id: <199311010808.AA21373@world.std.com>
To: cmp-id@xylint.co.uk
Cc: beast@world.std.com
Subject: draft-cameron-tmux-01.txt
Date: Mon, 01 Nov 1993 03:08:11 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Beast (Donald E. Eastlake 3rd)" <beast@world.std.com>

First of all, I think this is a great idea.

My comments:
	This draft is much too terminal server exclusive.  That may be
the most important initial use of Tmux but it seems to me that there
are lots of cases of frequent traffic between hosts that could be
accumulated.  For example, messages between IRC servers.
	The protocol is only applicable if the datagrams to be grouped
have the same TOS (Type of Service) and the combined Tmux packet must
have the TOS of the combined datagrams.
	The document should point out that this technique is
applicable to broadcast packets as well.  It just matters that the
destination addresses and TOS be the same and the combined packets fit
into the MTU.
	I was happy to see the change from 00.txt to allow longer Tmux
packets.
	A lot of other things in the draft just seem too specific.
For example, a host might just want to sent a Tmux ENQ back right away
when it received one to avoid any question of whether it happened to
have any Tmux'able traffic sitting around if it wanted to Tmux.
	The references to "the" Multiplexed Message under contruction"
seem odd.  There could be many (e.g., an IRC server that talked to two
or three other IRC servers might have enough traffice for each of them
to justify Tmux'ing.  Conceivably on some systems, you could patch
together packets sitting in your Ethernet or whatever output queue on
the fly and Tmux more as things get more backed up (probably not a
good idea in general but another conceivable strategy).  I also don't
see where this "30 octet" suggested limit comes from.  Even with an
MTU of 500 octets, it might make sense to Tmux things up to 100 octets
and even more for a larger MTU.
	Under Security Considerations, Tmux isn't a TCP port number,
its an IP protocol.  I think the paragraph should be re-written to
spell out the results of the three primary choices (let Tmux through:
no security for small datagrams that are Tmux'ed; block Tmux: hosts
will think it not implemented and not use it; understand Tmux:
efficiency of traffic with security).

Donald

*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-
 Donald E. Eastlake, III     1-508-486-6577(w)     beast@world.std.com
 PO Box N, MIT Branch PO                           dee@skidrow.lkg.dec.com
 Cambridge, MA 02139 USA     1-508-287-4877(h)