    Network Working Group                                              David Walden
    Request for Comments: 716                                            Joel Levin
    NIC #35534                                                         May 24, 1976

           Interim Revision to Appendix F of BBN Report 1822

    Over the past few months we have become aware that there has been
    some confusion as to how to operate a Host connected to an IMP as a
    Very Distant Host (or VDH).  Therefore, next time BBN Report 1822
    ("Specifications for the Interconnection of a Host and an IMP") is
    revised, we will include additional information on how the IMP side
    of a VDH connection works and how the Host side may operate most
    efficiently.  As an interim measure, we are distributing this RFC
    which takes the form of a (logical) update to Appendix F of BBN
    Report 1822.

    On page F-6 on Appendix F, delete the second footnote.

    On page F-7, find the phrase "... and the odd/even bit is complemented."
    on line 17 of the page.  Delete the rest of the page and insert the
    following text:

    In a standard Host to IMP interface, messages are delivered in a
    specific order and received in the same order.  A Very Distant Host
    interface operates similarly in that messages are passed, for
    example, from the IMP to its RTP in order; the Host's RTP then
    delivers them to its receiving process in the same order.  It is
    important to note, however, that between these two software
    interfaces there is nothing said about ordering.  In particular, if
    the special interface detects an error in a packet, for example,
    the receiving RTP will discard the packet.  The next packet may
    arrive on another logical channel before the sending RTP
    retransmits the discarded and unacknowledged packet, and the
    receiver should be prepared to accept this packet out of order.
    The protocol described above explicitly permits such out-of-order
    behavior between the RTPs, requiring only that the transmit portion
    of the RTP fill its channels in sequence (one to channel zero, one
    to channel one, one to channel zero, etc.), and that the receive
    portion of the RTP empty its channels in sequence.  In addition, to
    insure correct sequencing, the first channel filled or emptied
    after initialization must be channel zero.  Null packets use
    neither a channel nor a channel number when sent and are not
    acknowledged when received.

    When packets must be retransmitted until acknowledged, processing
    and transmission delay may cause acknowledgement to be delayed for
    more than one transmission time.  Unnecessary retransmission may
    interfere with new transmissions, as well as placing an added

                                   -1-

    burden on both receiver and transmitter.  Therefore, we recommend a
    program delay before deciding to retransmit an unacknowledged
    packet.  This amount of delay should be adjustable, but we
    recommend a trial value of 100 msec.  Additional efficiency may be
    gained if the RTP can notice that the next packet has been
    acknowledged while the previous one has not: in this case, it is
    clear that the first packet was not correctly received and it may
    be retransmitted immediately without waiting for the programmed
    delay to expire.  This option has not, however, been implemented in
    the IMP at this time.

                                    -2-