NCP statistics
A method for hosts to send daily NCP statistics to UCLA-NMC.
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]
ISO Plain Language
On this page
§1The Collection Procedure
UCLA-NMC announces that it is ready to gather NCP statistics automatically on a daily basis. It will periodically open a connection on a host's local socket 241 (decimal), and expects the host to send its data after receiving an Allocate command.
When transmission of the last message is complete and its RFNM arrives, the host closes the connection. A host that connects to UCLA-NMC socket 241 can receive UCLA-NMC's own 24-hour data.
UCLA-NMC opens a connection to a host's socket 241 and requests its report. The report covers the last local 24-hour period.
§2Statistics Included
The requested figures include total bits and messages sent to and received from each host, plus an optional average round-trip delay on send connections. The RFC says only standard open connections should be counted, excluding measurement and experimental NCP links; it specifically excludes link 0 from the per-host traffic counts.
An optional report can show the distribution of message types on link 0 across all hosts. The RFC says the summarized figures cover a standard local day, such as local midnight to midnight, rather than a sliding 24-hour period.
Hosts report how many bits and messages they exchanged with other hosts. They can also report average delay and counts of control-message types.
§3Report Format
The first word contains a 16-bit day number and a 16-bit time in minutes when sampling started. The second word contains the source host, byte size, number of host-related entries and format flags.
Each following entry identifies a foreign host and includes the counts selected by the format flags. Optional link 0 control-message data uses pairs of an 8-bit type and a 24-bit count; average RFNM delay is in milliseconds.
The report begins with the sample date and time, then identifies the reporting host and which statistics follow. It then lists data for each other host.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
DAY | Day number | 2 bytes | Day of year: 1 to 365, or 6 on leap year. | |
TIME | Start time | 2 bytes | Minutes at which sample started, from 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. | |
ENTRY-COUNT | N | 1 byte | Number of host-related entries. | |
FORMAT | Format | 1 byte | Flags C, R, B and M select optional contents. |
§4Participation and Publication
The RFC says UCLA-NMC will publish results monthly as Network Measurement notes and RFCs. UCLA-NMC, DMCG and LL-67 are named as participants, and other hosts are invited to join.
Several sites are named as participants, and other hosts are invited. UCLA-NMC plans to publish the collected results each month.