Lost message detection
Three proposals for detecting messages lost by the network communications subsystem.
Postel, J., "Lost message detection", RFC 516, DOI 10.17487/RFC0516, May 1973, <https://www.rfc-editor.org/info/rfc516>.
@misc{rfc516,
series = {Request for Comments},
number = 516,
howpublished = {RFC 516},
publisher = {RFC Editor},
doi = {10.17487/RFC0516},
url = {https://www.rfc-editor.org/info/rfc516},
author = {J. Postel},
title = {{Lost message detection}},
pagetotal = 2,
year = 1973,
month = may,
} RFC text
Network Working Group Jonathan B. Postel
RFC # 516 UCLA-NMC
NIC # 16683 May 18, 1973
LOST MESSAGE DETECTION
I have three suggestions for detecting the loss of messages by the
communications subsystem. The first of these is perhaps the more
powerful and simpler to implement since it uses no new concepts and has
the power to retransmit the message detected as lost.
The first scheme:
If upon sending a message the host saved a copy of that message and
waited until either:
a RFNM was returned, in which case everything is ok and the next
message is processed.
a INCOMPLETE TRANSMISSION is returned, in which case the copy of
the message is retransmitted (this could be a loop so put a
finite upper bound on the number of times to retransmit the same
message).
a DESTINATION DEAD is returned, in which case mark the
destination down and require the exchange of reset commands
before further communication is allowed.
something else is received indicating an error in the network or
local IMP, in which case 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 on a per host basis, message numbers are included in the host to
host header of messages,, and messages are delivered in order (this
is 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 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, not clear, but at
least can be logged and reported to the network control center. A
missing message may not be fatal to an interactive conversation, but
it is critical in a file transfer, thus I suggest that missing
messages which are not 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 I
will not elaborate on it here, feeling that deeper study will be
necessary to fully specify a reasonable host to host acknowledgement
strategy.
Of these three suggestions the first is the most immediately practical
and implementable; in fact several hosts all ready do this. These
schemes also are non-conflicting, 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 ]
ISO Plain Language
On this page
§1Three Ways to Detect Loss
Jonathan Postel offers three suggestions for detecting messages lost by the communications subsystem. The first uses existing concepts and can retransmit a message when it is reported lost. The RFC says the three schemes do not conflict and could be implemented together.
The memo offers three ways for a host to find out that a message may be missing. They can be considered separately or used together.
- Save and resendKeep a copy until RFNM; retransmit on INCOMPLETE TRANSMISSION.
- Number messagesCompare the received number with the expected number.
- Host acknowledgmentsRequire one host to acknowledge messages from the other.
§1Save a Copy and Retransmit
After sending a message, a host keeps a copy and waits for the network's response. An RFNM means the host can process the next message. An INCOMPLETE TRANSMISSION response causes the host to retransmit its copy, with a finite limit to prevent an endless loop. A DESTINATION DEAD response marks the destination down and requires reset commands before communication continues.
Other responses indicate an error in the network or local IMP. The RFC says the host should at least log the error and probably close the conversation. The procedure can be used per host or per link.
The sender keeps a copy until it receives a response. It can resend after an incomplete transmission, but the RFC says retries need a limit.
§3Message Numbers and Host Acknowledgments
The second scheme adds message numbers to the Host-Host header. A receiver compares each number with the expected value and detects a loss when they differ. The example increments numbers modulo N, with N=256. The memo notes that this approach assumes messages arrive in order and says hosts would need to send either all messages as priority or none as priority.
The third scheme requires acknowledgments from one host to another, similar to the IMP-to-IMP method. The author says this would be a serious change to current protocols and needs further study. If a missing message is not recovered, the memo suggests closing the conversation because loss may be tolerable in an interactive exchange but critical in file transfer.
Message numbers reveal gaps, while acknowledgments let the other host confirm receipt. The memo notes that host acknowledgments would require a major protocol change.