Movatterモバイル変換

Network Working Group                                     Wayne HathawayRFC # 512                                                        AMES-67NIC # 16443                                                  25 May 1973MORE ON LOST MESSAGE DETECTIONI would like to second Edwin Meyer's (RFC #492) strong opposition to theproposals made in RFC #467 concerning solutions to the "lost allocate"and "half-closed" phenomena.  In particular I support all of hisprinciples concerning the "half-closed" phenomenon.  I also agree thatthe proposed "lost allocate" solution tends to mask the real problem oflost messages.  I would, however, like to propose the followingalternative scheme for recognizing lost messages.I propose that one of the two unused eight-bit bytes in the level 2message leader be designated the "Sequence Control Byte" (SCB).  ThisSCB would be essentially a modulo 255 message count.  Upon receipt of amessage, the receiving NCP would compare the SCB in the previous themessage with the expected SCB as computed from the SCB in the previousmessage on the same link.  A discrepancy indicates a lost message, whichcould then be reported immediately via an appropriate ERR message.  ThisERR message (to be defined) would contain both received and expectedSCB's, allowing possible recovery of the lost message (if sufficientspace were available in the sending host to save the last severalmessages for each link).  At any rate, the lost message would berecognized immediately, whether it was an ALL (or any control message)or a data message.  The message with the unexpected SCB should beprocessed normally, with the SCB for the next message computed from it.For compatibility, the SCB would be defined such that an SCB of zeroindicates that no checking is to be done.  The SCB following 255 wouldthus be 1.  This would mean that current NCP's would not have to bechanged unless actual checking were desired (since the level 2 protocolspecifies that these two unused bytes must be zero.)  This specialdefinition of zero SCB would also allow RST's and ERR's to bypasschecking, which would be useful in avoiding possible loops.This proposed scheme is similar to the second scheme suggested by JonPostel (RFC #516) except that it is on a per-link basis rather than aper-host basis.  This is significant, however, as it removes therequirement that all messages from one host to another arrive in theorder sent (which cannot be guaranteed).  It also provides forcompatibility with existing NCP's.  Jon's first proposal (save allmessages until RFNM received) is weak in two areas: first, it ispossible that the receiving IMP has sent a RFNM for a message that infact never gets to its host, and second, it requires (at least forswapped systems such as ours) either that messages be saved in residentHathaway                                                        [Page 1]

RFC 512              MORE ON LOST MESSAGE DETECTION             May 1973storage (expensive) or that RFNM's be handled by a swapped process (alsoexpensive).  The third proposal (that of a host-to-host acknowledgmentscheme) is perhaps the best, but as that requires quite major changes tothe level 2 protocol, an interim solution such as that proposed hereseems of value.       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by Alex McKenzie with    ]       [ support from GTE, formerly BBN Corp.             9/99 ]Hathaway                                                        [Page 2]