rfc1944.txt

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

Network Working Group                                         S. Bradner
Request for Comments: 1944                            Harvard University
Category: Informational                                       J. McQuaid
                                                            Bay Networks
                                                                May 1996


       Benchmarking Methodology for Network Interconnect Devices

Status of This Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document discusses and defines a number of tests that may be
   used to describe the performance characteristics of a network
   interconnecting  device.  In addition to defining the tests this
   document also describes specific formats for reporting the results of
   the tests.  Appendix A lists the tests and conditions that we believe
   should be included for specific cases and gives additional
   information about testing practices.  Appendix B is a reference
   listing of maximum frame rates to be used with specific frame sizes
   on various media and Appendix C gives some examples of frame formats
   to be used in testing.

1. Introduction

   Vendors often engage in "specsmanship" in an attempt to give their
   products a better position in the marketplace.  This often involves
   "smoke & mirrors" to confuse the potential users of the products.

   This document defines a specific set of tests that vendors can use to
   measure and report the performance characteristics of network
   devices.  The results of these tests will provide the user comparable
   data from different vendors with which to evaluate these devices.

   A previous document, "Benchmarking Terminology for Network
   Interconnect Devices" (RFC 1242), defined many of the terms that are
   used in this document.  The terminology document should be consulted
   before attempting to make use of this document.








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


2. Real world

   In producing this document the authors attempted to keep in mind the
   requirement that apparatus to perform the described tests must
   actually be built.  We do not know of "off the shelf" equipment
   available to implement all of the tests but it is our opinion that
   such equipment can be constructed.

3. Tests to be run

   There are a number of tests described in this document.  Not all of
   the tests apply to all types of devices under test (DUTs). Vendors
   should perform all of the tests that can be supported by a specific
   type of product.  The authors understand that it will take a
   considerable period of time to perform all of the recommended tests
   nder  all of the recommended conditions. We believe that the results
   are worth the effort.  Appendix A lists some of the tests and
   conditions that we believe should be included for specific cases.

4. Evaluating the results

   Performing all of the recommended tests will result in a great deal
   of data. Much of this data will not apply to the evaluation of the
   devices under each circumstance.  For example, the rate at which a
   router forwards IPX frames will be of little use in selecting a
   router for an environment that does not (and will not) support that
   protocol.  Evaluating even that data which is relevant to a
   particular network installation will require experience which may not
   be readily available. Furthermore, selection of the tests to be run
   and evaluation of the test data must be done with an understanding of
   generally accepted testing practices regarding repeatability,
   variance and statistical significance of small numbers of trials.

5. Requirements

   In this document, the words that are used to define the significance
   of each particular requirement are capitalized. These words are:

    * "MUST" This word, or the words "REQUIRED" and "SHALL" mean that
   the item is an absolute requirement of the specification.

    * "SHOULD" This word or the adjective "RECOMMENDED" means that there
   may exist valid reasons in particular circumstances to ignore this
   item, but the full implications should be understood and the case
   carefully weighed before choosing a different course.

    * "MAY" This word or the adjective "OPTIONAL" means that this item
   is truly optional.  One vendor may choose to include the item because



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


   a particular marketplace requires it or because it enhances the
   product, for example; another vendor may omit the same item.

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST requirements for the protocols it implements.  An
   implementation that satisfies all the MUST and all the SHOULD
   requirements for its protocols is said to be "unconditionally
   compliant"; one that satisfies all the MUST requirements but not all
   the SHOULD requirements for its protocols is said to be
   "conditionally compliant".

6. Test set up

   The ideal way to implement this series of tests is to use a tester
   with both transmitting and receiving ports.  Connections are made
   from the sending ports of the tester to the receiving ports of the
   DUT and from the sending ports of the DUT back to the tester. (see
   Figure 1)  Since the tester both sends the test traffic and receives
   it back, after the traffic has been forwarded but the DUT, the tester
   can easily determine if all of the transmitted packets were received
   and verify that the correct packets were received.  The same
   functionality can be obtained with separate transmitting and
   receiving devices (see Figure 2) but unless they are remotely
   controlled by some computer in a way that simulates the single
   tester, the labor required to accurately perform some of the tests
   (particularly the throughput test) can be prohibitive.

                            +------------+
                            |            |
               +------------|  tester    |<-------------+
               |            |            |              |
               |            +------------+              |
               |                                        |
               |            +------------+              |
               |            |            |              |
               +----------->|    DUT     |--------------+
                            |            |
                            +------------+
                              Figure 1

         +--------+         +------------+          +----------+
         |        |         |            |          |          |
         | sender |-------->|    DUT     |--------->| receiver |
         |        |         |            |          |          |
         +--------+         +------------+          +----------+
                              Figure 2





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


6.1 Test set up for multiple media types

   Two different setups could be used to test a DUT which is used in
   real-world networks to connect networks of differing media type,
   local Ethernet to a backbone FDDI ring for example.  The tester could
   support both media types in which case the set up shown in Figure 1
   would be used.

   Two identical DUTs are used in the other test set up. (see Figure 3)
   In many cases this set up may more accurately simulate the real
   world.  For example, connecting two LANs together with a WAN link or
   high speed backbone.  This set up would not be as good at simulating
   a system where clients on a Ethernet LAN were interacting with a
   server on an FDDI backbone.

                               +-----------+
                               |           |
         +---------------------|  tester   |<---------------------+
         |                     |           |                      |
         |                     +-----------+                      |
         |                                                        |
         |        +----------+               +----------+         |
         |        |          |               |          |         |
         +------->|  DUT 1   |-------------->|   DUT 2  |---------+
                  |          |               |          |
                  +----------+               +----------+

                                  Figure 3

7. DUT set up

   Before starting to perform the tests, the DUT to be tested MUST be
   configured following the instructions provided to the user.
   Specifically, it is expected that all of the supported protocols will
   be configured and enabled during this set up (See Appendix A).  It is
   expected that all of the tests will be run without changing the
   configuration or setup of the DUT in any way other than that required
   to do the specific test.  For example, it is not acceptable to change
   the size of frame handling buffers between tests of frame handling
   rates or to disable all but one transport protocol when testing the
   throughput of that protocol.  It is necessary to modify the
   configuration when starting a test to determine the effect of filters
   on throughput, but the only change MUST be to enable the specific
   filter. The DUT set up SHOULD include the normally recommended
   routing update intervals and keep alive frequency.  The specific
   version of the software and the exact DUT configuration, including
   what functions are disabled, used during the tests MUST be included
   as part of the report of the results.



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


8. Frame formats

   The formats of the test frames to use for TCP/IP over Ethernet are
   shown in Appendix C: Test Frame Formats.  These exact frame formats
   SHOULD be used in the tests described in this document for this
   protocol/media combination and that these frames will be used as a
   template for testing other protocol/media combinations.  The specific
   formats that are used to define the test frames for a particular test
   series MUST be included in the report of the results.

9. Frame sizes

   All of the described tests SHOULD be performed at a number of frame
   sizes. Specifically, the sizes SHOULD include the maximum and minimum
   legitimate sizes for the protocol under test on the media under test
   and enough sizes in between to be able to get a full characterization
   of the DUT performance.  Except where noted, at least five frame
   sizes SHOULD be tested for each test condition.

   Theoretically the minimum size UDP Echo request frame would consist
   of an IP header (minimum length 20 octets), a UDP header (8 octets)
   and whatever MAC level header is required by the media in use.  The
   theoretical maximum frame size is determined by the size of the
   length field in the IP header.  In almost all cases the actual
   maximum and minimum sizes are determined by the limitations of the
   media.

   In theory it would be ideal to distribute the frame sizes in a way
   that would evenly distribute the theoretical frame rates.  These
   recommendations incorporate this theory but specify frame sizes which
   are easy to understand and remember.  In addition, many of the same
   frame sizes are specified on each of the media types to allow for
   easy performance comparisons.

   Note: The inclusion of an unrealistically small frame size on some of
   the media types (i.e. with little or no space for data) is to help
   characterize the per-frame processing overhead of the DUT.

   9.1 Frame sizes to be used on Ethernet

       64, 128, 256, 512, 1024, 1280, 1518

      These sizes include the maximum and minimum frame sizes permitted
      by the Ethernet standard and a selection of sizes between these
      extremes with a finer granularity for the smaller frame sizes and
      higher frame rates.





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


   9.2 Frame sizes to be used on 4Mb and 16Mb token ring

       54, 64, 128, 256, 1024, 1518, 2048, 4472

      The frame size recommendations for token ring assume that there is
      no RIF field in the frames of routed protocols.  A RIF field would
      be present in any direct source route bridge performance test.
      The minimum size frame for UDP on token ring is 54 octets.  The
      maximum size of 4472 octets is recommended for 16Mb token ring
      instead of the theoretical size of 17.9Kb because of the size
      limitations imposed by many token ring interfaces.  The reminder
      of the sizes are selected to permit direct comparisons with other
      types of media.  An IP (i.e. not UDP) frame may be used in
      addition if a higher data rate is desired, in which case the
      minimum frame size is 46 octets.

   9.3 Frame sizes to be used on FDDI

       54, 64, 128, 256, 1024, 1518, 2048, 4472

      The minimum size frame for UDP on FDDI is 53 octets, the minimum
      size of 54 is recommended to allow direct comparison to token ring
      performance.  The maximum size of 4472 is recommended instead of
      the theoretical maximum size of 4500 octets to permit the same
      type of comparison. An IP (i.e. not UDP) frame may be used in
      addition if a higher data rate is desired, in which case the
      minimum frame size is 45 octets.

   9.4 Frame sizes in the presence of disparate MTUs

      When the interconnect DUT supports connecting links with disparate
      MTUs, the frame sizes for the link with the *larger* MTU SHOULD be
      used, up to the limit of the protocol being tested. If the
      interconnect DUT does not support the fragmenting of frames in the
      presence of MTU mismatch, the forwarding rate for that frame size
      shall be reported as zero.

      For example, the test of IP forwarding with a bridge or router
      that joins FDDI and Ethernet should use the frame sizes of FDDI
      when going from the FDDI to the Ethernet link. If the bridge does
      not support IP fragmentation, the forwarding rate for those frames