The RFC Archive
 The RFC Archive   RFC 17   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 17

Some questions re: Host-IMP Protocol

Last modified on Wednesday, November 15th, 2000

Permanent link to RFC 17
Search GitHub Wiki for RFC 17
Show other RFCs mentioning RFC 17







Network Working Group                                         J. Kreznar
Request for Comments: 17                                             SDC
Category: Informational                                 27 August 1969


                  Some Questions Re: HOST-IMP Protocol

1.  Automatic deletion of links, as indicated in BBN 1822, page 11,
    seems bad:

     a) Link use may be dependent upon human use of a time share
        terminal - indefinite time between messages.

     b) Program using link may be slow due to:

        i)  Busy HOST (many jobs)

        ii) Much local I/O and/or CPU time between messages - is it
            that, if a HOST's user fails to use a link for 15 seconds,
            the HOST network program must generate a dummy message
            merely to keep the link open?

2.  Steve Crocker, HOST Software, 1969 Apr 7, asks on page 2: "Can a
    HOST, as opposed to its IMP, control RFNM's?"  BBN, Report No. 1837,
    1969 Jul, says on page 2: "The principal function of the (IMP)
    program...includes...generating of RFNM's..."  What if an IMP
    generates an RFNM and then discovers it cannot, for some reason,
    complete timely delivery of the last received message to its HOST?
    This seems especially pressing since I don't recall seeing anywhere an
    IMP constraint upon HOSTs that they must accept incoming messages
    within some specified maximum time.

3.  A HOST has to be prepared to repeat transmissions of a message
    into network (see, e.g., Page 17, BBN 1822) therefore why the
            special discardable NOP message (Page 12, BBN 1822).

4.  "Arbitrary delays," middle paragraph, page 23, BBN 1822, seems
    inconsistent with automatic link deletion questioned in 1 above.
    Normally the times involved differ by many orders of magnitude but a
    high priority non-network HOST responsibility could delay next bit for
    a long time.

    1.  Abhi Bhushan, Proj. MAC         10.  Sal Aranda, SDC
    2.  Steve Crocker, UCLA             11.  Jerry Cole,  "
    3.  Ron Stoughton, UCSB             12.  John Kreznar,"
    4.  Elmer Shapiro, SRI              13.  Dick Linde,  "
    5.  Steve Carr, Utah                14.  Bob Long,    "
    6.  John Haefner, RAND              15.  Reg Martin,  "



Kreznar & Kahn                                               PAGE 1 top


RFC 17& 17a Re: HOST-IMP Protocol & Response August 1969 7. Paul Rovner, LL 16. Hal Sackman, " 8. Bob Kahn, BB & N 17. C. Weissman, " 9. Larry Roberts, ARPA [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Marc Blanchett 3/00 ] Kreznar & Kahn PAGE 2 top

RFC 17& 17a Re: HOST-IMP Protocol & Response August 1969 Network Working Group R. Kahn Request for Comments: 17a Bolt Beranek and Newman Inc August 1969 Re: Some Questions Re: HOST-IMP Protocol THE FOLLOWING COMMENTS ARE IN RESPONSE TO JOHN KREZNAR'S QUESTIONS WHICH WERE RAISED IN NWG:- 17 The deletion of a link entry from an IMP's link table will, in general, have no effect upon a Host transmission (or reception) at that IMP's site. Let us distinguish between non-use of a link in- between messages and non-use of a link due to Host program delays in the middle of transmitting or receiving a message. When the Host transmits a message on a link for which an entry is not in the link table, one will simply be inserted there. There is no need for "dummy" Host messages to keep a link "open" since a link is effectively always open. Only if the link table becomes full immediately after an entry is deleted (a situation we do not expect to occur) is there a possibility of resulting delay. Arbitrary delays introduced by Host programs are also not inconsistent with the link entry deletion procedure. A link is blocked when the first access of the link table is made during transmission from the source IMP and is unblocked when the RFNM returns. Only non-blocked transmit link entries are deleted after 30 seconds of disuse. The statement on page 23 referencing arbitrary delays was only intended to have hardware implications insofar as the Host/IMP interface is designed to transfer bits asynchronously between the Host and the IMP. A RFNM is returned from the destination IMP to the source IMP when a message reaches the head of the destination IMP's output queue to the Host (i.e. just before a message is sent to the Host). If a destination IMP cannot then deliver that full message to the Host, at most one more message may possibly arrive at that IMP due to the premature release of the RFNM. The new message will subsequently take its place at the end of the output queue to the Host thus guaranteeing the preservation of the proper message arrival sequence. The NOP message is a special control message which is available for use during initiation of communication between the Host and its IMP. The Host may, of course, decline to send NOP messages during this period, but the first received message after IMP startup or after the Kreznar & Kahn PAGE 3 top

RFC 17& 17a Re: HOST-IMP Protocol & Response August 1969 Host ready indicator has gone on, may be discarded by the IMP. We do not require a Host to be prepared to repeat transmissions into the network. R.E. Kahn BOLT BERANEK AND NEWMAN INC. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Marc Blanchett 3/00 ] Kreznar & Kahn PAGE 4 top

Some questions re: Host-IMP Protocol RFC TOTAL SIZE: 6065 bytes PUBLICATION DATE: Wednesday, November 15th, 2000 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 17: The IETF Trust, Wednesday, November 15th, 2000
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement