home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 200s / rfc210.txt < prev    next >
Text File  |  1997-06-23  |  3KB  |  113 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Request for Comments # 210                                     W. Conrad
  8. Categories  C.4                                                  Harvard
  9. NIC 7189                                                    16 August 71
  10.  
  11.                       Improvement of Flow Control
  12.  
  13. The current "give back" - "return" scheme seems to put the cart before
  14. the horse in that the "return" command indicates the amount of space
  15. the sending host is returning rather than the amount of space it has
  16. left after decrementing by the amount specified in the "give back"
  17. command.  Considering the fact that allocation counters at sending and
  18. receiving hosts may get out of synchronization and the fact that the
  19. receiving host has a preemptive priority in the allocation of its
  20. resources, it is only logical that the receiving host be able to find
  21. out exactly how much of its buffer space a sending host thinks it can
  22. claim.
  23.  
  24. If the "return" command is to accurately reflect a sending host's
  25. current allocation, and if successive "give backs" are to produce
  26. "return" commands which can be properly interpreted, certain race
  27. conditions must be avoided. A "give back" must be answered by a
  28. "return" and no more "give backs" can be issued until that "return" is
  29. received.  In some sense, a "return" command as here proposed is
  30. really a give back reply, and, perhaps, should implemented under that
  31. name. On the sending side, the "return" command must not be issued as
  32. long as a data RFNM is awaited on the link to which the "return"
  33. refers. As soon as the net is clear of data messages, the "return" may
  34. be sent and data transmission may continue when the RFNM for this
  35. message containing the "return" command is received.
  36.  
  37. The current "give back" command uses fractions and has a format
  38. different from the "allocate" and "return" commands making processing
  39. unnecessarily complicated. By adopting the convention that allocations
  40. can not be decremented below zero, one can safely specify absolute
  41. decrements in a format like that of the "allocate" command. If the
  42. receiving host's estimate of a suitable decrement is inaccurate, no
  43. harm is done and the "return" command in response to the "give back"
  44. provides immediate corrective information.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. SUMMARY
  61.  
  62.           Proposal                       Advantage
  63.  
  64. 1    "Return" specifies amount       Provides more pertinent
  65.      of space left after             information and a means
  66.      decrementing.                   of resynchronization other
  67.                                      than closing connection.
  68.  
  69. 2    "Give Back" must get            Provide more accurate
  70.      "return" in reply and           allocation information
  71.      "return" must not be            by eliminating race
  72.      sent with data on the           conditions.
  73.      link.
  74.  
  75. 3    Eliminate fractions             Eliminate messy math
  76.      from "give back".               and provide symmetry
  77.                                      to allocation commands
  78.                                      making processing easier.
  79.  
  80.  
  81.  
  82.        [ This RFC was put into machine readable form for entry ]
  83.         [ into the online RFC archives by Gunnar Reichert 6/97 ]
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113.