Protocol experiment
RFC 700

Document Type RFC - Informational (August 1974; No errata)
Last updated 2016-04-08
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 700 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
NWG/RFC 700                                                  August 1974
NIC 31020
INWG Experiments Note 1

                   A Protocol Experiment

                       Eric R. Mader
                     William W. Plummer
                    Raymond S. Tomlinson

I.  Introduction

In early February, 1974 the main line  printer  on  BBN's  TENEX  system
failed and it was decided to use the PDP-11 line printer via the ARPANET
both for the direct purpose of obtaining listings and also the  indirect
purpose of studying network protocols.

II.  The Basic Protocol

The design was based on the protocol described by Cerf and Kahn in  INWG
Note  #39.  Familiarity with that document is assumed.  The following is
a brief sketch of the protocol.  Not  all  features  described  in  this
section have been implemented.  See Section VI.

At any instant, the sender has two pointers into the stream of bytes  to
be  sent.   Bytes to the left of the LEFT pointer have already been sent
and acknowledged.  Bytes in the "window"  between  the  LEFT  and  RIGHT
pointers  have  been  sent  (zero  or  more times), but no indication of
successful transmission has been received.  Bytes to the right of  RIGHT
remain to be considered at some time in the future.

In operation the sender is constantly sending bytes from the input  data
stream   resulting   in   the   RIGHT   pointer   advancing.    Positive
acknowledgements produced by the receiver cause the  LEFT  edge  of  the
window to move towards the RIGHT edge.

LEFT and RIGHT are actually numerical byte  positions  within  the  data
stream.   The low order 16 bits of RIGHT are sent with each message as a
sequence number so that the receiver can identify which part of the data
stream  it  is  receiving  in case messages are not received in the same
order they were transmitted.  The receiver has a finite amount of buffer
space  available  in which it can reassemble an image of the data in the
transmitter's window.  The receiver discards  any  messages  which  have
sequence  numbers  outside of its buffer area.  However, messages to the
left of LEFT must  be  acknowledged  even  though  they  are  discarded.
Otherwise,  a  lost  ACK  would  cause the sender to retransmit (and the
receiver ingore) the message indefinitely.  Messages received  with  bad
checksums are also discarded.

As "good" messages are received, the holes are filled in the  receiver's
buffer  and  continuous  segments  at  the  left  edge are passed to the
physical line printer (in our case).  The receiver informs the sender of


                                                    Page   2

this  action  by sending an ACK (acknowledgement) message.  This message
specifies the sequence number of the byte it would like to receive  next
(the  new  value of LEFT in the sender) and the current amount of buffer
space it has available (new maximum window width in  the  sender).   The
sender  ignores  ACK's  to  the  left of LEFT and to the right of RIGHT.
Thus, both the sender and  receiver  are  prepared  to  handle  multiple
copies of messages.

Failures such as messages  with  bad  checksums,  messages  lost  during
transmission  (data  and ACK's), and messages discarded due to sequences
numbers which were apparently out of range, all manifest  themselves  to
the sender as a dropped ACK.  A dropped ACK will cause the sender's LEFT
edge to stop advancing, leaving the unacknowledged message at  the  left
of the sender's window, and possibly a corresponding hole at the left of
the receiver's image of the window.  Eventually, transmission will cease
and   a  (10  second)  timeout  will  trigger  in  the  sender,  causing
retransmission of all data within the window.  Note that at the  instant
of  a  timeout,  there is no guarantee that the un-ACK'd message will be
exactly at the  left  edge  of  the  window  or  that  it  is  the  only
unacknowledged  message  in  the  window.  Retransmissions are likely to
cause the receiver to see data that it has seen  before,  but  duplicate
messages will be discarded due to sequence number considerations.

III.  "Say Again"

An extension to the INWN #39 protocol  which  was  implemented  was  the
ability to let the receiver force retransmission of the entire window by
turning on a flag in any message back to the sender.  This is useful  in
cases  where  the receiver believes that a data message has been dropped
and it wants to force retransmission rather than wait for a  timeout  in
the sender.  Clearly, this relies on the network to preserve ordering of
the messages.  Also, it is not useful if the error rate is high  because
the  whole  window  is retransmitted in order to get retransmission of a
single message or two.

IV.  Establishing an Association

In the experiment two flags were used to establish an association.  FRST
(FiRST  flag)  was  the equivalent of SYN described in INWG Note #39 and
served to identify the first message of an association.  This instructed
Show full document text