1 files changed, 115 insertions, 0 deletions
diff --git a/doc/rfc/rfc516.txt b/doc/rfc/rfc516.txt
new file mode 100644
index 0000000..336081d
--- /dev/null
+++ b/doc/rfc/rfc516.txt
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+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]
+
+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]
+