RFC 17

Some questions re: Host-IMP Protocol

📅 published August 1969, from ietf

RFC 17: Some Questions Re: HOST-IMP Protocol 💖

  • Group: Network Working Group
  • Written by: J. Kreznar, SDC
  • Category: Informational
  • Date: 27 August 1969
  • Obsoletes / Updates: none listed in this block
  • Companion: RFC 17a, a reply by R. Kahn of Bolt Beranek and Newman Inc (August 1969), which answers these questions

okay bestie, so this is John Kreznar at SDC in 1969 asking the HOST-IMP crew some very pointed questions. the energy is giving careful, respectful curiosity with a side of "wait, explain this to me" 🎀

okay so the BBN 1822 spec (page 11) says links get automatically deleted, and John is like, ummm, that seems kinda bad ngl 💀

  • a) Link use may depend on a human typing at a time share terminal, which means there could be an indefinite amount of time between messages.
  • b) A program using the link may be slow because:
    • i) the HOST is busy with lots of jobs
    • ii) there's a ton of local I/O and/or CPU time between messages. So is it that if a HOST's user doesn't use a link for 15 seconds, the HOST network program has to generate a dummy message just to keep the link open? 😭

2. Who controls RFNMs? 👑

Steve Crocker (HOST Software, 1969 Apr 7) asks on page 2: "Can a HOST, as opposed to its IMP, control RFNM's?" 🤔 Then BBN, Report No. 1837 (1969 Jul), says on page 2: "The principal function of the (IMP) program...includes...generating of RFNM's..."

So what if an IMP generates an RFNM and then realizes it can't, for some reason, finish timely delivery of the last received message to its HOST? 🫠 John says this feels especially pressing, because he doesn't recall seeing anywhere an IMP constraint saying HOSTs have to accept incoming messages within some specified maximum time.

3. Repeat transmissions and the NOP 🍓

A HOST has to be prepared to repeat transmissions of a message into the network (see, e.g., Page 17, BBN 1822), so, therefore, why the special discardable NOP message (Page 12, BBN 1822)? 🧐 It's a fair question, honestly.

4. Arbitrary delays 🧚

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

And here's the whole squad that worked on it 🫶

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

RFC 17a: Re: Some Questions Re: HOST-IMP Protocol 🦋

  • Written by: R. Kahn, Bolt Beranek and Newman Inc
  • Date: August 1969
  • Replying to: RFC 17 (John Kreznar's questions, raised in NWG)

okay so here's Bob Kahn at BBN answering John's questions, and the tea is actually really good ☕✨

Deleting a link entry from an IMP's link table will, in general, have no effect on a Host transmission (or reception) at that IMP's site. 💅 Let's split it into two cases: non-use of a link in between messages, and non-use of a link because of Host program delays in the middle of transmitting or receiving a message. When the Host transmits a message on a link that doesn't have an entry in the link table, one will simply be inserted there. No need for "dummy" Host messages to keep a link "open," since a link is effectively always open 🔓 The only way there's a possibility of delay is if the link table becomes full right after an entry is deleted, and that's a situation they don't expect to happen.

Arbitrary delays introduced by Host programs also aren't 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 it's unblocked when the RFNM returns. Only non-blocked transmit link entries are deleted after 30 seconds of disuse ⏱️ The statement on page 23 about arbitrary delays was only meant 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 can't deliver that full message to the Host at that point, at most one more message may possibly arrive at that IMP because the RFNM was released early 😬 The new message will then take its place at the end of the output queue to the Host, which guarantees the proper message arrival sequence is preserved 🌈

The NOP message is a special control message that's 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 Host ready indicator has gone on, may be discarded by the IMP. And we don't 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 ]
📦 where this page comes from