MORE ON LOST MESSAGE DETECTION

I would like to second Edwin Meyer's (RFC #492) strong opposition to the

proposals made in RFC #467 concerning solutions to the "lost allocate"

and "half-closed" phenomena. In particular I support all of his

principles concerning the "half-closed" phenomenon. I also agree that

the proposed "lost allocate" solution tends to mask the real problem of

lost messages. I would, however, like to propose the following

alternative scheme for recognizing lost messages.

I propose that one of the two unused eight-bit bytes in the level 2

message leader be designated the "Sequence Control Byte" (SCB). This

SCB would be essentially a modulo 255 message count. Upon receipt of a

message, the receiving NCP would compare the SCB in the previous the

message with the expected SCB as computed from the SCB in the previous

message on the same link. A discrepancy indicates a lost message, which

could then be reported immediately via an appropriate ERR message. This

ERR message (to be defined) would contain both received and expected

SCB's, allowing possible recovery of the lost message (if sufficient

space were available in the sending host to save the last several

messages for each link). At any rate, the lost message would be

recognized immediately, whether it was an ALL (or any control message)

or a data message. The message with the unexpected SCB should be

processed normally, with the SCB for the next message computed from it.

For compatibility, the SCB would be defined such that an SCB of zero

indicates that no checking is to be done. The SCB following 255 would

thus be 1. This would mean that current NCP's would not have to be

changed unless actual checking were desired (since the level 2 protocol

specifies that these two unused bytes must be zero.) This special

definition of zero SCB would also allow RST's and ERR's to bypass

checking, which would be useful in avoiding possible loops.

This proposed scheme is similar to the second scheme suggested by Jon

Postel (RFC #516) except that it is on a per-link basis rather than a

per-host basis. This is significant, however, as it removes the

requirement that all messages from one host to another arrive in the

order sent (which cannot be guaranteed). It also provides for

compatibility with existing NCP's. Jon's first proposal (save all

messages until RFNM received) is weak in two areas: first, it is

possible that the receiving IMP has sent a RFNM for a message that in

fact never gets to its host, and second, it requires (at least for

swapped systems such as ours) either that messages be saved in resident

---

Page 2

storage (expensive) or that RFNM's be handled by a swapped process (also

expensive). The third proposal (that of a host-to-host acknowledgment

scheme) is perhaps the best, but as that requires quite major changes to

the level 2 protocol, an interim solution such as that proposed here

seems 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 ]

---