rfc323.txt

RFC技术文档 从0000－05

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


   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



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

            [phone]
            [phone]



        [This RFC was put into machine readable form for entry]
    [into the online RFC archives by H閘鑞e Morin, Viag閚ie, 12/99]






Cerf                                                            [Page 9]