Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


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
       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.

Cerf [Page 1] RFC 323 Formation of Network Measurement Group March 1972

 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.

Cerf [Page 2] RFC 323 Formation of Network Measurement Group March 1972

 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

Cerf [Page 3] RFC 323 Formation of Network Measurement Group March 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 | | | +——–+——+——-+———-+ | | | |_ _| | | |

  |                   |       |                     |

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

Cerf [Page 4] RFC 323 Formation of Network Measurement Group March 1972

 The remaining words of the message depend on Format byte setting:
              |   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

Cerf [Page 5] RFC 323 Formation of Network Measurement Group March 1972

 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

Cerf [Page 6] RFC 323 Formation of Network Measurement Group March 1972

 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

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
       d) Message length distribution, or average, or fixed length for

Cerf [Page 7] RFC 323 Formation of Network Measurement Group March 1972

          each link.

Cerf [Page 8] RFC 323 Formation of Network Measurement Group March 1972

 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]

Cerf [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc323.txt · Last modified: 2000/05/10 16:50 (external edit)