Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!ames!ucbcad!ucbvax!CS.UCL.AC.UK!Steve.Kille
From: Steve.Kille@CS.UCL.AC.UK.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: GOSIP vs TCP/IP
Message-ID: <3476.544130860@UK.AC.UCL.CS>
Date: Mon, 30-Mar-87 14:59:22 EST
Article-I.D.: UK.3476.544130860
Posted: Mon Mar 30 14:59:22 1987
Date-Received: Wed, 1-Apr-87 01:27:12 EST
References: <[A.ISI.EDU]15-Mar-87.01:04:54.CERF>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 34
Approved: tcp-ip@sri-nic.arpa



 >From:  CERF@edu.isi.a
 >Subject: Re: GOSIP vs TCP/IP
 >Date:  15 Mar 1987 01:04-EST

 >Please ask Steve what he does about X.25 resets in the absence of
 >an end/end reliable protocol such as TCP or TP4?

Well, I'm the wrong Steve, but will comment anyhow!    The TCP
Implementor's conference has made it very clear to me that the X.25
oriented solutions are very poorly understood in the TCP/IP
community.

There are two basic ways of handling resets.   The first is at
the application level, and will certainly be done by those
applications which need to handle large quantities of data, and
do not wish to incur the cost of retransmission.  This can be
done by use of CCR (Comit Concurrency + Recovery) for FTAM and
JTM (Job Transfer and Manipulation).  For X.400, the RTS
(Reliable Transfer Service) resumption mechanisms can be used.

In many cases, these will be sufficient, and so a very
lightweight transport (viz TP0) is sensible to make best
utilisation of the X.25.   However, for some applications (e.g.
Terminal Access) it would be very desirable to have resumption
over the same transport connection.  Therfore, TP1 (viz error
recovery class) is a sensible choice.

There is absolutely no need for the heavyweight overkill of TP4.
X.25 will keep data in sequence, and prevent data corruption.


Steve