Browse Prior Art Database

Some questions re: Host-IMP Protocol (RFC0017)

IP.com Disclosure Number: IPCOM000004846D
Original Publication Date: 1969-Aug-27
Included in the Prior Art Database: 2001-Jul-11
Document File: 5 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J.E. Kreznar: AUTHOR

Abstract

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

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 61% of the total text.

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]

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]

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