RFC 516

Lost Message Detection ✨

okay bestie, this RFC is RFC 516, called "LOST MESSAGE DETECTION" 🎀 It's from the Network Working Group, written by Jonathan B. Postel of UCLA-NMC (NIC # 16683), and it's dated May 18, 1973 📅 The title block doesn't list a category, status, or anything it obsoletes or updates, so there's nothing to flag there 💅

Okay so Jonathan has three suggestions for detecting when the communications subsystem loses a message 😭 The first one is honestly the most powerful AND the simplest, because it uses no new concepts and can even retransmit the message it spots as lost 🔥

The first scheme 🦋

Here's the vibe: when a host sends a message, it saves a copy and then waits until one of these happens:

• A RFNM comes back, so everything is ok and the next message gets processed 💖
• An INCOMPLETE TRANSMISSION comes back, so the copy gets retransmitted. This could turn into a loop, so put a finite upper bound on how many times you retransmit the same message 🔁
• A DESTINATION DEAD comes back, so mark the destination down and require the exchange of reset commands before any further communication is allowed 🙅
• Something else comes back that indicates an error in the network or local IMP, so at least log the error, and probably close the conversation 💀

Following the above procedures, either on a per host basis or a per link basis, should prevent a lost message problem from developing 🌸

The second scheme 🧚

If it's done on a per host basis, message numbers get included in the host to host header of messages, and messages are delivered in order. (That's currently the case in the network, except for priority messages, so this proposal requires that each host either send everything as priority or nothing as priority.) Then each receiving host can detect a missing message by comparing the message number of the received message with the previously received message 👀

• On exchanging resets, the sequence numbers between that pair of hosts is set to zero.
• Each time a message is sent, the current send message number is entered into a field in the message header, and the current send message number is incremented (modulo N, say N=256).
• Each time a message is received, the message number from the message is compared to the current receive message number, and:
  • if the received message is the expected one, then the message is acceptable and the current receive message number is incremented (modulo N);
  • if the received message is not the expected one, then a message has been lost.

What to do when a missing message is detected isn't clear, but at least it can be logged and reported to the network control center 📝 A missing message may not be fatal to an interactive conversation, but it's critical in a file transfer, so Jonathan suggests that missing messages which aren't recovered be cause to close the conversation 🙈

The third scheme 🌈

Host to host acknowledgements could be required. Such an acknowledgement scheme could be implemented similarly to the IMP to IMP scheme. This is a serious change to the current protocols, so he won't elaborate on it here, feeling that deeper study will be necessary to fully specify a reasonable host to host acknowledgement strategy 🧐

Wrap-up 👑

Of these three suggestions, the first is the most immediately practical and implementable. In fact, several hosts already do this 💅 These schemes also don't conflict with each other, so they could be implemented and used simultaneously 🫶

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