RFC 65 (rfc65) - Page 2 of 2

Comments on Host/Host Protocol document #1

RFC 65               Comments on Host-Host Protocol          August 1970


   bits to the right of the link in the leader.  The IMP must preserve
   these bits and return them with RFNMs and the receiver must use the
   pseudo link instead of the link in RET and INR.  The extra memory
   necessary to store the pseudo link in the NCP receive tables (which
   are indexed by link) and the link in the NCP send tables (which are
   indexed by pseudo link) is certainly less than the overhead necessary
   to maintain associative tables.

   Page 8.   The allocate mechanism seems very inconvenient for the
   receive portion of the NCP to use.  The receiver wants the allocation
   to be used up in units of the receiver's buffer size not in units of
   sender messages which may be variable length.  Otherwise the receiver
   has a memory compaction problem.

   Page 9.   The new irregular message to make the "cease" mechanism
   work are unnecessary, I think.  The sender can keep track (probably
   with a one bit counter) of ALLs and GVBs and ignore GVB 0s for which
   resume ALLs have already arrived.   This the receiver need not know
   whether the cease has been sent or not.

   Page 15.  If I implemented an NCP, all ERRs would be treated like
   NOP.  As an error control mechanism ERR is complicated and
   insufficient.  Who wants to debug a complicated mechanism which only
   catches bugs due to the primary mechanism being undebugged.  The one
   error control mechanism I would provide is a receive process to send
   process acknowledgment on every message.  If this is not received for
   too long, the send process can send the message again if it has been
   saving it.  This acknowledgment catches errors causing message loss
   at the process/NCP, NCP/NCP, Host/IMP, IMP/IMP, etc.  levels.
   Currently the Host/IMP interface is particularly lacking in useful
   error controls.  I wouldn't worry about kinds of errors check-sums
   are designed to pick up.  If dropped and picked up bits ever become a
   problem either add hardware to more interfaces or let the receive
   process not send the process to process acknowledgment if a software
   checksum does not check.

   The page 3 and page 6 comments involve a change to the IMP program.
   I feel a tiny bit guilty suggesting changes I don't have to implement
   any more.  However, I trust Crowther and Cosell will, as always,
   resist bad changes while making sensible ones.  The page 9 comment is
   aimed at avoiding a change in the IMP program.


         [ This RFC was put into machine readable form for entry ]
           [ into the online RFC archives by Luke Hollins 8/99]






Walden