1

2
3
4
5
6
7 Network Working Group J. Kreznar
8 Request for Comments: 17 SDC
9 Category: Informational 27 August 1969
10
11
12 Some Questions Re: HOST-IMP Protocol
13
14 1. Automatic deletion of links, as indicated in BBN 1822, page 11,
15 seems bad:
16
17 a) Link use may be dependent upon human use of a time share
18 terminal - indefinite time between messages.
19
20 b) Program using link may be slow due to:
21
22 i) Busy HOST (many jobs)
23
24 ii) Much local I/O and/or CPU time between messages - is it
25 that, if a HOST's user fails to use a link for 15 seconds,
26 the HOST network program must generate a dummy message
27 merely to keep the link open?
28
29 2. Steve Crocker, HOST Software, 1969 Apr 7, asks on page 2: "Can a
30 HOST, as opposed to its IMP, control RFNM's?" BBN, Report No. 1837,
31 1969 Jul, says on page 2: "The principal function of the (IMP)
32 program...includes...generating of RFNM's..." What if an IMP
33 generates an RFNM and then discovers it cannot, for some reason,
34 complete timely delivery of the last received message to its HOST?
35 This seems especially pressing since I don't recall seeing anywhere an
36 IMP constraint upon HOSTs that they must accept incoming messages
37 within some specified maximum time.
38
39 3. A HOST has to be prepared to repeat transmissions of a message
40 into network (see, e.g., Page 17, BBN 1822) therefore why the
41 special discardable NOP message (Page 12, BBN 1822).
42
43 4. "Arbitrary delays," middle paragraph, page 23, BBN 1822, seems
44 inconsistent with automatic link deletion questioned in 1 above.
45 Normally the times involved differ by many orders of magnitude but a
46 high priority non-network HOST responsibility could delay next bit for
47 a long time.
48
49 1. Abhi Bhushan, Proj. MAC 10. Sal Aranda, SDC
50 2. Steve Crocker, UCLA 11. Jerry Cole, "
51 3. Ron Stoughton, UCSB 12. John Kreznar,"
52 4. Elmer Shapiro, SRI 13. Dick Linde, "
53 5. Steve Carr, Utah 14. Bob Long, "
54 6. John Haefner, RAND 15. Reg Martin, "
55
56
57
58 Kreznar & Kahn [Page 1]
59 FF
60 RFC 17& 17a Re: HOST-IMP Protocol & Response August 1969
61
62
63 7. Paul Rovner, LL 16. Hal Sackman, "
64 8. Bob Kahn, BB & N 17. C. Weissman, "
65 9. Larry Roberts, ARPA
66
67 [ This RFC was put into machine readable form for entry ]
68 [ into the online RFC archives by Marc Blanchett 3/00 ]
69
 70
71
72
73
74
75
76
77
78
79
80
81
82
83
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
112
113
114 Kreznar & Kahn [Page 2]
115 FF
116 RFC 17& 17a Re: HOST-IMP Protocol & Response August 1969
117
118
119 Network Working Group R. Kahn
120 Request for Comments: 17a Bolt Beranek and Newman Inc
121 August 1969
122
123
124 Re: Some Questions Re: HOST-IMP Protocol
125
126 THE FOLLOWING COMMENTS ARE IN RESPONSE TO JOHN KREZNAR'S QUESTIONS
127 WHICH WERE RAISED IN NWG:- 17
128
129 The deletion of a link entry from an IMP's link table will, in
130 general, have no effect upon a Host transmission (or reception) at
131 that IMP's site. Let us distinguish between non-use of a link in-
132 between messages and non-use of a link due to Host program delays in
133 the middle of transmitting or receiving a message. When the Host
134 transmits a message on a link for which an entry is not in the link
135 table, one will simply be inserted there. There is no need for
136 "dummy" Host messages to keep a link "open" since a link is
137 effectively always open. Only if the link table becomes full
138 immediately after an entry is deleted (a situation we do not expect
139 to occur) is there a possibility of resulting delay.
140
141 Arbitrary delays introduced by Host programs are also not
142 inconsistent with the link entry deletion procedure. A link is
143 blocked when the first access of the link table is made during
144 transmission from the source IMP and is unblocked when the RFNM
145 returns. Only non-blocked transmit link entries are deleted after 30
146 seconds of disuse. The statement on page 23 referencing arbitrary
147 delays was only intended to have hardware implications insofar as the
148 Host/IMP interface is designed to transfer bits asynchronously
149 between the Host and the IMP.
150
151 A RFNM is returned from the destination IMP to the source IMP when a
152 message reaches the head of the destination IMP's output queue to the
153 Host (i.e. just before a message is sent to the Host). If a
154 destination IMP cannot then deliver that full message to the Host, at
155 most one more message may possibly arrive at that IMP due to the
156 premature release of the RFNM. The new message will subsequently
157 take its place at the end of the output queue to the Host thus
158 guaranteeing the preservation of the proper message arrival sequence.
159
160 The NOP message is a special control message which is available for
161 use during initiation of communication between the Host and its IMP.
162 The Host may, of course, decline to send NOP messages during this
163 period, but the first received message after IMP startup or after the
164
165
166
167
168
169
170 Kreznar & Kahn [Page 3]
171 FF
172 RFC 17& 17a Re: HOST-IMP Protocol & Response August 1969
173
174
175 Host ready indicator has gone on, may be discarded by the IMP. We do
176 not require a Host to be prepared to repeat transmissions into the
177 network.
178
179 R.E. Kahn
180 BOLT BERANEK AND NEWMAN INC.
181
182
183 [ This RFC was put into machine readable form for entry ]
184 [ into the online RFC archives by Marc Blanchett 3/00 ]
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226 Kreznar & Kahn [Page 4]
227 FF
228