RFC 534 UNKNOWN ARPANET · RELIABILITY

Lost message detection

The extra message-id bits from RFC 533 can serve as a sequence number for spotting lost messages.

On rfc-editor.org ↗
PUBLISHED
July 1973
AUTHORS
D.C. Walden
STREAM
Legacy
SEQUENCE LENGTH
16 elements
OUTSTANDING MESSAGES PER HOST PAIR
At most four
ELEMENT 0
Sequence numbers not in use
DOI
10.17487/RFC0534

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                       David Walden
Request for Comments: 534                                        BBN-NET
NIC: 17453                                                  17 July 1973
References:  512, 516, 533


                         Lost Message Detection

   As an aside to RFC 533, note that if sending Hosts do uniquely
   identify messages on a given link using the extra four bits and
   receiving Hosts do look at these bits, a lost message detection
   system such as those suggested in RFCs 512 and 516 drops right out of
   using of the unique message-id.  These extra four bits can be treated
   as Hathaway's SCB of RFC 512 providing a 16 element sequence number
   on a per connection basis.  A 16 element sequence is sufficient as
   the IMPs never allow more than four outstanding messages at one time
   between a given pair of Hosts.  As Hathaway also suggests, the 0
   element in the sequence can be used to indicate to the receiving Host
   that sequence numbers are not being used.

   To summarize, there appear to be three modes of using the message-id
   number under Host/Host protocol:

   1. The sender can always set the extra four bits to 0 and only
      transmit one message over a given link at a time -- this is slow
      but it allows orderly retransmission of messages without any help
      from the receiver.

   2. The receiver can give no help to the sender.  In this case it
      doesn't matter whether the sender uses the extra four bits to
      uniquely identify the messages or not -- the sender has no method
      of orderly retransmission, although the sender can accurately
      identify which message was lost if the sender has uniquely
      identified the messages.

   3. The sender can have multiple messages outstanding (i.e., RFNMs not
      received) on a given link and the receiver can help the sender.
      In this case, if the sender uses the extra four bits to uniquely
      identify the messages in a way which can be synchronized with the
      receiver (e.g., sequential id numbers), the receiver can reliably
      detect lost messages.

   Although it probably will seem insufficient to some, if the sender
   and receiver use synchronized unique message-id numbers, very
   reliable retransmission schemes are readily available.  For instance,
   the sender can retransmit the appropriate messages in response to
   incomplete transmissions and the receiver can use the unique
   message-ids to sort the retransmitted messages into the proper order
   with the other received messages.  Alternatively, the receiver can
   discard all messages received out of order and the sender can back up
   and retransmit a message for which an incomplete transmission was
   received and all subsequent messages.


         [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with 10/99 ]

AI ELI5

On this page
PROBLEMHosts want a way to detect lost messages, as proposed in RFC 512 and RFC 516.
MECHANISMThe four extra message-id bits can be treated as a 16 element sequence number per connection, with element 0 meaning that sequence numbers are not in use.
WHY IT MATTERSThe note describes three ways hosts can use the field, and says that with synchronized ids very reliable retransmission schemes are readily available.

§1Message-ID as a Sequence Number

As an aside to RFC 533, if sending Hosts uniquely identify messages on a link with the extra four bits and receiving Hosts look at them, a lost message detection system like those in RFC 512 and RFC 516 drops right out.

The four bits can be treated as Hathaway's SCB of RFC 512, giving a 16 element sequence number per connection. That is enough because the IMPs never allow more than four outstanding messages at one time between a given pair of Hosts. The 0 element can tell the receiver that sequence numbers are not being used.

Number your letters 1, 2, 3 and so on. If the receiver sees 3 after 1, it knows number 2 is missing.

§2Three Modes of Use

The note lists three ways to use the message-id under the Host/Host protocol.

  • The sender always sets the extra four bits to 0 and sends only one message over a link at a time. This is slow, but allows orderly retransmission without help from the receiver.
  • The receiver gives no help. Whether the sender uses the bits or not, it cannot retransmit in an orderly way, though uniquely identified messages let it say which one was lost.
  • The sender has several messages outstanding (RFNMs not yet received) and the receiver helps. If the ids are synchronized, for example sequential, the receiver can reliably detect lost messages.

You can send one letter and wait, send many with no help, or send many while a friend counts them for you.

§3Retransmission Schemes

The author admits the approach may seem insufficient to some, but says that with synchronized unique message-ids very reliable retransmission schemes are readily available.

Two examples are given. The sender can retransmit the appropriate messages after an incomplete transmission, and the receiver can use the ids to sort retransmitted messages into order. Or the receiver can discard all messages that arrive out of order, and the sender can back up and resend the failed message and everything after it.

Either the receiver puts late letters back in order, or it throws out mixed-up ones and the sender starts again from the missing one.

§4References