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-