Movatterモバイル変換

Network Working Group                                              David WaldenRequest for Comments: 716                                            Joel LevinNIC #35534                                                         May 24, 1976Interim Revision toAppendix F of BBN Report 1822Over the past few months we have become aware that there has beensome confusion as to how to operate a Host connected to an IMP as aVery Distant Host (or VDH).  Therefore, next time BBN Report 1822("Specifications for the Interconnection of a Host and an IMP") isrevised, we will include additional information on how the IMP sideof a VDH connection works and how the Host side may operate mostefficiently.  As an interim measure, we are distributing this RFCwhich takes the form of a (logical) update toAppendix F of BBNReport 1822.On page F-6 onAppendix 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 thefollowing text:In a standard Host to IMP interface, messages are delivered in aspecific order and received in the same order.  A Very Distant Hostinterface operates similarly in that messages are passed, forexample, from the IMP to its RTP in order; the Host's RTP thendelivers them to its receiving process in the same order.  It isimportant to note, however, that between these two softwareinterfaces there is nothing said about ordering.  In particular, ifthe special interface detects an error in a packet, for example,the receiving RTP will discard the packet.  The next packet mayarrive on another logical channel before the sending RTPretransmits the discarded and unacknowledged packet, and thereceiver should be prepared to accept this packet out of order.The protocol described above explicitly permits such out-of-orderbehavior between the RTPs, requiring only that the transmit portionof the RTP fill its channels in sequence (one to channel zero, oneto channel one, one to channel zero, etc.), and that the receiveportion of the RTP empty its channels in sequence.  In addition, toinsure correct sequencing, the first channel filled or emptiedafter initialization must be channel zero.  Null packets useneither a channel nor a channel number when sent and are notacknowledged when received.When packets must be retransmitted until acknowledged, processingand transmission delay may cause acknowledgement to be delayed formore than one transmission time.  Unnecessary retransmission mayinterfere with new transmissions, as well as placing an added                               -1-

burden on both receiver and transmitter.  Therefore, we recommend aprogram delay before deciding to retransmit an unacknowledgedpacket.  This amount of delay should be adjustable, but werecommend a trial value of 100 msec.  Additional efficiency may begained if the RTP can notice that the next packet has beenacknowledged while the previous one has not: in this case, it isclear that the first packet was not correctly received and it maybe retransmitted immediately without waiting for the programmeddelay to expire.  This option has not, however, been implemented inthe IMP at this time.                                -2-