From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc210.txt | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)
 create mode 100644 doc/rfc/rfc210.txt

(limited to 'doc/rfc/rfc210.txt')

diff --git a/doc/rfc/rfc210.txt b/doc/rfc/rfc210.txt
new file mode 100644
index 0000000..dc641bd
--- /dev/null
+++ b/doc/rfc/rfc210.txt
@@ -0,0 +1,112 @@
+
+
+
+
+
+
+Request for Comments # 210                                     W. Conrad
+Categories  C.4                                                  Harvard
+NIC 7189                                                    16 August 71
+
+                      Improvement of Flow Control
+
+The current "give back" - "return" scheme seems to put the cart before
+the horse in that the "return" command indicates the amount of space
+the sending host is returning rather than the amount of space it has
+left after decrementing by the amount specified in the "give back"
+command.  Considering the fact that allocation counters at sending and
+receiving hosts may get out of synchronization and the fact that the
+receiving host has a preemptive priority in the allocation of its
+resources, it is only logical that the receiving host be able to find
+out exactly how much of its buffer space a sending host thinks it can
+claim.
+
+If the "return" command is to accurately reflect a sending host's
+current allocation, and if successive "give backs" are to produce
+"return" commands which can be properly interpreted, certain race
+conditions must be avoided. A "give back" must be answered by a
+"return" and no more "give backs" can be issued until that "return" is
+received.  In some sense, a "return" command as here proposed is
+really a give back reply, and, perhaps, should implemented under that
+name. On the sending side, the "return" command must not be issued as
+long as a data RFNM is awaited on the link to which the "return"
+refers. As soon as the net is clear of data messages, the "return" may
+be sent and data transmission may continue when the RFNM for this
+message containing the "return" command is received.
+
+The current "give back" command uses fractions and has a format
+different from the "allocate" and "return" commands making processing
+unnecessarily complicated. By adopting the convention that allocations
+can not be decremented below zero, one can safely specify absolute
+decrements in a format like that of the "allocate" command. If the
+receiving host's estimate of a suitable decrement is inaccurate, no
+harm is done and the "return" command in response to the "give back"
+provides immediate corrective information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+SUMMARY
+
+          Proposal                       Advantage
+
+1    "Return" specifies amount       Provides more pertinent
+     of space left after             information and a means
+     decrementing.                   of resynchronization other
+                                     than closing connection.
+
+2    "Give Back" must get            Provide more accurate
+     "return" in reply and           allocation information
+     "return" must not be            by eliminating race
+     sent with data on the           conditions.
+     link.
+
+3    Eliminate fractions             Eliminate messy math
+     from "give back".               and provide symmetry
+                                     to allocation commands
+                                     making processing easier.
+
+
+
+       [ This RFC was put into machine readable form for entry ]
+        [ into the online RFC archives by Gunnar Reichert 6/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+
-- 
cgit v1.2.3