RFC 512

MORE ON LOST MESSAGE DETECTION 💖

okay so this is RFC 512 🎀 from the Network Working Group, written by Wayne Hathaway (AMES-67) on 25 May 1973, with NIC # 16443. It doesn't list any category, and it doesn't obsolete or update anything. 🦋

I'm seconding Edwin Meyer's (RFC #492) strong opposition to the proposals in RFC #467 for handling the "lost allocate" and "half-closed" phenomena 💅 I'm especially backing all of his principles about the "half-closed" phenomenon. I also agree that the proposed "lost allocate" solution kinda hides the real problem of lost messages 🙈 So I'd like to pitch a different way to spot lost messages ✨

Here's my idea: one of the two unused eight-bit bytes in the level 2 message leader becomes the "Sequence Control Byte" (SCB) 🧚 Basically, the SCB is a modulo 255 message count. When a message arrives, the receiving NCP compares the SCB in the message that just arrived with the expected SCB, which is computed from the SCB in the previous message on the same link. If they don't match, that means a message got lost 😭 The NCP can report it right away with an appropriate ERR message. That ERR message (still to be defined) would hold both the received and the expected SCBs, which could help recover the lost message, as long as the sending host has enough room to save the last several messages for each link 💜 Either way, the lost message gets recognized immediately, whether it was an ALL (or any control message) or a data message 🔥 The message with the unexpected SCB still gets processed normally, and the SCB for the next message is computed from it.

For compatibility, an SCB of zero means no checking is to be done. The SCB after 255 is therefore 1. This means current NCPs don't have to change unless they actually want checking, since the level 2 protocol specifies that these two unused bytes must be zero. ✨ This special zero SCB also lets RSTs and ERRs skip checking, which is useful for avoiding possible loops 🌈

This scheme is kinda similar to the second idea from Jon Postel (RFC #516), except it's per-link instead of per-host 👑 That difference matters, because it removes the requirement that all messages from one host to another arrive in the order they were sent (which can't be guaranteed) 💅 It also stays compatible with existing NCPs. Jon's first proposal (save all messages until RFNM received) is weak in two areas. First, the receiving IMP might have sent an RFNM for a message that never actually reaches its host 😭 Second, it requires either saving messages in resident storage (expensive) or handling RFNMs with a swapped process (also expensive), at least for swapped systems like ours 🙈 The third proposal, a host-to-host acknowledgment scheme, is probably the best. But since it needs quite major changes to the level 2 protocol, an interim fix like this one feels valuable 🫶

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