NCP statistics
UCLA offers to collect daily NCP traffic counts from each ARPANET host over socket 241.
Cerf, V., "NCP statistics", RFC 388, DOI 10.17487/RFC0388, August 1972, <https://www.rfc-editor.org/info/rfc388>.
@misc{rfc388,
series = {Request for Comments},
number = 388,
howpublished = {RFC 388},
publisher = {RFC Editor},
doi = {10.17487/RFC0388},
url = {https://www.rfc-editor.org/info/rfc388},
author = {V. Cerf},
title = {{NCP statistics}},
pagetotal = 5,
year = 1972,
month = aug,
} RFC text
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).
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
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 |
+-------+---------------+
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.
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]
AI ELI5
On this page
§1The Daily Collection Offer
Vint Cerf of UCLA-NMC announces, after a 5 month lapse since RFC 323 (23 March), that the center is ready to gather NCP statistics automatically each day. The unit metadata lists this RFC as updating RFC 323.
UCLA-NMC will periodically open a connection on the host's local socket 241 (decimal) and expect the host to send its data as soon as the Allocate command arrives. This replaces the original idea of an ICP to a well-known socket, which Cerf considers an unnecessary complication. The host closes the connection after it receives the RFNM for its last message.
UCLA will ring a special doorbell on each computer once a day. The computer then hands over its numbers.
§2What Is Counted
For each host, the counts are total bits sent to and received from the host, total messages sent to and received from the host, and optionally the average round trip delay on send connections. Only standard open connections count, not measurement links or experimental NCP links, and not traffic on link 0; data is for open connections on links 0, 2-71 as the RFC phrases it.
An optional extra is the distribution of message types over link 0 across all hosts, which would show the relative use of control messages. The RFC expects ALLOC to be very prevalent. The figures cover the local 24 hour day, midnight to midnight, not a sliding window.
The computer reports how many bits and messages went in and out for each partner computer. It does not count the special test traffic.
§3The Report Format
Word 0 holds a 16 bit day number (1 to 365, 6 on leap year) and a 16 bit time in minutes from 0 to 1439 at which sampling began. Word 1 holds the source host (8 bits), byte size (8 bits), N, the number of host related entries, and a format byte. Format flag bits C, R, B and M say whether control message distribution, average delay, byte statistics and message statistics are present.
Then come N entries, each starting with the foreign host number and followed by the counts that the format bits select. The optional control message distribution is a list of 8 bit type and 24 bit count pairs; a missing type counts as 0. Average delay is the average RFNM delay in milliseconds.
The report is a form with boxes. The first boxes say the date and who is reporting, and the rest list the numbers for each partner computer.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
DAY | Day # | 2 bytes | Day of year, 1 to 365 (6 on leap year). | |
TIME | Time | 2 bytes | Minutes at which the sample started, 0 to 1439. | |
SOURCE-HOST | Source Host | 1 byte | Network host number of the reporter. | |
BYTE-SIZE | Byte Size | 1 byte | Bits per byte in byte statistics. | |
N | N | 1 byte | Number of host related entries. | |
FORMAT | Format | 1 byte | Flag bits C, R, B and M select the optional contents. |
§4Participation
Anyone can connect to UCLA-NMC socket 241 to receive its own 24 hour data and is welcome to capture it. The named participants are UCLA-NMC, DMCG and LL-67, and other hosts are heartily invited to join. Results were to be published monthly as Network Measurement notes and RFCs.
Anyone can ask UCLA for its numbers too. Three groups had signed up, and others were invited.