Formation of Network Measurement Group (NMG)
Minutes of the 1972 meeting that set up a group to measure the ARPANET and reserved links for test traffic.
Cerf, V., "Formation of Network Measurement Group (NMG)", RFC 323, DOI 10.17487/RFC0323, March 1972, <https://www.rfc-editor.org/info/rfc323>.
@misc{rfc323,
series = {Request for Comments},
number = 323,
howpublished = {RFC 323},
publisher = {RFC Editor},
doi = {10.17487/RFC0323},
url = {https://www.rfc-editor.org/info/rfc323},
author = {V. Cerf},
title = {{Formation of Network Measurement Group (NMG)}},
pagetotal = 9,
year = 1972,
month = mar,
} RFC text
Contents
Network Working Group Vint Cerf
Request for Comments: 323 UCLA-NMC
NIC: 9630 March 23, 1972
Formation of Network Measurement Group (NMG)
On March 17, 1972, at MIT project MAC, the following group met to
discuss plans to perform measurement experiments on the ARPANET:
A. Bhushan - MIT/DMCG
V. Cerf - UCLA/NMC, Chairman, NMG
S. Crocker - ARPA/IPT
J. Forgie - LL/TX-2
R. Metcalfe - MIT/HARV/DMCG
M. Padlipsky - MIT/MULTICS
J. Postel - UCLA/NMC
J. Winett - LL/67
The purpose of the meeting was to discuss existing and planned
measurements of network and HOST behavior.
1. Measurement Link #'s
It was agreed (after a ridiculously long discussion) to allocate
links 159-191 for network measurement only (see RFC #317). It was
further agreed that these links would be allocated in the following
way:
159-174 HOST DISCARD; co-operating HOSTS receiving messages on
these links will throw them away without generating an
error message.
175-190 To be allocated as needed by V. Cerf - UCLA/NMC.
191 To be used by IMPs to send measurement traffic
obtained from IMP statistics packages.
It should be apparent that HOSTs wishing to co-operate in the support
of a HOST discard service should modify their NCP's to throw away all
messages received on links 159-174 without sending an error back to
the source HOST (no connection will be open on these links).
2. Process Discard
Although it was not mentioned at the meeting, C. Kline at UCLA has
suggested a PROCESS DISCARD also with some well known socket number.
The purpose of this discard routine would be to help us study
Process-Process behavior of the network.
It would be convenient if all co-operating HOSTs could write a
Process Discard program which would simply wait for ICP on some
standard socket number. Until a complete survey is made of well-
known socket numbers at each HOST, no socket number will be proposed
(see RFC #322).
3. NCP Statistics
At the meeting it was apparent that several sites have already
instrumented their NCP's out of curiosity. In particular, Joel
Winett, Lincoln Labs (360/67), has instrumented all connections
originated by local TELNET users. He gathers statistics per
connection such as:
a) Network connect time
b) NCP CPU time
c) Number of reads or writes on connection
d) Time stamps on:
first RFC, last RFC, first close, last close.
e) Number of messages and bits transmitted
f) Log of errors sent or received
MULTICS gathers summary statistics on the number of regular (type 0)
messages sent and received, and the number of irregular messages (not
type 0) sent or received.
The NWG agreed to implement a minimal NCP instrumentation procedure
which would gather by HOST for some standard 24 hour period (e.g.
local midnight to local midnight) the following:
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 whose well-known (to be specified) socket
number will support ICP and will produce a message in the following
format:
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 | | |
+--------+------+-------+----------+
| | | |_____________
___________| | | |
| | | |
Network | | +-----+-----+--+--+--+--+
Host number | | | | |C |R |B |M |
| | +-----+-----+--+--+--+--+
| | | | | |
| | | | | message
| number of HOST | | | statistics
| related entries | | |
| in message | | |__byte
| | | statistics
| | |
number of bits per | |__average
byte in byte statistics | round-trip
| time
|
|__control
message
distribution
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 | +---------------------+
entries | | message sent | if FORMAT bit M set
| +---------------------+
| | 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
| | | over all HOSTs. If a type is
+-------+---------------+ not present, its count is
| | | assumed to be 0.
+-------+---------------+
| | |
+-------+---------------+
| | |
+-------+---------------+
| . | . |
. .
. .
+-------+---------------+
|type | Count |
+-------+---------------+
The process sending these statistics will continue to send data until
it has transmitted the entire statistics sample at which time it will
close both connections. The process which requested the initial
connection is expected to continue to allocate space as it is
available until it receives a close request on the open connections.
It then responds with matching closes. The sending process should
not close until it has received a RFNM for the last message it wishes
to send.
4. Process level measurements
R Metcalfe MIT/DMCG suggested that the NWG consider trying to gather
the following data about network connections:
1. Capacity in bits/sec
2. Transmission delay
3. Mean Time Between Failures
4. Percent availability
These statistics characterize connections as communication
commodities and would be the kind of information one would want if
Network connections were for sale as "off-the-shelf" items. The
first two measures are fairly easy to obtain (although they may vary
from connection to connection). The last two are harder to get at
and will require some planning to measure.
5 HOST surveys
Several HOSTS have built or are building automatic survey programs
which periodically test and record the status of various HOSTs. BB&N
(Ellen Westheimer) has been doing this manually on a daily basis.
MIT/DMCG has a program developed by R. Metcalfe and M. Seriff which
gathers these statistics every 15 minutes and stores the data away in
messaged form. The data can be retrieved through the NETWORK program
at DMCG. A summary can be obtained, by HOST, declaring the % time VP
overall samples and the message response to perform ICP in seconds.
This program also keeps the state of the HOSTs according to the
following measures:
code meaning
---- -------
0 HOST not surveyed
1 HOST Dead (according to IMP)
2 NCP not responding to RESET request (15 second time-out)
3 NCP rejecting (ICP got close response).
4 Logger not responding (20 second time-out after ICP request).
5 Logger available (i.e. ICP successful followed by Close request
by DMCG).
Details and sample data are available in an RFC produced by M. Seriff
(RFC #308, NIC #9259). At UCLA, M. Kampe is implementing a similar
program.
J. Postel and V. Cerf plotted Ellen Westheimer's data for HOSTS OPEN
(regarding HOST advertising of service of hours) and found the
resulting plot rather interesting. The result is reproduced in the
figure below. On a moving average, the number of HOSTS OPEN seems to
be increasing, which is a good sign.
[Here was a figure]
5. File Transmission Statistics
At MIT/DMCG, H. Brodie has measured transmission delay and total
throughput as a function of file size for transmissions to and from
UCSB's Simple Minded File System. The NWG is interested in
specifying certain measurements which should become a standard part
of any File transmission protocol implementation. In particular,
distributions of file sizes, transmission delay and perhaps
destination would be of interest. Throughput measurements could also
be used to correlate with Metcalfe's suggested connection
measurements.
6. Artificial traffic generator
UCLA and Lincoln Labs have experimented with artificial traffic
generators as a means of testing network capacity. At Lincoln Labs,
J. Forgie used the 360/67 to generate traffic from a normal user
process. Depending on system load, he was able to maintain traffic
rates ranging from 4800 bps to 38K bps. UCLA has had a generator for
about a year and has managed to obtain transmission rates around 75K
bps using multiple links for parallel transmission.
The NWG is interested in having such artificial traffic generators
available at several HOSTs as a means of artificially loading the
network. Ideally, generators could be started by a TELNET-like
protocol and would permit specification of
a) Link #'s to send on
b) Destination: HOST's or IMP's discard
c) Inter-arrival time distribution for messages sent on each
link (i.e. possibly different distribution for each link).
Or at least average IAT for assumed exponential
distribution. An average IAT of 0 would imply RFNM driven
traffic
d) Message length distribution, or average, or fixed length for
each link.
It would also be helpful to accumulate average round-trip times and
total bits sent for the duration of the experiment.
At UCLA, the traffic generator permits the following specifications:
a) message header (includes link #)
b) message length (for each link) - distribution (can be
constant for each link)
c) message inter-arrival time - distribution for each link
d) Duration of generation in seconds
We can also send imperative commands to the program to stop message
generation prematurely. Throughput and average response times (Round
Trip delays) are automatically accumulated for each link and are
published at the end of the experiment.
A more sophisticated version will also permit specification of ICP
socket number for the Process Discard experiments. The idea is to
have a number of artificial traffic generators available at different
sites and to be able to start these up remotely from UCLA/NMC during
the course of a measurement experiment. More details of the desired
generator will be published in another RFC.
7. Measurements at other sites
People at sites not mentioned may have done some measurement work and
the NWG encourages these people to publish their results. If anyone
is interested in co-operating with the NWG in making NCP measurements
(or what-have-you), please get in touch with
Vint Cerf
UCLA-NMC Computer Science Department
3804 Boelter Hall
Los Angeles, California 90024
(213) 825-4864
(213) 825-2368
[This RFC was put into machine readable form for entry]
[into the online RFC archives by H�l�ne Morin, Viag�nie, 12/99]
AI ELI5
On this page
§1The Network Measurement Group
On March 17, 1972, a group met at MIT project MAC to discuss plans to perform measurement experiments on the ARPANET. Eight people attended, and V. Cerf of UCLA/NMC was named Chairman of the NMG. The purpose was to discuss existing and planned measurements of network and HOST behavior.
The RFC is Cerf's report of what was discussed and agreed.
Some grown-up scientists met in a room to plan how to check whether the network was working well. One of them was put in charge of the group.
§2Links Reserved for Measurement
After what the RFC calls a ridiculously long discussion, the group agreed to allocate links 159 to 191 for network measurement only (see RFC 317). Links 159 to 174 are HOST DISCARD: cooperating HOSTs receiving messages on these links throw them away without generating an error message. Links 175 to 190 are to be allocated as needed by V. Cerf. Link 191 is used by IMPs to send measurement traffic obtained from IMP statistics packages.
A HOST that wants to support the discard service should modify its NCP to drop all messages on links 159 to 174 without sending an error back to the source HOST. No connection is open on these links.
A separate PROCESS DISCARD was also suggested by C. Kline at UCLA, to study process-to-process behavior. It would wait for ICP on a well-known socket, but no socket number was proposed until a survey of well-known sockets is complete (see RFC 322).
They picked a row of lanes just for test traffic. Some lanes were like a bin where test messages get thrown away so nobody gets confused.
- 159-174HOST DISCARD — Cooperating HOSTs throw messages away without an error message.
- 175-190As needed — Allocated as needed by V. Cerf at UCLA/NMC.
- 191IMP statistics — Used by IMPs to send measurement traffic from IMP statistics packages.
§3NCP Statistics and the Report Format
Several sites had already instrumented their NCPs out of curiosity. Joel Winett at Lincoln Labs, for example, gathered per-connection statistics for local TELNET users, such as network connect time, NCP CPU time and a log of errors.
The group agreed on a minimal NCP instrumentation procedure. For a standard 24 hour period, each HOST counts, per remote HOST, the total bits and messages sent and received, and optionally the average round trip delay. Only standard open connections are counted, not measurement links, experimental NCP links or link 0. Another optional measurement is the distribution of message types on link 0.
The last 24 hour sample is made available by a process on a well-known socket (still to be specified) that supports ICP. Its message starts with a word holding a Day # and a start time in minutes, from 0 (midnight) to 1439. The next word holds the source host, byte size, number of host entries and a format byte whose bits say which statistics follow: message counts, byte counts, average round-trip time and control message distribution.
Every computer would keep a daily tally of how much it sent and got, and be ready to show the tally to anyone who asks, in an agreed layout.
§4Other Measurement Ideas
R. Metcalfe suggested measuring connections as if they were commodities: capacity in bits per second, transmission delay, mean time between failures and percent availability. The first two are fairly easy; the last two are harder.
The RFC also describes HOST survey programs that periodically test whether HOSTs are up. The MIT/DMCG program does this every 15 minutes and records states coded 0 to 5, from "HOST not surveyed" to "Logger available". Details are in RFC 308.
Finally, the NWG wanted file transfer measurements and artificial traffic generators. At Lincoln Labs, J. Forgie kept traffic between 4800 bps and 38K bps; UCLA reached around 75K bps using multiple links in parallel.
They also wanted to check which computers were awake and to build a machine that makes pretend traffic, a bit like testing a road by driving lots of empty trucks on it.