rfc1944.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   fragmented IP, X.25 frames out.)

   By extending the single DUT test model, reasonable benchmarks
   regarding multiple DUTs or heterogeneous environments may be
   collected. In this extension, the single DUT is replaced by a system
   of interconnected network DUTs. This test methodology would support
   the benchmarking of a variety of device/media/service/protocol
   combinations. For example, a configuration for a LAN-to-WAN-to-LAN
   test might be:

   (1) 802.3-> DUT 1 -> X.25 @ 64kbps -> DUT 2 -> 802.3

   Or a mixed LAN configuration might be:

   (2) 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3




Bradner & McQuaid            Informational                     [Page 12]

RFC 1944                Benchmarking Methodology                May 1996


   In both examples 1 and 2, end-to-end benchmarks of each system could
   be empirically ascertained. Other behavior may be characterized
   through the use of intermediate devices. In example 2, the
   configuration may be used to give an indication of the FDDI to FDDI
   capability exhibited by DUT 2.

   Because multiple DUTs are treated as a single system, there are
   limitations to this methodology. For instance, this methodology may
   yield an aggregate benchmark for a tested system. That benchmark
   alone, however, may not necessarily reflect asymmetries in behavior
   between the DUTs, latencies introduce by other apparatus (e.g.,
   CSUs/DSUs, switches), etc.

   Further, care must be used when comparing benchmarks of different
   systems by ensuring that the DUTs' features/configuration of the
   tested systems have the appropriate common denominators to allow
   comparison.

20. Maximum frame rate

   The maximum frame rates that should be used when testing LAN
   connections SHOULD be the listed theoretical maximum rate for the
   frame size on the media.

   The maximum frame rate that should be used when testing WAN
   connections SHOULD be greater than the listed theoretical maximum
   rate for the frame size on that speed connection.  The higher rate
   for WAN tests is to compensate for the fact that some vendors employ
   various forms of header compression.

   A list of maximum frame rates for LAN connections is included in
   Appendix B.

21. Bursty traffic

   It is convenient to measure the DUT performance under steady state
   load but this is an unrealistic way to gauge the functioning of a DUT
   since actual network traffic normally consists of bursts of frames.
   Some of the tests described below SHOULD be performed with both
   steady state traffic and with traffic consisting of repeated bursts
   of frames.  The frames within a burst are transmitted with the
   minimum legitimate inter-frame gap.

   The objective of the test is to determine the minimum interval
   between bursts which the DUT can process with no frame loss. During
   each test the number of frames in each burst is held constant and the
   inter-burst interval varied.  Tests SHOULD be run with burst sizes of
   16, 64, 256 and 1024 frames.



Bradner & McQuaid            Informational                     [Page 13]

RFC 1944                Benchmarking Methodology                May 1996


22. Frames per token

   Although it is possible to configure some token ring and FDDI
   interfaces to transmit more than one frame each time that the token
   is received, most of the network devices currently available transmit
   only one frame per token.  These tests SHOULD first be performed
   while transmitting only one frame per token.

   Some current high-performance workstation servers do transmit more
   than one frame per token on FDDI to maximize throughput.  Since this
   may be a common feature in future workstations and servers,
   interconnect devices with FDDI interfaces SHOULD be tested with 1, 4,
   8, and 16 frames per token.  The reported frame rate SHOULD be the
   average rate of frame transmission over the total trial period.

23. Trial description

   A particular test consists of multiple trials.  Each trial returns
   one piece of information, for example the loss rate at a particular
   input frame rate.  Each trial consists of a number of phases:

    a) If the DUT is a router, send the routing update to the "input"
   port and pause two seconds to be sure that the routing has settled.

    b)  Send the "learning frames" to the "output" port and wait 2
   seconds to be sure that the learning has settled.  Bridge learning
   frames are frames with source addresses that are the same as the
   destination addresses used by the test frames.  Learning frames for
   other protocols are used to prime the address resolution tables in
   the DUT.  The formats of the learning frame that should be used are
   shown in the Test Frame Formats document.

    c) Run the test trial.

    d) Wait for two seconds for any residual frames to be received.

    e) Wait for at least five seconds for the DUT to restabilize.

24. Trial duration

   The aim of these tests is to determine the rate continuously
   supportable by the DUT.  The actual duration of the test trials must
   be a compromise between this aim and the duration of the benchmarking
   test suite.  The duration of the test portion of each trial SHOULD be
   at least 60 seconds.  The tests that involve some form of "binary
   search", for example the throughput test, to determine the exact
   result MAY use a shorter trial duration to minimize the length of the
   search procedure, but  the final determination SHOULD be made with



Bradner & McQuaid            Informational                     [Page 14]

RFC 1944                Benchmarking Methodology                May 1996


   full length trials.

25. Address resolution

   The DUT SHOULD be able to respond to address resolution requests sent
   by the DUT wherever the protocol requires such a process.

26. Benchmarking tests:

   Note: The notation "type of data stream" refers to the above
   modifications to a frame stream with a constant inter-frame gap, for
   example, the addition of traffic filters to the configuration of the
   DUT.

   26.1 Throughput

      Objective:
      To determine the DUT throughput as defined in RFC 1242.

      Procedure:
      Send a specific number of frames at a specific rate through the
      DUT and then count the frames that are transmitted by the DUT. If
      the count of offered frames is equal to the count of received
      frames, the rate of the offered stream is raised and the test
      rerun.  If fewer frames are received than were transmitted, the
      rate of the offered stream is reduced and the test is rerun.

      The throughput is the fastest rate at which the count of test
      frames transmitted by the DUT is equal to the number of test
      frames sent to it by the test equipment.

      Reporting format:
      The results of the throughput test SHOULD be reported in the form
      of a graph. If it is, the x coordinate SHOULD be the frame size,
      the y coordinate SHOULD be the frame rate.  There SHOULD be at
      least two lines on the graph.  There SHOULD be one line showing
      the theoretical frame rate for the media at the various frame
      sizes.  The second line SHOULD be the plot of the test results.
      Additional lines MAY be used on the graph to report the results
      for each type of data stream tested.  Text accompanying the graph
      SHOULD indicate the protocol, data stream format, and type of
      media used in the tests.

      We assume that if a single value is desired for advertising
      purposes the vendor will select the rate for the minimum frame
      size for the media. If this is done then the figure MUST be
      expressed in frames per second.  The rate MAY also be expressed in
      bits (or bytes) per second if the vendor so desires.  The



Bradner & McQuaid            Informational                     [Page 15]

RFC 1944                Benchmarking Methodology                May 1996


      statement of performance MUST include a/ the measured maximum
      frame rate, b/ the size of the frame used, c/ the theoretical
      limit of the media for that frame size, and d/ the type of
      protocol used in the test.  Even if a single value is used as part
      of the advertising copy, the full table of results SHOULD be
      included in the product data sheet.

   26.2 Latency

      Objective:
      To determine the latency as defined in RFC 1242.

      Procedure:
      First determine the throughput for DUT at each of the listed frame
      sizes. Send a stream of frames at a particular frame size through
      the DUT at the determined throughput rate to a specific
      destination.  The stream SHOULD be at least 120 seconds in
      duration.  An identifying tag SHOULD be included in one frame
      after 60 seconds with the type of tag being implementation
      dependent. The time at which this frame is fully transmitted is
      recorded (timestamp A).  The receiver logic in the test equipment
      MUST recognize the tag information in the frame stream and record
      the time at which the tagged frame was received (timestamp B).

      The latency is timestamp B minus timestamp A as per the relevant
      definition frm RFC 1242, namely latency as defined for store and
      forward devices or latency as defined for bit forwarding devices.

      The test MUST be repeated at least 20 times with the reported
      value being the average of the recorded values.

      This test SHOULD be performed with the test frame addressed to the
      same destination as the rest of the data stream and also with each
      of the test frames addressed to a new destination network.

      Reporting format:
      The report MUST state which definition of latency (from RFC 1242)
      was used for this test.  The latency results SHOULD be reported
      in the format of a table with a row for each of the tested frame
      sizes.  There SHOULD be columns for the frame size, the rate at
      which the latency test was run for that frame size, for the media
      types tested, and for the resultant latency values for each
      type of data stream tested.








Bradner & McQuaid            Informational                     [Page 16]

RFC 1944                Benchmarking Methodology                May 1996


   26.3 Frame loss rate

      Objective:
      To determine the frame loss rate, as defined in RFC 1242, of a DUT
      throughout the entire range of input data rates and frame sizes.

      Procedure:
      Send a specific number of frames at a specific rate through the
      DUT to be tested and count the frames that are transmitted by the
      DUT.   The frame loss rate at each point is calculated using the
      following equation:

       ( ( input_count - output_count ) * 100 ) / input_count

      The first trial SHOULD be run for the frame rate that corresponds
      to 100% of the maximum rate for the frame size on the input media.
      Repeat the procedure for the rate that corresponds to 90% of the
      maximum rate used and then for 80% of this rate.  This sequence
      SHOULD be continued (at reducing 10% intervals) until there are
      two successive trials in which no frames are lost. The maximum
      granularity of the trials MUST be 10% of the maximum rate, a finer
      granularity is encouraged.

      Reporting format:
      The results of the frame loss rate test SHOULD be plotted as a
      graph.  If this is done then the X axis MUST be the input frame
      rate as a percent of the theoretical rate for the media at the
      specific frame size. The Y axis MUST be the percent loss at the
      particular input rate.  The left end of the X axis and the bottom
      of the Y axis MUST be 0 percent; the right end of the X axis and
      the top of the Y axis MUST be 100 percent.  Multiple lines on the
      graph MAY used to report the frame loss rate for different frame
      sizes, protocols, and types of data streams.

      Note: See section 18 for the maximum frame rates that SHOULD be
      used.

   26.4 Back-to-back frames

      Objective:
      To characterize the ability of a DUT to process back-to-back
      frames as defined in RFC 1242.

      Procedure:
      Send a burst of frames with minimum inter-frame gaps to the DUT
      and count the number of frames forwarded by the DUT.  If the count
      of transmitted frames is equal to the number of frames forwarded
      the length of the burst is increased and the test is rerun.  If



Bradner & McQuaid            Informational                     [Page 17]

RFC 1944                Benchmarking Methodology                May 1996


      the number of forwarded frames is less than the number
      transmitted, the length of the burst is reduced and the test is
      rerun.

      The back-to-back value is the number of frames in the longest
      burst that the DUT will handle without the loss of any frames.
      The trial length MUST be at least 2 seconds and SHOULD be
      repeated at least 50 times with the average of the recorded values
      being reported.

      Reporting format:
      The back-to-back results SHOULD be reported in the format of a
      table with a row for each of the tested frame sizes.  There SHOULD
      be columns for the frame size and for the resultant average frame
      count for each type of data stream tested.  The standard deviation
      for each measurement MAY also be reported.

   26.5 System recovery

      Objective:
      To characterize the speed at which a DUT recovers from an overload
      condition.