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
- Re: draft-cameron-tmux-02.txt Donald E. Eastlake 3rd (Beast)
- draft-cameron-tmux-02.txt David A. Borman
- Re: draft-cameron-tmux-02.txt Dave Crocker
- Re: draft-cameron-tmux-02.txt Pete Cameron
- Re: draft-cameron-tmux-02.txt Donald E. Eastlake 3rd (Beast)
- Re: draft-cameron-tmux-02.txt Pete Cameron
- Re: draft-cameron-tmux-02.txt Donald E. Eastlake 3rd (Beast)
- Re: draft-cameron-tmux-02.txt Pete Cameron
- Re: draft-cameron-tmux-02.txt Donald E. Eastlake 3rd (Beast)
- Re: draft-cameron-tmux-02.txt Pete Cameron
- Re: draft-cameron-tmux-02.txt Donald E. Eastlake 3rd (Beast)