1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
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
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
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
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
|
Network Working Group V. Cerf
Request for Comments: 388 UCLA-NMC
Obsoletes: 323 23 August 1972
NIC: 11360
Network Measurement Note #8
NCP Statistics
After a lapse of 5 months since RFC #323 was issued (23 March), I am
pleased to announce that UCLA-NMC is prepared to gather your NCP
statistics automatically on a daily basis. The results will be
published monthly as Network Measurement notes and as RFC's. We will
periodically open a connection on your local socket @241 (decimal),
expecting you to send the following data in the format shown:
<duplicate pages 3-5 of RFC 323 here>
a. Total bits sent to HOST
b. Total bits received from HOST
c. Total messages sent to HOST
d. Total messages received from HOST and optionally
e. Average Round Trip delay on send connections to HOST
The information above should be collected only for standard open
connections (i.e. those using standard NCP protocol) and not
measurement links or experimental NCP links, and in particular, not
traffic on link 0).
Another optional measurement would be to gather the distribution of
message types over link 0 over all HOSTS (i.e. not broken down by
HOST). This will reveal the relative utilization of control messages
(ALLOC should be very prevalent).
The data collected for the last 24 hour sample period should be
available from a process listening on local socket number 241 (10).
Cerf [Page 1]
^L
RFC 388 NCP Statistics August 1972
16 16
+----------+------------+
word 0 | Day # | Time |
+----------+------------+
| |
1 - 365 (6 on leap year) |______
|
Time in minutes at which sample was
started. Ranges from 0 (midnight) to 1439.
8 8
+--------+------+-------+----------+
word 1 | Source | Byte | N | Format |
| Host | Size | | |
+--------+------+-------+----------+
| | | |__________
_______| | | |
| | number of HOST |
Network Host | related entries +---+---+---+---+---+---+
number | in message | | | C | R | B | M |
| +---+---+---+---+---+---+
number of bits per | | | |
byte in byte statistics ____ ____| | | message
| ___| | statistics
| | byte
control | statistics
message distribution |
average
round-trip time
Cerf [Page 2]
^L
RFC 388 NCP Statistics August 1972
The remaining words of the message depend on Format byte setting:
<-------32--------->
/ +---------------------+
| | Foreign HOST # | always present
|-+---------------------+
| | messages received | if FORMAT bit M set
| +---------------------+
| | Bytes received | if FORMAT bit B set
N of | +---------------------+
these | | message sent | if FORMAT bit M set
entries | +---------------------+
| | Bytes sent | if FORMAT bit B set
| +---------------------+
\ | Average delay | if FORMAT bit R set
+---------------------+
This is average RFNM
delay in milliseconds
8 24
+-------+---------------+
| type | Count | if FORMAT bit C set these
+-------+---------------+ are link 0 control message
| | | distributions for the
+-------+---------------+ sample period, cumulative
| | | overall HOSTs. If a type is
+-------+---------------+ not present, its count is
| | | assumed to be 0.
+-------+---------------+
| | |
+-------+---------------+
| | |
+-------+---------------+
| . | |
.
.
|type | Count |
+-------+---------------+
Cerf [Page 3]
^L
RFC 388 NCP Statistics August 1972
Thus, the data you send will look roughly like this.
+--------------------------------+
word 0 | DAY/TIME |
+--------------------------------+
word 1 | CONTROL WORD |
+--------------------------------+
| DATA FOR |
| DESTINATION |
| 1 |
+--------------------------------+
| DATA FOR |
| DESTINATION |
| 2 |
+--------------------------------+
.
.
.
+--------------------------------+
| DATA FOR |
| DESTINATION |
| N |
+--------------------------------+
| CONTROL MESSAGE |
. DISTRIBUTION |
. |
. |
| |
word n +--------------------------------+
On completion of transmission of the last message, and after you
receive the RFNM for this last message, close the connection.
In the original specification, we said that the data gathering
program would ICP to some well-known socket. We believe this to be
an unnecessary complication and instead, we will merely open a
connection on your 241 (decimal), expecting you to send data as soon
as our Allocate command is received by your NCP. Please let me know
if this cannot be done (i.e. you need the ICP).
If you connect to UCLA-NMC socket 241, we will send you our own 24
hour data. Anyone interested in capturing these statistics is
welcome to do so.
Cerf [Page 4]
^L
RFC 388 NCP Statistics August 1972
Please note that these summarized statistics are for standard local
24 hour period (e.g. local midnight to local midnight). They are not
for a sliding 24 hour period ending with the time at which statistics
were requested. Also, the data is to be collected only for open
connections on links 0, 2-71.
The following are participating (others) are heartily invited):
UCLA-NMC, DMCG, LL-67.
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Helene Morin, Via Genie, 12/99]
Cerf [Page 5]
^L
|
