Version 2 of the Reliable Data Protocol (RDP)
RFC 1151

Document Type RFC - Experimental (April 1990; No errata)
Updates RFC 908
Authors Bob Hinden  , Craig Partridge 
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1151 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      C. Partridge
Request for Comments: 1151                 BBN Systems and Technologies
Updates: RFC 908                                              R. Hinden
                                               BBN Communications Corp.
                                                             April 1990

             Version 2 of the Reliable Data Protocol (RDP)

Status of this Memo

   This RFC suggests several updates to the specification of the
   Reliable Data Protocol (RDP) in RFC-908 based on experience with the
   protocol.  This revised version of the protocol is experimental.

   Distribution of this memo is unlimited.


   Experiments in 1986 and 1987 turned up some ambiguities and problems
   with the RDP specification.  At the time, it was hoped that the
   authors might find the time to revise the entire RDP specification to
   fix these problems, however given the limited demand for RDP
   implementations, the authors were never able to justify the time
   involved in revising the spec.  This document lists the changes that
   we believe are appropriate to make to RDP version 1.

   Readers are expected to be familiar with RFC-908.

Changes To The Protocol Header

   There are three changes to the protocol header: the checksum
   algorithm has been changed, the port size increased, and the version
   number incremented.  The new header format is shown in Figure 1.

   The major discovery during the testing of the protocol is that cost
   of computing the the RDP checksum proved surprisingly variable; its
   performance was more heavily affected by the host's data
   representation than anticipated.  Optimized checksum implementations
   on two comparable hardware bases gave performance that differed by a
   factor of five.  Since the speed of the checksum is a key factor in
   the performance of the protocol itself, this variation caused a
   noticeable difference in throughput.

   The wide variation in performance on comparable machines was felt to
   be undesirable, so the checksum has been changed.  RDP now uses the
   16-bit TCP checksum, which is specified on page 16 of RFC-793.

Partridge & Hinden                                              [Page 1]
RFC 1151                    RDP - Version 2                   April 1990

   The 8-bit port size is probably too small to support a large range of
   applications.  Accordingly, the port size is now 16-bits.  Port
   numbers less than 1024 are reserved for well-defined applications.
   Allocable ports begin at port number 1024.

   Finally, because the checksum and port size have been changed, the
   version number has been increased to 2.

                   0             0 0   1         1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  |S|A|E|R|N| |Ver|    Header     |
                0 |Y|C|A|S|U|0|No.|    Length     |
                  |N|K|K|T|L| |   |               |
                1 |         Source Port           |
                2 |       Destination Port        |
                3 |          Data  Length         |
                4 |                               |
                  +---    Sequence Number      ---+
                5 |                               |
                6 |                               |
                  +--- Acknowledgement Number  ---+
                7 |                               |
                8 |           Checksum            |
                9 |     Variable Header Area      |
                  .                               .
                  .                               .
                  |                               |

                         RDP Header Format
                             Figure 1

Minor Errors and Ambiguities

   Some ambiguities and minor errors have been found in RFC-908.  They
   are corrected in this section.

   The value of the state variable, SND.UNA is treated inconsistently in
   the pseudo-code on pages 21-29.  On page 12, SND.UNA is defined as

Partridge & Hinden                                              [Page 2]
RFC 1151                    RDP - Version 2                   April 1990

   "the sequence number of the oldest unacknowledged segment", and on
   page 21 it is appropriately set to the initial sequence number when
   the connection is opened.  But on page 28, when an acknowledgement is
   received, SND.UNA is set to SEG.ACK, the sequence number being
   acknowledged, instead of SEG.ACK+1.  A similar inconsistency occurs
Show full document text