Re: draft-cameron-tmux-02.txt

Pete Cameron <cameron@xylint.co.uk> Tue, 08 February 1994 15:36 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07880; 8 Feb 94 10:36 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07876; 8 Feb 94 10:36 EST
Received: from basil.xylint.co.uk by CNRI.Reston.VA.US id aa08522; 8 Feb 94 10:36 EST
Received: by basil.xylint.co.uk (4.1/SMI-4.1) id AA23390; Tue, 8 Feb 94 14:58:22 GMT
Date: Tue, 08 Feb 1994 14:58:22 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Pete Cameron <cameron@xylint.co.uk>
Message-Id: <9402081458.AA23390@basil.xylint.co.uk>
To: dee@skidrow.lkg.dec.com
Subject: Re: draft-cameron-tmux-02.txt
Cc: cmp-id@xylint.co.uk

---------  Received message begins Here  ---------

> From: "Donald E. Eastlake 3rd (Beast)" <dee@skidrow.lkg.dec.com>

Donald,

Thanks for commenting again.

> I'm not completely certain, but I think that a system capable of
> operation with less state is simpler.  No matter what you do,
> since tmux is not part of the basic required IP protocol, you need
> to keep some state about the remote system.  But with ENQ/RSP
> you don't need to remember if you sent an ENQ.

The ENQ gets ENQ response is marked as a non recomended
option in the document. If you follow the recomended option,
then you have it even easier, as you don't have to remember
that you sent an ENQ, or look for RSPs, as ENQs are a
trivial case of normal packet reception.

> I've always thought that the tmux concept was very elegant and general
> and should apply to all IP traffic.  I mean it just groups packets for
> efficiency.  At a high level, why should it matter a bit what kind
> of packets they are?

The consensus of opinion at the Houston BOF was that the
document should be made very specific to terminal servers,
hence the direction I am taking. Also, it matters a LOT what
kind of packets are passed from the higher level to TMux. We
tried some experiments with ftp to see what would happen. If
we allow ftp packets to be multiplexed, then for a single
ftp session we got a 15% degradation in performance. We
consider this unacceptable for something that is designed to
increase performance. Having said this, I still agree to a
degree with your sentiments, TMux is applicable to all IP
trafic, but must be used with care.

> It seems to me that you might want to be able to configure a host to
> the opposite assumption, i.e., that all other hosts are tmux capable
> unless you get a ICMP error back in which case you add it to your list
> of non-tmux capable hosts and time out that list with some long
> time-out.  This might be appropriate for a terminal server.  Note:
> this eliminates the need for any ENQ and/or RSP!

Our first attempt at implementing TMux used exactly this
idea.  Unfortunately the BSD TCP/IP (as used by many hosts)
does not send ICMP errors for unknown protocols.  This is
because all unknown IP protocols are passed upto the RAW
protocol driver where they fall into a black hole :-(

> Or, hosts could generate occasional ENQ and/or RSP packets if they
> think they would otherwise time out.

Yep, I will add that to the document.

Thanks

Pete Cameron                                            tel: +44 908 222112
Consulting Engineer                                     fax: +44 908 222115
Xylogics International Limited                  email: cameron@xylint.co.uk
Featherstone Rd, Wolverton Mill, MK12 5RD, UK.         cameron@xylogics.com