docs/testing/developer/requirements/vswitchperf_ltd.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3 .. (c) OPNFV, Intel Corporation, AT&T and others.
   4
   5 ******************************
   6 VSPERF LEVEL TEST DESIGN (LTD)
   7 ******************************
   8
   9 .. 3.1
  10
  11 ============
  12 Introduction
  13 ============
  14
  15 The intention of this Level Test Design (LTD) document is to specify the set of
  16 tests to carry out in order to objectively measure the current characteristics
  17 of a virtual switch in the Network Function Virtualization Infrastructure
  18 (NFVI) as well as the test pass criteria. The detailed test cases will be
  19 defined in details-of-LTD_, preceded by the doc-id-of-LTD_ and the scope-of-LTD_.
  20
  21 This document is currently in draft form.
  22
  23 .. 3.1.1
  24
  25
  26 .. _doc-id-of-LTD:
  27
  28 Document identifier
  29 ===================
  30
  31 The document id will be used to uniquely
  32 identify versions of the LTD. The format for the document id will be:
  33 OPNFV\_vswitchperf\_LTD\_REL\_STATUS, where by the
  34 status is one of: draft, reviewed, corrected or final. The document id
  35 for this version of the LTD is:
  36 OPNFV\_vswitchperf\_LTD\_Brahmaputra\_REVIEWED.
  37
  38 .. 3.1.2
  39
  40 .. _scope-of-LTD:
  41
  42 Scope
  43 =====
  44
  45 The main purpose of this project is to specify a suite of
  46 performance tests in order to objectively measure the current packet
  47 transfer characteristics of a virtual switch in the NFVI. The intent of
  48 the project is to facilitate testing of any virtual switch. Thus, a
  49 generic suite of tests shall be developed, with no hard dependencies to
  50 a single implementation. In addition, the test case suite shall be
  51 architecture independent.
  52
  53 The test cases developed in this project shall not form part of a
  54 separate test framework, all of these tests may be inserted into the
  55 Continuous Integration Test Framework and/or the Platform Functionality
  56 Test Framework - if a vSwitch becomes a standard component of an OPNFV
  57 release.
  58
  59 .. 3.1.3
  60
  61 References
  62 ==========
  63
  64 *  `RFC 1242 Benchmarking Terminology for Network Interconnection
  65    Devices <http://www.ietf.org/rfc/rfc1242.txt>`__
  66 *  `RFC 2544 Benchmarking Methodology for Network Interconnect
  67    Devices <http://www.ietf.org/rfc/rfc2544.txt>`__
  68 *  `RFC 2285 Benchmarking Terminology for LAN Switching
  69    Devices <http://www.ietf.org/rfc/rfc2285.txt>`__
  70 *  `RFC 2889 Benchmarking Methodology for LAN Switching
  71    Devices <http://www.ietf.org/rfc/rfc2889.txt>`__
  72 *  `RFC 3918 Methodology for IP Multicast
  73    Benchmarking <http://www.ietf.org/rfc/rfc3918.txt>`__
  74 *  `RFC 4737 Packet Reordering
  75    Metrics <http://www.ietf.org/rfc/rfc4737.txt>`__
  76 *  `RFC 5481 Packet Delay Variation Applicability
  77    Statement <http://www.ietf.org/rfc/rfc5481.txt>`__
  78 *  `RFC 6201 Device Reset
  79    Characterization <http://tools.ietf.org/html/rfc6201>`__
  80
  81 .. 3.2
  82
  83 .. _details-of-LTD:
  84
  85 ================================
  86 Details of the Level Test Design
  87 ================================
  88
  89 This section describes the features to be tested (FeaturesToBeTested-of-LTD_), and
  90 identifies the sets of test cases or scenarios (TestIdentification-of-LTD_).
  91
  92 .. 3.2.1
  93
  94 .. _FeaturesToBeTested-of-LTD:
  95
  96 Features to be tested
  97 =====================
  98
  99 Characterizing virtual switches (i.e. Device Under Test (DUT) in this document)
 100 includes measuring the following performance metrics:
 101
 102 - Throughput
 103 - Packet delay
 104 - Packet delay variation
 105 - Packet loss
 106 - Burst behaviour
 107 - Packet re-ordering
 108 - Packet correctness
 109 - Availability and capacity of the DUT
 110
 111 .. 3.2.2
 112
 113 .. _TestIdentification-of-LTD:
 114
 115 Test identification
 116 ===================
 117
 118 .. 3.2.2.1
 119
 120 Throughput tests
 121 ----------------
 122
 123 The following tests aim to determine the maximum forwarding rate that
 124 can be achieved with a virtual switch. The list is not exhaustive but
 125 should indicate the type of tests that should be required. It is
 126 expected that more will be added.
 127
 128 .. 3.2.2.1.1
 129
 130 .. _PacketLossRatio:
 131
 132 Test ID: LTD.Throughput.RFC2544.PacketLossRatio
 133 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 134
 135     **Title**: RFC 2544 X% packet loss ratio Throughput and Latency Test
 136
 137     **Prerequisite Test**: N/A
 138
 139     **Priority**:
 140
 141     **Description**:
 142
 143     This test determines the DUT's maximum forwarding rate with X% traffic
 144     loss for a constant load (fixed length frames at a fixed interval time).
 145     The default loss percentages to be tested are: - X = 0% - X = 10^-7%
 146
 147     Note: Other values can be tested if required by the user.
 148
 149     The selected frame sizes are those previously defined under
 150     :ref:`default-test-parameters`.
 151     The test can also be used to determine the average latency of the traffic.
 152
 153     Under the `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__
 154     test methodology, the test duration will
 155     include a number of trials; each trial should run for a minimum period
 156     of 60 seconds. A binary search methodology must be applied for each
 157     trial to obtain the final result.
 158
 159     **Expected Result**: At the end of each trial, the presence or absence
 160     of loss determines the modification of offered load for the next trial,
 161     converging on a maximum rate, or
 162     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ Throughput with X%
 163     loss.
 164     The Throughput load is re-used in related
 165     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ tests and other
 166     tests.
 167
 168     **Metrics Collected**:
 169
 170     The following are the metrics collected for this test:
 171
 172     -  The maximum forwarding rate in Frames Per Second (FPS) and Mbps of
 173        the DUT for each frame size with X% packet loss.
 174     -  The average latency of the traffic flow when passing through the DUT
 175        (if testing for latency, note that this average is different from the
 176        test specified in Section 26.3 of
 177        `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__).
 178     -  CPU and memory utilization may also be collected as part of this
 179        test, to determine the vSwitch's performance footprint on the system.
 180
 181 .. 3.2.2.1.2
 182
 183 .. _PacketLossRatioFrameModification:
 184
 185 Test ID: LTD.Throughput.RFC2544.PacketLossRatioFrameModification
 186 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 187
 188     **Title**: RFC 2544 X% packet loss Throughput and Latency Test with
 189     packet modification
 190
 191     **Prerequisite Test**: N/A
 192
 193     **Priority**:
 194
 195     **Description**:
 196
 197     This test determines the DUT's maximum forwarding rate with X% traffic
 198     loss for a constant load (fixed length frames at a fixed interval time).
 199     The default loss percentages to be tested are: - X = 0% - X = 10^-7%
 200
 201     Note: Other values can be tested if required by the user.
 202
 203     The selected frame sizes are those previously defined under
 204     :ref:`default-test-parameters`.
 205     The test can also be used to determine the average latency of the traffic.
 206
 207     Under the `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__
 208     test methodology, the test duration will
 209     include a number of trials; each trial should run for a minimum period
 210     of 60 seconds. A binary search methodology must be applied for each
 211     trial to obtain the final result.
 212
 213     During this test, the DUT must perform the following operations on the
 214     traffic flow:
 215
 216     -  Perform packet parsing on the DUT's ingress port.
 217     -  Perform any relevant address look-ups on the DUT's ingress ports.
 218     -  Modify the packet header before forwarding the packet to the DUT's
 219        egress port. Packet modifications include:
 220
 221        -  Modifying the Ethernet source or destination MAC address.
 222        -  Modifying/adding a VLAN tag. (**Recommended**).
 223        -  Modifying/adding a MPLS tag.
 224        -  Modifying the source or destination ip address.
 225        -  Modifying the TOS/DSCP field.
 226        -  Modifying the source or destination ports for UDP/TCP/SCTP.
 227        -  Modifying the TTL.
 228
 229     **Expected Result**: The Packet parsing/modifications require some
 230     additional degree of processing resource, therefore the
 231     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__
 232     Throughput is expected to be somewhat lower than the Throughput level
 233     measured without additional steps. The reduction is expected to be
 234     greatest on tests with the smallest packet sizes (greatest header
 235     processing rates).
 236
 237     **Metrics Collected**:
 238
 239     The following are the metrics collected for this test:
 240
 241     -  The maximum forwarding rate in Frames Per Second (FPS) and Mbps of
 242        the DUT for each frame size with X% packet loss and packet
 243        modification operations being performed by the DUT.
 244     -  The average latency of the traffic flow when passing through the DUT
 245        (if testing for latency, note that this average is different from the
 246        test specified in Section 26.3 of
 247        `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__).
 248     -  The `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__
 249        PDV form of delay variation on the traffic flow,
 250        using the 99th percentile.
 251     -  CPU and memory utilization may also be collected as part of this
 252        test, to determine the vSwitch's performance footprint on the system.
 253
 254 .. 3.2.2.1.3
 255
 256 Test ID: LTD.Throughput.RFC2544.Profile
 257 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 258
 259     **Title**: RFC 2544 Throughput and Latency Profile
 260
 261     **Prerequisite Test**: N/A
 262
 263     **Priority**:
 264
 265     **Description**:
 266
 267     This test reveals how throughput and latency degrades as the offered
 268     rate varies in the region of the DUT's maximum forwarding rate as
 269     determined by LTD.Throughput.RFC2544.PacketLossRatio (0% Packet Loss).
 270     For example it can be used to determine if the degradation of throughput
 271     and latency as the offered rate increases is slow and graceful or sudden
 272     and severe.
 273
 274     The selected frame sizes are those previously defined under
 275     :ref:`default-test-parameters`.
 276
 277     The offered traffic rate is described as a percentage delta with respect
 278     to the DUT's RFC 2544 Throughput as determined by
 279     LTD.Throughput.RFC2544.PacketLoss Ratio (0% Packet Loss case). A delta
 280     of 0% is equivalent to an offered traffic rate equal to the RFC 2544
 281     Maximum Throughput; A delta of +50% indicates an offered rate half-way
 282     between the Maximum RFC2544 Throughput and line-rate, whereas a delta of
 283     -50% indicates an offered rate of half the RFC 2544 Maximum Throughput.
 284     Therefore the range of the delta figure is natuarlly bounded at -100%
 285     (zero offered traffic) and +100% (traffic offered at line rate).
 286
 287     The following deltas to the maximum forwarding rate should be applied:
 288
 289     -  -50%, -10%, 0%, +10% & +50%
 290
 291     **Expected Result**: For each packet size a profile should be produced
 292     of how throughput and latency vary with offered rate.
 293
 294     **Metrics Collected**:
 295
 296     The following are the metrics collected for this test:
 297
 298     -  The forwarding rate in Frames Per Second (FPS) and Mbps of the DUT
 299        for each delta to the maximum forwarding rate and for each frame
 300        size.
 301     -  The average latency for each delta to the maximum forwarding rate and
 302        for each frame size.
 303     -  CPU and memory utilization may also be collected as part of this
 304        test, to determine the vSwitch's performance footprint on the system.
 305     -  Any failures experienced (for example if the vSwitch crashes, stops
 306        processing packets, restarts or becomes unresponsive to commands)
 307        when the offered load is above Maximum Throughput MUST be recorded
 308        and reported with the results.
 309
 310 .. 3.2.2.1.4
 311
 312 Test ID: LTD.Throughput.RFC2544.SystemRecoveryTime
 313 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 314
 315     **Title**: RFC 2544 System Recovery Time Test
 316
 317     **Prerequisite Test** LTD.Throughput.RFC2544.PacketLossRatio
 318
 319     **Priority**:
 320
 321     **Description**:
 322
 323     The aim of this test is to determine the length of time it takes the DUT
 324     to recover from an overload condition for a constant load (fixed length
 325     frames at a fixed interval time). The selected frame sizes are those
 326     previously defined under :ref:`default-test-parameters`,
 327     traffic should be sent to the DUT under normal conditions. During the
 328     duration of the test and while the traffic flows are passing though the
 329     DUT, at least one situation leading to an overload condition for the DUT
 330     should occur. The time from the end of the overload condition to when
 331     the DUT returns to normal operations should be measured to determine
 332     recovery time. Prior to overloading the DUT, one should record the
 333     average latency for 10,000 packets forwarded through the DUT.
 334
 335     The overload condition SHOULD be to transmit traffic at a very high
 336     frame rate to the DUT (150% of the maximum 0% packet loss rate as
 337     determined by LTD.Throughput.RFC2544.PacketLossRatio or line-rate
 338     whichever is lower), for at least 60 seconds, then reduce the frame rate
 339     to 75% of the maximum 0% packet loss rate. A number of time-stamps
 340     should be recorded: - Record the time-stamp at which the frame rate was
 341     reduced and record a second time-stamp at the time of the last frame
 342     lost. The recovery time is the difference between the two timestamps. -
 343     Record the average latency for 10,000 frames after the last frame loss
 344     and continue to record average latency measurements for every 10,000
 345     frames, when latency returns to within 10% of pre-overload levels record
 346     the time-stamp.
 347
 348     **Expected Result**:
 349
 350     **Metrics collected**
 351
 352     The following are the metrics collected for this test:
 353
 354     -  The length of time it takes the DUT to recover from an overload
 355        condition.
 356     -  The length of time it takes the DUT to recover the average latency to
 357        pre-overload conditions.
 358
 359     **Deployment scenario**:
 360
 361     -  Physical → virtual switch → physical.
 362
 363 .. 3.2.2.1.5
 364
 365 .. _BackToBackFrames:
 366
 367 Test ID: LTD.Throughput.RFC2544.BackToBackFrames
 368 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 369
 370     **Title**: RFC2544 Back To Back Frames Test
 371
 372     **Prerequisite Test**: N
 373
 374     **Priority**:
 375
 376     **Description**:
 377
 378     The aim of this test is to characterize the ability of the DUT to
 379     process back-to-back frames. For each frame size previously defined
 380     under :ref:`default-test-parameters`, a burst of traffic
 381     is sent to the DUT with the minimum inter-frame gap between each frame.
 382     If the number of received frames equals the number of frames that were
 383     transmitted, the burst size should be increased and traffic is sent to
 384     the DUT again. The value measured is the back-to-back value, that is the
 385     maximum burst size the DUT can handle without any frame loss. Please note
 386     a trial must run for a minimum of 2 seconds and should be repeated 50
 387     times (at a minimum).
 388
 389     **Expected Result**:
 390
 391     Tests of back-to-back frames with physical devices have produced
 392     unstable results in some cases. All tests should be repeated in multiple
 393     test sessions and results stability should be examined.
 394
 395     **Metrics collected**
 396
 397     The following are the metrics collected for this test:
 398
 399     -  The average back-to-back value across the trials, which is
 400        the number of frames in the longest burst that the DUT will
 401        handle without the loss of any frames.
 402     -  CPU and memory utilization may also be collected as part of this
 403        test, to determine the vSwitch's performance footprint on the system.
 404
 405     **Deployment scenario**:
 406
 407     -  Physical → virtual switch → physical.
 408
 409 .. 3.2.2.1.6
 410
 411 Test ID: LTD.Throughput.RFC2889.MaxForwardingRateSoak
 412 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 413
 414     **Title**: RFC 2889 X% packet loss Max Forwarding Rate Soak Test
 415
 416     **Prerequisite Test** LTD.Throughput.RFC2544.PacketLossRatio
 417
 418     **Priority**:
 419
 420     **Description**:
 421
 422     The aim of this test is to understand the Max Forwarding Rate stability
 423     over an extended test duration in order to uncover any outliers. To allow
 424     for an extended test duration, the test should ideally run for 24 hours
 425     or, if this is not possible, for at least 6 hours. For this test, each frame
 426     size must be sent at the highest Throughput rate with X% packet loss, as
 427     determined in the prerequisite test. The default loss percentages to be
 428     tested are: - X = 0% - X = 10^-7%
 429
 430     Note: Other values can be tested if required by the user.
 431
 432     **Expected Result**:
 433
 434     **Metrics Collected**:
 435
 436     The following are the metrics collected for this test:
 437
 438     -  Max Forwarding Rate stability of the DUT.
 439
 440        -  This means reporting the number of packets lost per time interval
 441           and reporting any time intervals with packet loss. The
 442           `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__
 443           Forwarding Rate shall be measured in each interval.
 444           An interval of 60s is suggested.
 445
 446     -  CPU and memory utilization may also be collected as part of this
 447        test, to determine the vSwitch's performance footprint on the system.
 448     -  The `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__
 449        PDV form of delay variation on the traffic flow,
 450        using the 99th percentile.
 451
 452 .. 3.2.2.1.7
 453
 454 Test ID: LTD.Throughput.RFC2889.MaxForwardingRateSoakFrameModification
 455 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 456
 457     **Title**: RFC 2889 Max Forwarding Rate Soak Test with Frame Modification
 458
 459     **Prerequisite Test**:
 460     LTD.Throughput.RFC2544.PacketLossRatioFrameModification (0% Packet Loss)
 461
 462     **Priority**:
 463
 464     **Description**:
 465
 466     The aim of this test is to understand the Max Forwarding Rate stability over an
 467     extended test duration in order to uncover any outliers. To allow for an
 468     extended test duration, the test should ideally run for 24 hours or, if
 469     this is not possible, for at least 6 hour. For this test, each frame
 470     size must be sent at the highest Throughput rate with 0% packet loss, as
 471     determined in the prerequisite test.
 472
 473     During this test, the DUT must perform the following operations on the
 474     traffic flow:
 475
 476     -  Perform packet parsing on the DUT's ingress port.
 477     -  Perform any relevant address look-ups on the DUT's ingress ports.
 478     -  Modify the packet header before forwarding the packet to the DUT's
 479        egress port. Packet modifications include:
 480
 481        -  Modifying the Ethernet source or destination MAC address.
 482        -  Modifying/adding a VLAN tag (**Recommended**).
 483        -  Modifying/adding a MPLS tag.
 484        -  Modifying the source or destination ip address.
 485        -  Modifying the TOS/DSCP field.
 486        -  Modifying the source or destination ports for UDP/TCP/SCTP.
 487        -  Modifying the TTL.
 488
 489     **Expected Result**:
 490
 491     **Metrics Collected**:
 492
 493     The following are the metrics collected for this test:
 494
 495     -  Max Forwarding Rate stability of the DUT.
 496
 497        -  This means reporting the number of packets lost per time interval
 498           and reporting any time intervals with packet loss. The
 499           `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__
 500           Forwarding Rate shall be measured in each interval.
 501           An interval of 60s is suggested.
 502
 503     -  CPU and memory utilization may also be collected as part of this
 504        test, to determine the vSwitch's performance footprint on the system.
 505     -  The `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__
 506        PDV form of delay variation on the traffic flow, using the 99th
 507        percentile.
 508
 509 .. 3.2.2.1.8
 510
 511 Test ID: LTD.Throughput.RFC6201.ResetTime
 512 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 513
 514     **Title**: RFC 6201 Reset Time Test
 515
 516     **Prerequisite Test**: N/A
 517
 518     **Priority**:
 519
 520     **Description**:
 521
 522     The aim of this test is to determine the length of time it takes the DUT
 523     to recover from a reset.
 524
 525     Two reset methods are defined - planned and unplanned. A planned reset
 526     requires stopping and restarting the virtual switch by the usual
 527     'graceful' method defined by it's documentation. An unplanned reset
 528     requires simulating a fatal internal fault in the virtual switch - for
 529     example by using kill -SIGKILL on a Linux environment.
 530
 531     Both reset methods SHOULD be exercised.
 532
 533     For each frame size previously defined under :ref:`default-test-parameters`,
 534     traffic should be sent to the DUT under
 535     normal conditions. During the duration of the test and while the traffic
 536     flows are passing through the DUT, the DUT should be reset and the Reset
 537     time measured. The Reset time is the total time that a device is
 538     determined to be out of operation and includes the time to perform the
 539     reset and the time to recover from it (cf. `RFC6201
 540     <https://www.rfc-editor.org/rfc/rfc6201.txt>`__).
 541
 542     `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ defines two methods
 543     to measure the Reset time:
 544
 545       - Frame-Loss Method: which requires the monitoring of the number of
 546         lost frames and calculates the Reset time based on the number of
 547         frames lost and the offered rate according to the following
 548         formula:
 549
 550         .. code-block:: console
 551
 552                                     Frames_lost (packets)
 553                  Reset_time = -------------------------------------
 554                                 Offered_rate (packets per second)
 555
 556       - Timestamp Method: which measures the time from which the last frame
 557         is forwarded from the DUT to the time the first frame is forwarded
 558         after the reset. This involves time-stamping all transmitted frames
 559         and recording the timestamp of the last frame that was received prior
 560         to the reset and also measuring the timestamp of the first frame that
 561         is received after the reset. The Reset time is the difference between
 562         these two timestamps.
 563
 564     According to `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ the
 565     choice of method depends on the test tool's capability; the Frame-Loss
 566     method SHOULD be used if the test tool supports:
 567
 568      * Counting the number of lost frames per stream.
 569      * Transmitting test frame despite the physical link status.
 570
 571     whereas the Timestamp method SHOULD be used if the test tool supports:
 572
 573      * Timestamping each frame.
 574      * Monitoring received frame's timestamp.
 575      * Transmitting frames only if the physical link status is up.
 576
 577     **Expected Result**:
 578
 579     **Metrics collected**
 580
 581     The following are the metrics collected for this test:
 582
 583      * Average Reset Time over the number of trials performed.
 584
 585     Results of this test should include the following information:
 586
 587      * The reset method used.
 588      * Throughput in Fps and Mbps.
 589      * Average Frame Loss over the number of trials performed.
 590      * Average Reset Time in milliseconds over the number of trials performed.
 591      * Number of trials performed.
 592      * Protocol: IPv4, IPv6, MPLS, etc.
 593      * Frame Size in Octets
 594      * Port Media: Ethernet, Gigabit Ethernet (GbE), etc.
 595      * Port Speed: 10 Gbps, 40 Gbps etc.
 596      * Interface Encapsulation: Ethernet, Ethernet VLAN, etc.
 597
 598     **Deployment scenario**:
 599
 600     * Physical → virtual switch → physical.
 601
 602 .. 3.2.2.1.9
 603
 604 Test ID: LTD.Throughput.RFC2889.MaxForwardingRate
 605 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 606
 607     **Title**: RFC2889 Forwarding Rate Test
 608
 609     **Prerequisite Test**: LTD.Throughput.RFC2544.PacketLossRatio
 610
 611     **Priority**:
 612
 613     **Description**:
 614
 615     This test measures the DUT's Max Forwarding Rate when the Offered Load
 616     is varied between the throughput and the Maximum Offered Load for fixed
 617     length frames at a fixed time interval. The selected frame sizes are
 618     those previously defined under :ref:`default-test-parameters`.
 619     The throughput is the maximum offered
 620     load with 0% frame loss (measured by the prerequisite test), and the
 621     Maximum Offered Load (as defined by
 622     `RFC2285 <https://www.rfc-editor.org/rfc/rfc2285.txt>`__) is *"the highest
 623     number of frames per second that an external source can transmit to a
 624     DUT/SUT for forwarding to a specified output interface or interfaces"*.
 625
 626     Traffic should be sent to the DUT at a particular rate (TX rate)
 627     starting with TX rate equal to the throughput rate. The rate of
 628     successfully received frames at the destination counted (in FPS). If the
 629     RX rate is equal to the TX rate, the TX rate should be increased by a
 630     fixed step size and the RX rate measured again until the Max Forwarding
 631     Rate is found.
 632
 633     The trial duration for each iteration should last for the period of time
 634     needed for the system to reach steady state for the frame size being
 635     tested. Under `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__
 636     (Sec. 5.6.3.1) test methodology, the test
 637     duration should run for a minimum period of 30 seconds, regardless
 638     whether the system reaches steady state before the minimum duration
 639     ends.
 640
 641     **Expected Result**: According to
 642     `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__ The Max Forwarding
 643     Rate is the highest forwarding rate of a DUT taken from an iterative set of
 644     forwarding rate measurements. The iterative set of forwarding rate measurements
 645     are made by setting the intended load transmitted from an external source and
 646     measuring the offered load (i.e what the DUT is capable of forwarding). If the
 647     Throughput == the Maximum Offered Load, it follows that Max Forwarding Rate is
 648     equal to the Maximum Offered Load.
 649
 650     **Metrics Collected**:
 651
 652     The following are the metrics collected for this test:
 653
 654     -  The Max Forwarding Rate for the DUT for each packet size.
 655     -  CPU and memory utilization may also be collected as part of this
 656        test, to determine the vSwitch's performance footprint on the system.
 657
 658     **Deployment scenario**:
 659
 660     -  Physical → virtual switch → physical. Note: Full mesh tests with
 661        multiple ingress and egress ports are a key aspect of RFC 2889
 662        benchmarks, and scenarios with both 2 and 4 ports should be tested.
 663        In any case, the number of ports used must be reported.
 664
 665 .. 3.2.2.1.10
 666
 667 Test ID: LTD.Throughput.RFC2889.ForwardPressure
 668 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 669
 670     **Title**: RFC2889 Forward Pressure Test
 671
 672     **Prerequisite Test**: LTD.Throughput.RFC2889.MaxForwardingRate
 673
 674     **Priority**:
 675
 676     **Description**:
 677
 678     The aim of this test is to determine if the DUT transmits frames with an
 679     inter-frame gap that is less than 12 bytes. This test overloads the DUT
 680     and measures the output for forward pressure. Traffic should be
 681     transmitted to the DUT with an inter-frame gap of 11 bytes, this will
 682     overload the DUT by 1 byte per frame. The forwarding rate of the DUT
 683     should be measured.
 684
 685     **Expected Result**: The forwarding rate should not exceed the maximum
 686     forwarding rate of the DUT collected by
 687     LTD.Throughput.RFC2889.MaxForwardingRate.
 688
 689     **Metrics collected**
 690
 691     The following are the metrics collected for this test:
 692
 693     -  Forwarding rate of the DUT in FPS or Mbps.
 694     -  CPU and memory utilization may also be collected as part of this
 695        test, to determine the vSwitch's performance footprint on the system.
 696
 697     **Deployment scenario**:
 698
 699     -  Physical → virtual switch → physical.
 700
 701 .. 3.2.2.1.11
 702
 703 Test ID: LTD.Throughput.RFC2889.ErrorFramesFiltering
 704 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 705
 706     **Title**: RFC2889 Error Frames Filtering Test
 707
 708     **Prerequisite Test**: N/A
 709
 710     **Priority**:
 711
 712     **Description**:
 713
 714     The aim of this test is to determine whether the DUT will propagate any
 715     erroneous frames it receives or whether it is capable of filtering out
 716     the erroneous frames. Traffic should be sent with erroneous frames
 717     included within the flow at random intervals. Illegal frames that must
 718     be tested include: - Oversize Frames. - Undersize Frames. - CRC Errored
 719     Frames. - Dribble Bit Errored Frames - Alignment Errored Frames
 720
 721     The traffic flow exiting the DUT should be recorded and checked to
 722     determine if the erroneous frames where passed through the DUT.
 723
 724     **Expected Result**: Broken frames are not passed!
 725
 726     **Metrics collected**
 727
 728     No Metrics are collected in this test, instead it determines:
 729
 730     -  Whether the DUT will propagate erroneous frames.
 731     -  Or whether the DUT will correctly filter out any erroneous frames
 732        from traffic flow with out removing correct frames.
 733
 734     **Deployment scenario**:
 735
 736     -  Physical → virtual switch → physical.
 737
 738 .. 3.2.2.1.12
 739
 740 Test ID: LTD.Throughput.RFC2889.BroadcastFrameForwarding
 741 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 742
 743     **Title**: RFC2889 Broadcast Frame Forwarding Test
 744
 745     **Prerequisite Test**: N
 746
 747     **Priority**:
 748
 749     **Description**:
 750
 751     The aim of this test is to determine the maximum forwarding rate of the
 752     DUT when forwarding broadcast traffic. For each frame previously defined
 753     under :ref:`default-test-parameters`, the traffic should
 754     be set up as broadcast traffic. The traffic throughput of the DUT should
 755     be measured.
 756
 757     The test should be conducted with at least 4 physical ports on the DUT.
 758     The number of ports used MUST be recorded.
 759
 760     As broadcast involves forwarding a single incoming packet to several
 761     destinations, the latency of a single packet is defined as the average
 762     of the latencies for each of the broadcast destinations.
 763
 764     The incoming packet is transmitted on each of the other physical ports,
 765     it is not transmitted on the port on which it was received. The test MAY
 766     be conducted using different broadcasting ports to uncover any
 767     performance differences.
 768
 769     **Expected Result**:
 770
 771     **Metrics collected**:
 772
 773     The following are the metrics collected for this test:
 774
 775     -  The forwarding rate of the DUT when forwarding broadcast traffic.
 776     -  The minimum, average & maximum packets latencies observed.
 777
 778     **Deployment scenario**:
 779
 780     -  Physical → virtual switch 3x physical. In the Broadcast rate testing,
 781        four test ports are required. One of the ports is connected to the test
 782        device, so it can send broadcast frames and listen for miss-routed frames.
 783
 784 .. 3.2.2.1.13
 785
 786 Test ID: LTD.Throughput.RFC2544.WorstN-BestN
 787 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 788
 789     **Title**: Modified RFC 2544 X% packet loss ratio Throughput and Latency Test
 790
 791     **Prerequisite Test**: N/A
 792
 793     **Priority**:
 794
 795     **Description**:
 796
 797     This test determines the DUT's maximum forwarding rate with X% traffic
 798     loss for a constant load (fixed length frames at a fixed interval time).
 799     The default loss percentages to be tested are: X = 0%, X = 10^-7%
 800
 801     Modified RFC 2544 throughput benchmarking methodology aims to quantify
 802     the throughput measurement variations observed during standard RFC 2544
 803     benchmarking measurements of virtual switches and VNFs. The RFC2544
 804     binary search algorithm is modified to use more samples per test trial
 805     to drive the binary search and yield statistically more meaningful
 806     results. This keeps the heart of the RFC2544 methodology, still relying
 807     on the binary search of throughput at specified loss tolerance, while
 808     providing more useful information about the range of results seen in
 809     testing. Instead of using a single traffic trial per iteration step,
 810     each traffic trial is repeated N times and the success/failure of the
 811     iteration step is based on these N traffic trials. Two types of revised
 812     tests are defined - *Worst-of-N* and *Best-of-N*.
 813
 814     **Worst-of-N**
 815
 816     *Worst-of-N* indicates the lowest expected maximum throughput for (
 817     packet size, loss tolerance) when repeating the test.
 818
 819     1.  Repeat the same test run N times at a set packet rate, record each
 820         result.
 821     2.  Take the WORST result (highest packet loss) out of N result samples,
 822         called the Worst-of-N sample.
 823     3.  If Worst-of-N sample has loss less than the set loss tolerance, then
 824         the step is successful - increase the test traffic rate.
 825     4.  If Worst-of-N sample has loss greater than the set loss tolerance
 826         then the step failed - decrease the test traffic rate.
 827     5.  Go to step 1.
 828
 829     **Best-of-N**
 830
 831     *Best-of-N* indicates the highest expected maximum throughput for (
 832     packet size, loss tolerance) when repeating the test.
 833
 834     1.  Repeat the same traffic run N times at a set packet rate, record
 835         each result.
 836     2.  Take the BEST result (least packet loss) out of N result samples,
 837         called the Best-of-N sample.
 838     3.  If Best-of-N sample has loss less than the set loss tolerance, then
 839         the step is successful - increase the test traffic rate.
 840     4.  If Best-of-N sample has loss greater than the set loss tolerance,
 841         then the step failed - decrease the test traffic rate.
 842     5.  Go to step 1.
 843
 844     Performing both Worst-of-N and Best-of-N benchmark tests yields lower
 845     and upper bounds of expected maximum throughput under the operating
 846     conditions, giving a very good indication to the user of the
 847     deterministic performance range for the tested setup.
 848
 849     **Expected Result**: At the end of each trial series, the presence or
 850     absence of loss determines the modification of offered load for the
 851     next trial series, converging on a maximum rate, or
 852     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ Throughput
 853     with X% loss.
 854     The Throughput load is re-used in related
 855     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ tests and other
 856     tests.
 857
 858     **Metrics Collected**:
 859
 860     The following are the metrics collected for this test:
 861
 862     -  The maximum forwarding rate in Frames Per Second (FPS) and Mbps of
 863        the DUT for each frame size with X% packet loss.
 864     -  The average latency of the traffic flow when passing through the DUT
 865        (if testing for latency, note that this average is different from the
 866        test specified in Section 26.3 of
 867        `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__).
 868     -  Following may also be collected as part of this test, to determine
 869        the vSwitch's performance footprint on the system:
 870
 871       -  CPU core utilization.
 872       -  CPU cache utilization.
 873       -  Memory footprint.
 874       -  System bus (QPI, PCI, ...) utilization.
 875       -  CPU cycles consumed per packet.
 876
 877 .. 3.2.2.1.14
 878
 879 Test ID: LTD.Throughput.Overlay.Network.<tech>.RFC2544.PacketLossRatio
 880 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 881
 882        **Title**: <tech> Overlay Network RFC 2544 X% packet loss ratio Throughput and Latency Test
 883
 884
 885        NOTE: Throughout this test, four interchangeable overlay technologies are covered by the
 886        same test description.  They are: VXLAN, GRE, NVGRE and GENEVE.
 887
 888       **Prerequisite Test**: N/A
 889
 890       **Priority**:
 891
 892       **Description**:
 893       This test evaluates standard switch performance benchmarks for the scenario where an
 894       Overlay Network is deployed for all paths through the vSwitch. Overlay Technologies covered
 895       (replacing <tech> in the test name) include:
 896
 897       - VXLAN
 898       - GRE
 899       - NVGRE
 900       - GENEVE
 901
 902       Performance will be assessed for each of the following overlay network functions:
 903
 904       - Encapsulation only
 905       - De-encapsulation only
 906       - Both Encapsulation and De-encapsulation
 907
 908       For each native packet, the DUT must perform the following operations:
 909
 910       - Examine the packet and classify its correct overlay net (tunnel) assignment
 911       - Encapsulate the packet
 912       - Switch the packet to the correct port
 913
 914       For each encapsulated packet, the DUT must perform the following operations:
 915
 916       - Examine the packet and classify its correct native network assignment
 917       - De-encapsulate the packet, if required
 918       - Switch the packet to the correct port
 919
 920     The selected frame sizes are those previously defined under
 921     :ref:`default-test-parameters`.
 922
 923     Thus, each test comprises an overlay technology, a network function,
 924     and a packet size *with* overlay network overhead included
 925     (but see also the discussion at
 926     https://etherpad.opnfv.org/p/vSwitchTestsDrafts ).
 927
 928     The test can also be used to determine the average latency of the traffic.
 929
 930     Under the `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__
 931     test methodology, the test duration will
 932     include a number of trials; each trial should run for a minimum period
 933     of 60 seconds. A binary search methodology must be applied for each
 934     trial to obtain the final result for Throughput.
 935
 936     **Expected Result**: At the end of each trial, the presence or absence
 937     of loss determines the modification of offered load for the next trial,
 938     converging on a maximum rate, or
 939     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ Throughput with X%
 940     loss (where the value of X is typically equal to zero).
 941     The Throughput load is re-used in related
 942     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ tests and other
 943     tests.
 944
 945     **Metrics Collected**:
 946     The following are the metrics collected for this test:
 947
 948     -  The maximum Throughput in Frames Per Second (FPS) and Mbps of
 949        the DUT for each frame size with X% packet loss.
 950     -  The average latency of the traffic flow when passing through the DUT
 951        and VNFs (if testing for latency, note that this average is different from the
 952        test specified in Section 26.3 of
 953        `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__).
 954     -  CPU and memory utilization may also be collected as part of this
 955        test, to determine the vSwitch's performance footprint on the system.
 956
 957 .. 3.2.3.1.15
 958
 959 Test ID: LTD.Throughput.RFC2544.MatchAction.PacketLossRatio
 960 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 961
 962     **Title**: RFC 2544 X% packet loss ratio match action Throughput and Latency Test
 963
 964     **Prerequisite Test**: LTD.Throughput.RFC2544.PacketLossRatio
 965
 966     **Priority**:
 967
 968     **Description**:
 969
 970     The aim of this test is to determine the cost of carrying out match
 971     action(s) on the DUT’s RFC2544 Throughput with X% traffic loss for
 972     a constant load (fixed length frames at a fixed interval time).
 973
 974     Each test case requires:
 975
 976          * selection of a specific match action(s),
 977          * specifying a percentage of total traffic that is elligible
 978            for the match action,
 979          * determination of the specific test configuration (number
 980            of flows, number of test ports, presence of an external
 981            controller, etc.), and
 982          * measurement of the RFC 2544 Throughput level with X% packet
 983            loss: Traffic shall be bi-directional and symmetric.
 984
 985     Note: It would be ideal to verify that all match action-elligible
 986     traffic was forwarded to the correct port, and if forwarded to
 987     an unintended port it should be considered lost.
 988
 989     A match action is an action that is typically carried on a frame
 990     or packet that matches a set of flow classification parameters
 991     (typically frame/packet header fields). A match action may or may
 992     not modify a packet/frame. Match actions include [1]:
 993
 994          * output : outputs a packet to a particular port.
 995          * normal: Subjects the packet to traditional L2/L3 processing
 996            (MAC learning).
 997          * flood: Outputs the packet on all switch physical ports
 998            other than the port on which it was received and any ports
 999            on which flooding is disabled.
1000          * all: Outputs the packet on all switch physical ports other
1001            than the port on which it was received.
1002          * local: Outputs  the packet on the ``local port``, which
1003            corresponds to the network device that has the same name as
1004            the bridge.
1005          * in_port: Outputs the packet on the port from which it was
1006            received.
1007          * Controller: Sends the packet and its metadata to the
1008            OpenFlow controller as a ``packet in`` message.
1009          * enqueue: Enqueues  the  packet  on the specified queue
1010            within port.
1011          * drop: discard the packet.
1012
1013    Modifications include [1]:
1014
1015          * mod vlan: covered by LTD.Throughput.RFC2544.PacketLossRatioFrameModification
1016          * mod_dl_src: Sets the source Ethernet address.
1017          * mod_dl_dst: Sets the destination Ethernet address.
1018          * mod_nw_src: Sets the IPv4 source address.
1019          * mod_nw_dst: Sets the IPv4 destination address.
1020          * mod_tp_src: Sets the TCP or UDP or SCTP source port.
1021          * mod_tp_dst: Sets the TCP or UDP or SCTP destination port.
1022          * mod_nw_tos: Sets the  DSCP bits in the IPv4 ToS/DSCP or
1023            IPv6 traffic class field.
1024          * mod_nw_ecn: Sets the ECN bits in the appropriate IPv4 or
1025            IPv6 field.
1026          * mod_nw_ttl: Sets the IPv4 TTL or IPv6 hop limit field.
1027
1028     Note: This comprehensive list requires extensive traffic generator
1029     capabilities.
1030
1031     The match action(s) that were applied as part of the test should be
1032     reported in the final test report.
1033
1034     During this test, the DUT must perform the following operations on
1035     the traffic flow:
1036
1037         * Perform packet parsing on the DUT’s ingress port.
1038         * Perform any relevant address look-ups on the DUT’s ingress
1039           ports.
1040         * Carry out one or more of the match actions specified above.
1041
1042     The default loss percentages to be tested are: - X = 0% - X = 10^-7%
1043     Other values can be tested if required by the user. The selected
1044     frame sizes are those previously defined under
1045     :ref:`default-test-parameters`.
1046
1047     The test can also be used to determine the average latency of the
1048     traffic when a match action is applied to packets in a flow. Under
1049     the RFC2544 test methodology, the test duration will include a
1050     number of trials; each trial should run for a minimum period of 60
1051     seconds. A binary search methodology must be applied for each
1052     trial to obtain the final result.
1053
1054     **Expected Result:**
1055
1056     At the end of each trial, the presence or absence of loss
1057     determines the modification of offered load for the next trial,
1058     converging on a maximum rate, or RFC2544Throughput with X% loss.
1059     The Throughput load is re-used in related RFC2544 tests and other
1060     tests.
1061
1062     **Metrics Collected:**
1063
1064     The following are the metrics collected for this test:
1065
1066         * The RFC 2544 Throughput in Frames Per Second (FPS) and Mbps
1067           of the DUT for each frame size with X% packet loss.
1068         * The average latency of the traffic flow when passing through
1069           the DUT (if testing for latency, note that this average is
1070           different from the test specified in Section 26.3 ofRFC2544).
1071         * CPU and memory utilization may also be collected as part of
1072           this test, to determine the vSwitch’s performance footprint
1073           on the system.
1074
1075     The metrics collected can be compared to that of the prerequisite
1076     test to determine the cost of the match action(s) in the pipeline.
1077
1078     **Deployment scenario**:
1079
1080     -  Physical → virtual switch → physical (and others are possible)
1081
1082     [1] ovs-ofctl - administer OpenFlow switches
1083         [http://openvswitch.org/support/dist-docs/ovs-ofctl.8.txt ]
1084
1085
1086 .. 3.2.2.2
1087
1088 Packet Latency tests
1089 --------------------
1090
1091 These tests will measure the store and forward latency as well as the packet
1092 delay variation for various packet types through the virtual switch. The
1093 following list is not exhaustive but should indicate the type of tests
1094 that should be required. It is expected that more will be added.
1095
1096 .. 3.2.2.2.1
1097
1098 Test ID: LTD.PacketLatency.InitialPacketProcessingLatency
1099 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1100
1101     **Title**: Initial Packet Processing Latency
1102
1103     **Prerequisite Test**: N/A
1104
1105     **Priority**:
1106
1107     **Description**:
1108
1109     In some virtual switch architectures, the first packets of a flow will
1110     take the system longer to process than subsequent packets in the flow.
1111     This test determines the latency for these packets. The test will
1112     measure the latency of the packets as they are processed by the
1113     flow-setup-path of the DUT. There are two methods for this test, a
1114     recommended method and a nalternative method that can be used if it is
1115     possible to disable the fastpath of the virtual switch.
1116
1117     Recommended method: This test will send 64,000 packets to the DUT, each
1118     belonging to a different flow. Average packet latency will be determined
1119     over the 64,000 packets.
1120
1121     Alternative method: This test will send a single packet to the DUT after
1122     a fixed interval of time. The time interval will be equivalent to the
1123     amount of time it takes for a flow to time out in the virtual switch
1124     plus 10%. Average packet latency will be determined over 1,000,000
1125     packets.
1126
1127     This test is intended only for non-learning virtual switches; For learning
1128     virtual switches use RFC2889.
1129
1130     For this test, only unidirectional traffic is required.
1131
1132     **Expected Result**: The average latency for the initial packet of all
1133     flows should be greater than the latency of subsequent traffic.
1134
1135     **Metrics Collected**:
1136
1137     The following are the metrics collected for this test:
1138
1139     -  Average latency of the initial packets of all flows that are
1140        processed by the DUT.
1141
1142     **Deployment scenario**:
1143
1144     -  Physical → Virtual Switch → Physical.
1145
1146 .. 3.2.2.2.2
1147
1148 Test ID: LTD.PacketDelayVariation.RFC3393.Soak
1149 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1150
1151     **Title**: Packet Delay Variation Soak Test
1152
1153     **Prerequisite Tests**: LTD.Throughput.RFC2544.PacketLossRatio (0% Packet Loss)
1154
1155     **Priority**:
1156
1157     **Description**:
1158
1159     The aim of this test is to understand the distribution of packet delay
1160     variation for different frame sizes over an extended test duration and
1161     to determine if there are any outliers. To allow for an extended test
1162     duration, the test should ideally run for 24 hours or, if this is not
1163     possible, for at least 6 hour. For this test, each frame size must be
1164     sent at the highest possible throughput with 0% packet loss, as
1165     determined in the prerequisite test.
1166
1167     **Expected Result**:
1168
1169     **Metrics Collected**:
1170
1171     The following are the metrics collected for this test:
1172
1173     -  The packet delay variation value for traffic passing through the DUT.
1174     -  The `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__
1175        PDV form of delay variation on the traffic flow,
1176        using the 99th percentile, for each 60s interval during the test.
1177     -  CPU and memory utilization may also be collected as part of this
1178        test, to determine the vSwitch's performance footprint on the system.
1179
1180 .. 3.2.2.3
1181
1182 Scalability tests
1183 -----------------
1184
1185 The general aim of these tests is to understand the impact of large flow
1186 table size and flow lookups on throughput. The following list is not
1187 exhaustive but should indicate the type of tests that should be required.
1188 It is expected that more will be added.
1189
1190 .. 3.2.2.3.1
1191
1192 .. _Scalability0PacketLoss:
1193
1194 Test ID: LTD.Scalability.Flows.RFC2544.0PacketLoss
1195 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1196
1197     **Title**: RFC 2544 0% loss Flow Scalability throughput test
1198
1199     **Prerequisite Test**: LTD.Throughput.RFC2544.PacketLossRatio, IF the
1200     delta Throughput between the single-flow RFC2544 test and this test with
1201     a variable number of flows is desired.
1202
1203     **Priority**:
1204
1205     **Description**:
1206
1207     The aim of this test is to measure how throughput changes as the number
1208     of flows in the DUT increases. The test will measure the throughput
1209     through the fastpath, as such the flows need to be installed on the DUT
1210     before passing traffic.
1211
1212     For each frame size previously defined under :ref:`default-test-parameters`
1213     and for each of the following number of flows:
1214
1215     -  1,000
1216     -  2,000
1217     -  4,000
1218     -  8,000
1219     -  16,000
1220     -  32,000
1221     -  64,000
1222     -  Max supported number of flows.
1223
1224     This test will be conducted under two conditions following the
1225     establishment of all flows as required by RFC 2544, regarding the flow
1226     expiration time-out:
1227
1228     1) The time-out never expires during each trial.
1229
1230     2) The time-out expires for all flows periodically. This would require a
1231     short time-out compared with flow re-appearance for a small number of
1232     flows, and may not be possible for all flow conditions.
1233
1234     The maximum 0% packet loss Throughput should be determined in a manner
1235     identical to LTD.Throughput.RFC2544.PacketLossRatio.
1236
1237     **Expected Result**:
1238
1239     **Metrics Collected**:
1240
1241     The following are the metrics collected for this test:
1242
1243     -  The maximum number of frames per second that can be forwarded at the
1244        specified number of flows and the specified frame size, with zero
1245        packet loss.
1246
1247 .. 3.2.2.3.2
1248
1249 Test ID: LTD.MemoryBandwidth.RFC2544.0PacketLoss.Scalability
1250 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1251
1252     **Title**: RFC 2544 0% loss Memory Bandwidth Scalability test
1253
1254     **Prerequisite Tests**: LTD.Throughput.RFC2544.PacketLossRatio, IF the
1255     delta Throughput between an undisturbed RFC2544 test and this test with
1256     the Throughput affected by cache and memory bandwidth contention is desired.
1257
1258     **Priority**:
1259
1260     **Description**:
1261
1262     The aim of this test is to understand how the DUT's performance is
1263     affected by cache sharing and memory bandwidth between processes.
1264
1265     During the test all cores not used by the vSwitch should be running a
1266     memory intensive application. This application should read and write
1267     random data to random addresses in unused physical memory. The random
1268     nature of the data and addresses is intended to consume cache, exercise
1269     main memory access (as opposed to cache) and exercise all memory buses
1270     equally. Furthermore:
1271
1272     - the ratio of reads to writes should be recorded. A ratio of 1:1
1273       SHOULD be used.
1274     - the reads and writes MUST be of cache-line size and be cache-line aligned.
1275     - in NUMA architectures memory access SHOULD be local to the core's node.
1276       Whether only local memory or a mix of local and remote memory is used
1277       MUST be recorded.
1278     - the memory bandwidth (reads plus writes) used per-core MUST be recorded;
1279       the test MUST be run with a per-core memory bandwidth equal to half the
1280       maximum system memory bandwidth divided by the number of cores. The test
1281       MAY be run with other values for the per-core memory bandwidth.
1282     - the test MAY also be run with the memory intensive application running
1283       on all cores.
1284
1285     Under these conditions the DUT's 0% packet loss throughput is determined
1286     as per LTD.Throughput.RFC2544.PacketLossRatio.
1287
1288     **Expected Result**:
1289
1290     **Metrics Collected**:
1291
1292     The following are the metrics collected for this test:
1293
1294     -  The DUT's 0% packet loss throughput in the presence of cache sharing and
1295        memory bandwidth between processes.
1296
1297 .. 3.2.2.3.3
1298
1299 Test ID: LTD.Scalability.VNF.RFC2544.PacketLossRatio
1300 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1301
1302     **Title**: VNF Scalability RFC 2544 X% packet loss ratio Throughput and
1303                Latency Test
1304
1305     **Prerequisite Test**: N/A
1306
1307     **Priority**:
1308
1309     **Description**:
1310
1311     This test determines the DUT's throughput rate with X% traffic loss for
1312     a constant load (fixed length frames at a fixed interval time) when the
1313     number of VNFs on the DUT increases. The default loss percentages
1314     to be tested are: - X = 0% - X = 10^-7% . The minimum number of
1315     VNFs to be tested are 3.
1316
1317     Flow classification should be conducted with L2, L3 and L4 matching
1318     to understand the matching and scaling capability of the vSwitch. The
1319     matching fields which were used as part of the test should be reported
1320     as part of the benchmark report.
1321
1322     The vSwitch is responsible for forwarding frames between the VNFs
1323
1324     The SUT (vSwitch and VNF daisy chain) operation should be validated
1325     before running the test. This may be completed by running a burst or
1326     continuous stream of traffic through the SUT to ensure proper operation
1327     before a test.
1328
1329     **Note**: The traffic rate used to validate SUT operation should be low
1330     enough not to stress the SUT.
1331
1332     **Note**: Other values can be tested if required by the user.
1333
1334     **Note**: The same VNF should be used in the "daisy chain" formation.
1335     Each addition of a VNF should be conducted in a new test setup (The DUT
1336     is brought down, then the DUT is brought up again). An atlernative approach
1337     would be to continue to add VNFs without bringing down the DUT. The
1338     approach used needs to be documented as part of the test report.
1339
1340     The selected frame sizes are those previously defined under
1341     :ref:`default-test-parameters`.
1342     The test can also be used to determine the average latency of the traffic.
1343
1344     Under the `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__
1345     test methodology, the test duration will
1346     include a number of trials; each trial should run for a minimum period
1347     of 60 seconds. A binary search methodology must be applied for each
1348     trial to obtain the final result for Throughput.
1349
1350     **Expected Result**: At the end of each trial, the presence or absence
1351     of loss determines the modification of offered load for the next trial,
1352     converging on a maximum rate, or
1353     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ Throughput with X%
1354     loss.
1355     The Throughput load is re-used in related
1356     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ tests and other
1357     tests.
1358
1359     If the test VNFs are rather light-weight in terms of processing, the test
1360     provides a view of multiple passes through the vswitch on logical
1361     interfaces. In other words, the test produces an optimistic count of
1362     daisy-chained VNFs, but the cumulative effect of traffic on the vSwitch is
1363     "real" (assuming that the vSwitch has some dedicated resources, and the
1364     effects on shared resources is understood).
1365
1366
1367     **Metrics Collected**:
1368     The following are the metrics collected for this test:
1369
1370     -  The maximum Throughput in Frames Per Second (FPS) and Mbps of
1371        the DUT for each frame size with X% packet loss.
1372     -  The average latency of the traffic flow when passing through the DUT
1373        and VNFs (if testing for latency, note that this average is different from the
1374        test specified in Section 26.3 of
1375        `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__).
1376     -  CPU and memory utilization may also be collected as part of this
1377        test, to determine the vSwitch's performance footprint on the system.
1378
1379 .. 3.2.2.3.4
1380
1381 Test ID: LTD.Scalability.VNF.RFC2544.PacketLossProfile
1382 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1383
1384      **Title**: VNF Scalability RFC 2544 Throughput and Latency Profile
1385
1386      **Prerequisite Test**: N/A
1387
1388      **Priority**:
1389
1390      **Description**:
1391
1392      This test reveals how throughput and latency degrades as the number
1393      of VNFs increases and offered rate varies in the region of the DUT's
1394      maximum forwarding rate as determined by
1395      LTD.Throughput.RFC2544.PacketLossRatio (0% Packet Loss).
1396      For example it can be used to determine if the degradation of throughput
1397      and latency as the number of VNFs and offered rate increases is slow
1398      and graceful, or sudden and severe. The minimum number of VNFs to
1399      be tested is 3.
1400
1401      The selected frame sizes are those previously defined under
1402      :ref:`default-test-parameters`.
1403
1404      The offered traffic rate is described as a percentage delta with respect
1405      to the DUT's RFC 2544 Throughput as determined by
1406      LTD.Throughput.RFC2544.PacketLoss Ratio (0% Packet Loss case). A delta
1407      of 0% is equivalent to an offered traffic rate equal to the RFC 2544
1408      Throughput; A delta of +50% indicates an offered rate half-way
1409      between the Throughput and line-rate, whereas a delta of
1410      -50% indicates an offered rate of half the maximum rate. Therefore the
1411      range of the delta figure is natuarlly bounded at -100% (zero offered
1412      traffic) and +100% (traffic offered at line rate).
1413
1414      The following deltas to the maximum forwarding rate should be applied:
1415
1416      -  -50%, -10%, 0%, +10% & +50%
1417
1418     **Note**: Other values can be tested if required by the user.
1419
1420     **Note**: The same VNF should be used in the "daisy chain" formation.
1421     Each addition of a VNF should be conducted in a new test setup (The DUT
1422     is brought down, then the DUT is brought up again). An atlernative approach
1423     would be to continue to add VNFs without bringing down the DUT. The
1424     approach used needs to be documented as part of the test report.
1425
1426     Flow classification should be conducted with L2, L3 and L4 matching
1427     to understand the matching and scaling capability of the vSwitch. The
1428     matching fields which were used as part of the test should be reported
1429     as part of the benchmark report.
1430
1431     The SUT (vSwitch and VNF daisy chain) operation should be validated
1432     before running the test. This may be completed by running a burst or
1433     continuous stream of traffic through the SUT to ensure proper operation
1434     before a test.
1435
1436     **Note**: the traffic rate used to validate SUT operation should be low
1437     enough not to stress the SUT
1438
1439     **Expected Result**: For each packet size a profile should be produced
1440     of how throughput and latency vary with offered rate.
1441
1442     **Metrics Collected**:
1443
1444     The following are the metrics collected for this test:
1445
1446     -  The forwarding rate in Frames Per Second (FPS) and Mbps of the DUT
1447        for each delta to the maximum forwarding rate and for each frame
1448        size.
1449     -  The average latency for each delta to the maximum forwarding rate and
1450        for each frame size.
1451     -  CPU and memory utilization may also be collected as part of this
1452        test, to determine the vSwitch's performance footprint on the system.
1453     -  Any failures experienced (for example if the vSwitch crashes, stops
1454        processing packets, restarts or becomes unresponsive to commands)
1455        when the offered load is above Maximum Throughput MUST be recorded
1456        and reported with the results.
1457
1458 .. 3.2.2.4
1459
1460 Activation tests
1461 ----------------
1462
1463 The general aim of these tests is to understand the capacity of the
1464 and speed with which the vswitch can accommodate new flows.
1465
1466 .. 3.2.2.4.1
1467
1468 Test ID: LTD.Activation.RFC2889.AddressCachingCapacity
1469 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1470
1471     **Title**: RFC2889 Address Caching Capacity Test
1472
1473     **Prerequisite Test**: N/A
1474
1475     **Priority**:
1476
1477     **Description**:
1478
1479     Please note this test is only applicable to virtual switches that are capable of
1480     MAC learning. The aim of this test is to determine the address caching
1481     capacity of the DUT for a constant load (fixed length frames at a fixed
1482     interval time). The selected frame sizes are those previously defined
1483     under :ref:`default-test-parameters`.
1484
1485     In order to run this test the aging time, that is the maximum time the
1486     DUT will keep a learned address in its flow table, and a set of initial
1487     addresses, whose value should be >= 1 and <= the max number supported by
1488     the implementation must be known. Please note that if the aging time is
1489     configurable it must be longer than the time necessary to produce frames
1490     from the external source at the specified rate. If the aging time is
1491     fixed the frame rate must be brought down to a value that the external
1492     source can produce in a time that is less than the aging time.
1493
1494     Learning Frames should be sent from an external source to the DUT to
1495     install a number of flows. The Learning Frames must have a fixed
1496     destination address and must vary the source address of the frames. The
1497     DUT should install flows in its flow table based on the varying source
1498     addresses. Frames should then be transmitted from an external source at
1499     a suitable frame rate to see if the DUT has properly learned all of the
1500     addresses. If there is no frame loss and no flooding, the number of
1501     addresses sent to the DUT should be increased and the test is repeated
1502     until the max number of cached addresses supported by the DUT
1503     determined.
1504
1505     **Expected Result**:
1506
1507     **Metrics collected**:
1508
1509     The following are the metrics collected for this test:
1510
1511     -  Number of cached addresses supported by the DUT.
1512     -  CPU and memory utilization may also be collected as part of this
1513        test, to determine the vSwitch's performance footprint on the system.
1514
1515     **Deployment scenario**:
1516
1517     -  Physical → virtual switch → 2 x physical (one receiving, one listening).
1518
1519 .. 3.2.2.4.2
1520
1521 Test ID: LTD.Activation.RFC2889.AddressLearningRate
1522 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1523
1524     **Title**: RFC2889 Address Learning Rate Test
1525
1526     **Prerequisite Test**: LTD.Memory.RFC2889.AddressCachingCapacity
1527
1528     **Priority**:
1529
1530     **Description**:
1531
1532     Please note this test is only applicable to virtual switches that are capable of
1533     MAC learning. The aim of this test is to determine the rate of address
1534     learning of the DUT for a constant load (fixed length frames at a fixed
1535     interval time). The selected frame sizes are those previously defined
1536     under :ref:`default-test-parameters`, traffic should be
1537     sent with each IPv4/IPv6 address incremented by one. The rate at which
1538     the DUT learns a new address should be measured. The maximum caching
1539     capacity from LTD.Memory.RFC2889.AddressCachingCapacity should be taken
1540     into consideration as the maximum number of addresses for which the
1541     learning rate can be obtained.
1542
1543     **Expected Result**: It may be worthwhile to report the behaviour when
1544     operating beyond address capacity - some DUTs may be more friendly to
1545     new addresses than others.
1546
1547     **Metrics collected**:
1548
1549     The following are the metrics collected for this test:
1550
1551     -  The address learning rate of the DUT.
1552
1553     **Deployment scenario**:
1554
1555     -  Physical → virtual switch → 2 x physical (one receiving, one listening).
1556
1557 .. 3.2.2.5
1558
1559 Coupling between control path and datapath Tests
1560 ------------------------------------------------
1561
1562 The following tests aim to determine how tightly coupled the datapath
1563 and the control path are within a virtual switch. The following list
1564 is not exhaustive but should indicate the type of tests that should be
1565 required. It is expected that more will be added.
1566
1567 .. 3.2.2.5.1
1568
1569 Test ID: LTD.CPDPCouplingFlowAddition
1570 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1571
1572     **Title**: Control Path and Datapath Coupling
1573
1574     **Prerequisite Test**:
1575
1576     **Priority**:
1577
1578     **Description**:
1579
1580     The aim of this test is to understand how exercising the DUT's control
1581     path affects datapath performance.
1582
1583     Initially a certain number of flow table entries are installed in the
1584     vSwitch. Then over the duration of an RFC2544 throughput test
1585     flow-entries are added and removed at the rates specified below. No
1586     traffic is 'hitting' these flow-entries, they are simply added and
1587     removed.
1588
1589     The test MUST be repeated with the following initial number of
1590     flow-entries installed: - < 10 - 1000 - 100,000 - 10,000,000 (or the
1591     maximum supported number of flow-entries)
1592
1593     The test MUST be repeated with the following rates of flow-entry
1594     addition and deletion per second: - 0 - 1 (i.e. 1 addition plus 1
1595     deletion) - 100 - 10,000
1596
1597     **Expected Result**:
1598
1599     **Metrics Collected**:
1600
1601     The following are the metrics collected for this test:
1602
1603     -  The maximum forwarding rate in Frames Per Second (FPS) and Mbps of
1604        the DUT.
1605     -  The average latency of the traffic flow when passing through the DUT
1606        (if testing for latency, note that this average is different from the
1607        test specified in Section 26.3 of
1608        `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__).
1609     -  CPU and memory utilization may also be collected as part of this
1610        test, to determine the vSwitch's performance footprint on the system.
1611
1612     **Deployment scenario**:
1613
1614     -  Physical → virtual switch → physical.
1615
1616 .. 3.2.2.6
1617
1618 CPU and memory consumption
1619 --------------------------
1620
1621 The following tests will profile a virtual switch's CPU and memory
1622 utilization under various loads and circumstances. The following
1623 list is not exhaustive but should indicate the type of tests that
1624 should be required. It is expected that more will be added.
1625
1626 .. 3.2.2.6.1
1627
1628 .. _CPU0PacketLoss:
1629
1630 Test ID: LTD.Stress.RFC2544.0PacketLoss
1631 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1632
1633     **Title**: RFC 2544 0% Loss CPU OR Memory Stress Test
1634
1635     **Prerequisite Test**:
1636
1637     **Priority**:
1638
1639     **Description**:
1640
1641     The aim of this test is to understand the overall performance of the
1642     system when a CPU or Memory intensive application is run on the same DUT as
1643     the Virtual Switch. For each frame size, an
1644     LTD.Throughput.RFC2544.PacketLossRatio (0% Packet Loss) test should be
1645     performed. Throughout the entire test a CPU or Memory intensive application
1646     should be run on all cores on the system not in use by the Virtual Switch.
1647     For NUMA system only cores on the same NUMA node are loaded.
1648
1649     It is recommended that stress-ng be used for loading the non-Virtual
1650     Switch cores but any stress tool MAY be used.
1651
1652     **Expected Result**:
1653
1654     **Metrics Collected**:
1655
1656     The following are the metrics collected for this test:
1657
1658     -  Memory and CPU utilization of the cores running the Virtual Switch.
1659     -  The number of identity of the cores allocated to the Virtual Switch.
1660     -  The configuration of the stress tool (for example the command line
1661        parameters used to start it.)
1662
1663     **Note:** Stress in the test ID can be replaced with the name of the
1664               component being stressed, when reporting the results:
1665               LTD.CPU.RFC2544.0PacketLoss or LTD.Memory.RFC2544.0PacketLoss
1666
1667 .. 3.2.2.7
1668
1669 Summary List of Tests
1670 ---------------------
1671
1672 1. Throughput tests
1673
1674   - Test ID: LTD.Throughput.RFC2544.PacketLossRatio
1675   - Test ID: LTD.Throughput.RFC2544.PacketLossRatioFrameModification
1676   - Test ID: LTD.Throughput.RFC2544.Profile
1677   - Test ID: LTD.Throughput.RFC2544.SystemRecoveryTime
1678   - Test ID: LTD.Throughput.RFC2544.BackToBackFrames
1679   - Test ID: LTD.Throughput.RFC2889.Soak
1680   - Test ID: LTD.Throughput.RFC2889.SoakFrameModification
1681   - Test ID: LTD.Throughput.RFC6201.ResetTime
1682   - Test ID: LTD.Throughput.RFC2889.MaxForwardingRate
1683   - Test ID: LTD.Throughput.RFC2889.ForwardPressure
1684   - Test ID: LTD.Throughput.RFC2889.ErrorFramesFiltering
1685   - Test ID: LTD.Throughput.RFC2889.BroadcastFrameForwarding
1686   - Test ID: LTD.Throughput.RFC2544.WorstN-BestN
1687   - Test ID: LTD.Throughput.Overlay.Network.<tech>.RFC2544.PacketLossRatio
1688
1689 2. Packet Latency tests
1690
1691   - Test ID: LTD.PacketLatency.InitialPacketProcessingLatency
1692   - Test ID: LTD.PacketDelayVariation.RFC3393.Soak
1693
1694 3. Scalability tests
1695
1696   - Test ID: LTD.Scalability.Flows.RFC2544.0PacketLoss
1697   - Test ID: LTD.MemoryBandwidth.RFC2544.0PacketLoss.Scalability
1698   - LTD.Scalability.VNF.RFC2544.PacketLossProfile
1699   - LTD.Scalability.VNF.RFC2544.PacketLossRatio
1700
1701 4. Activation tests
1702
1703   - Test ID: LTD.Activation.RFC2889.AddressCachingCapacity
1704   - Test ID: LTD.Activation.RFC2889.AddressLearningRate
1705
1706 5. Coupling between control path and datapath Tests
1707
1708   - Test ID: LTD.CPDPCouplingFlowAddition
1709
1710 6. CPU and memory consumption
1711
1712   - Test ID: LTD.Stress.RFC2544.0PacketLoss