The RFC Archive
 The RFC Archive   RFC 516   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 516

Lost message detection

Last modified on Thursday, March 9th, 2000

Permanent link to RFC 516
Search GitHub Wiki for RFC 516
Show other RFCs mentioning RFC 516







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



Postel                                                       PAGE 1 top


RFC 516 LOST MESSAGE DETECTION May 1973 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 ] Postel PAGE 2 top

Lost message detection RFC TOTAL SIZE: 4086 bytes PUBLICATION DATE: Thursday, March 9th, 2000 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 516: The IETF Trust, Thursday, March 9th, 2000
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement