Reliable Asynchronous Transfer Protocol (RATP)
RFC 916

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                            G. Finn
Request for Comments: 916                                            ISI
                                                            October 1984

             RELIABLE ASYNCHRONOUS TRANSFER PROTOCOL (RATP)

Status of This Memo

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

   This paper proposes and specifies a protocol which allows two
   programs to reliably communicate over a communication link.  It
   ensures that the data entering one end of the link if received
   arrives at the other end intact and unaltered.  The protocol, named
   RATP, is designed to operate over a full duplex point-to-point
   connection.  It contains some features which tailor it to the RS-232
   links now in common use.

Introduction

   We are witnessing today an explosive growth in the small or personal
   computer market.  Such inexpensive computers are not normally
   connected to a computer network.  They are most likely stand-alone
   devices.  But virtually all of them have an RS-232 interface.  They
   also usually have a modem.  This allows them to communicate over the
   telephone with any other similarly equipped computer.

   The telephone system is a pervasive network, but one of the
   characteristics of the telephone system is the unpredictable quality
   of the circuit.  The standard telephone circuit is designed for voice
   communication and not data communication.  Voice communication
   tolerates a much higher degree of 'noise' than does a data circuit,
   so a voice circuit is tolerant of a much higher level of noise than
   is a data circuit.  Thus it is not uncommon for a byte of data
   transferred over a telephone circuit to have noise inserted.  For the
   same reason it is also not uncommon to have spurious data bytes added
   to the data stream.

   The need for a method of reliably transferring data over an RS-232
   point-to-point link has become severe.  As the number of powerful
   personal computers grows, the need for them to communicate with one
   another grows as well.  The new markets and new services that these
   computers will eventually allow their users to access will rely
   heavily upon the telephone system.  Services like electronic mail,
   electronic banking, ordering merchandise from home with a personal
   computer, etc.  As the information revolution proceeds data itself
   will become a commodity.  All require accuracy of the data sent or
   received.

Finn                                                            [Page 1]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol

1. Philosopy of Design

   Many tradeoffs were made in designing this protocol.  Decisions were
   made by above all ensuring reliability and then by favoring
   simplicity of implementation.  It is hoped that this protocol is
   simple enough to be implemented not only by small computers but also
   by stand alone devices incorporating microcomputers which accept
   commands over RS-232 lines.  Sophisticated but unnecessary features
   such as dynamic window management [TCP 81] were left out for
   simplicity's sake.  Having several packets outstanding at a time was
   eliminated for the same reason, and data queued to send when a
   connection is closed remotely is discarded.  This eliminates two
   states from the protocol implementation.

   The reader may ask why define this protocol at all, there are after
   all already RS-232 transport protocols in use.  This is true but some
   lack one or more features vitally important or are too complex.  See
   Appendix II for a brief survey.

      - A protocol which can only transfer data in one direction is
        unable to use a single RS-232 link for a full-duplex connection.
        As such it cannot act as a bridge between most computer
        networks.  Also it is not capable of supporting any applications
        requiring the two-way exchange of data.  In particular it is not
        a platform suitable for the creation of most higher level
        applications.  Unidirectional flow of data is sufficient for a
        weak implementation of file transfer but insufficient for remote
        terminal service, transaction oriented processing, etc.

      - Some of the existing RS-232 transport protocols allow the use of
        only fixed size packets or do not allow the receiver to place a
        limit on the sender's packets.  Where that block size is too
        large for the receiving end concentrator, that concentrator is
        likely to immediately invoke flow control.  This results in many
        dropped and damaged packets.  The receiver must be able to
        inform the sender at connection initiation what is the maximum
        packet size it is prepared to receive.