- 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]
-
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]
-