<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-bmwg-ngfw-performance-15" indexInclude="true" ipr="trust200902" number="9411" obsoletes="3511" prepTime="2023-03-09T21:56:30" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bmwg-ngfw-performance-15" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9411" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Benchmarking Network Security Devices">Benchmarking Methodology for Network Security Device Performance</title>
    <seriesInfo name="RFC" value="9411" stream="IETF"/>
    <author fullname="Balamuhunthan Balarajah" initials="B" surname="Balarajah">
      <organization showOnFrontPage="true"/>
      <address>
        <postal>
          <street/>
          <city>Berlin</city>
          <code/>
          <region/>
          <country>Germany</country>
        </postal>
        <phone/>
        <email>bm.balarajah@gmail.com</email>
      </address>
    </author>
    <author fullname="Carsten Rossenhoevel" initials="C" surname="Rossenhoevel">
      <organization showOnFrontPage="true">EANTC AG</organization>
      <address>
        <postal>
          <street>Salzufer 14</street>
          <city>Berlin</city>
          <code>10587</code>
          <region/>
          <country>Germany</country>
        </postal>
        <phone/>
        <email>cross@eantc.de</email>
      </address>
    </author>
    <author fullname="Brian Monkman" initials="B" surname="Monkman">
      <organization showOnFrontPage="true">NetSecOPEN</organization>
      <address>
        <postal>
          <street>417 Independence Court</street>
          <city>Mechanicsburg</city>
          <code>17050</code>
          <region>PA</region>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>bmonkman@netsecopen.org</email>
      </address>
    </author>
    <date month="03" year="2023"/>
    <area>ops</area>
    <workgroup>bmwg</workgroup>
    <keyword>NGFW</keyword>
    <keyword>NGIPS</keyword>
    <keyword>benchmarking</keyword>
    <keyword>performance testing</keyword>
    <keyword>security testing</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document provides benchmarking terminology and methodology for
      next-generation network security devices, including next-generation
      firewalls (NGFWs) and next-generation intrusion prevention systems
      (NGIPSs). The main areas covered in this document are test terminology,
      test configuration parameters, and benchmarking methodology for NGFWs and
      NGIPSs. (It is assumed that readers have a working knowledge of these
      devices and the security functionality they contain.) This document aims
      to improve the applicability, reproducibility, and transparency of
      benchmarks and to align the test methodology with today's increasingly
      complex layer 7 security-centric network application use cases. As a
      result, this document makes RFC 3511 obsolete.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9411" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scope">Scope</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-setup">Test Setup</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-testbed-configuration">Testbed Configuration</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dut-sut-configuration">DUT/SUT Configuration</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-effectiveness-conf">Security Effectiveness Configuration</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-equipment-configuratio">Test Equipment Configuration</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client-configuration">Client Configuration</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-backend-server-configuratio">Backend Server Configuration</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.3.1"><xref derivedContent="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-traffic-flow-definition">Traffic Flow Definition</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.4.1"><xref derivedContent="4.3.4" format="counter" sectionFormat="of" target="section-4.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-traffic-load-profile">Traffic Load Profile</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-testbed-considerations">Testbed Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reporting">Reporting</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction-2">Introduction</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-detailed-test-results">Detailed Test Results</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-benchmarks-and-key-performa">Benchmarks and Key Performance Indicators</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-benchmarking-tests">Benchmarking Tests</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-throughput-performance-with">Throughput Performance with Application Traffic Mix</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.1.2">
                  <li pn="section-toc.1-1.7.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.1.1"><xref derivedContent="7.1.1" format="counter" sectionFormat="of" target="section-7.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-objective">Objective</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.2.1"><xref derivedContent="7.1.2" format="counter" sectionFormat="of" target="section-7.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-setup-2">Test Setup</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.3.1"><xref derivedContent="7.1.3" format="counter" sectionFormat="of" target="section-7.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-parameters">Test Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.4.1"><xref derivedContent="7.1.4" format="counter" sectionFormat="of" target="section-7.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-procedures-and-expecte">Test Procedures and Expected Results</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tcp-connections-per-second-">TCP Connections Per Second with HTTP Traffic</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.2.2">
                  <li pn="section-toc.1-1.7.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.1.1"><xref derivedContent="7.2.1" format="counter" sectionFormat="of" target="section-7.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-objective-2">Objective</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.2.1"><xref derivedContent="7.2.2" format="counter" sectionFormat="of" target="section-7.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-setup-3">Test Setup</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.3.1"><xref derivedContent="7.2.3" format="counter" sectionFormat="of" target="section-7.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-parameters-2">Test Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.4.1"><xref derivedContent="7.2.4" format="counter" sectionFormat="of" target="section-7.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-procedures-and-expected">Test Procedures and Expected Results</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-http-throughput">HTTP Throughput</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.3.2">
                  <li pn="section-toc.1-1.7.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.1.1"><xref derivedContent="7.3.1" format="counter" sectionFormat="of" target="section-7.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-objective-3">Objective</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.2.1"><xref derivedContent="7.3.2" format="counter" sectionFormat="of" target="section-7.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-setup-4">Test Setup</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.3.1"><xref derivedContent="7.3.3" format="counter" sectionFormat="of" target="section-7.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-parameters-3">Test Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.4.1"><xref derivedContent="7.3.4" format="counter" sectionFormat="of" target="section-7.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-procedures-and-expected-">Test Procedures and Expected Results</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-http-transaction-latency">HTTP Transaction Latency</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.4.2">
                  <li pn="section-toc.1-1.7.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.4.2.1.1"><xref derivedContent="7.4.1" format="counter" sectionFormat="of" target="section-7.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-objective-4">Objective</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.4.2.2.1"><xref derivedContent="7.4.2" format="counter" sectionFormat="of" target="section-7.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-setup-5">Test Setup</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.4.2.3.1"><xref derivedContent="7.4.3" format="counter" sectionFormat="of" target="section-7.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-parameters-4">Test Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.4.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.4.2.4.1"><xref derivedContent="7.4.4" format="counter" sectionFormat="of" target="section-7.4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-procedures-and-expected-r">Test Procedures and Expected Results</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-concurrent-tcp-connection-c">Concurrent TCP Connection Capacity with HTTP Traffic</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.5.2">
                  <li pn="section-toc.1-1.7.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.5.2.1.1"><xref derivedContent="7.5.1" format="counter" sectionFormat="of" target="section-7.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-objective-5">Objective</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.5.2.2.1"><xref derivedContent="7.5.2" format="counter" sectionFormat="of" target="section-7.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-setup-6">Test Setup</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.5.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.5.2.3.1"><xref derivedContent="7.5.3" format="counter" sectionFormat="of" target="section-7.5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-parameters-5">Test Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.5.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.5.2.4.1"><xref derivedContent="7.5.4" format="counter" sectionFormat="of" target="section-7.5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-procedures-and-expected-re">Test Procedures and Expected Results</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.6">
                <t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent="7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tcp-or-quic-connections-per">TCP or QUIC Connections per Second with HTTPS Traffic</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.6.2">
                  <li pn="section-toc.1-1.7.2.6.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.6.2.1.1"><xref derivedContent="7.6.1" format="counter" sectionFormat="of" target="section-7.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-objective-6">Objective</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.6.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.6.2.2.1"><xref derivedContent="7.6.2" format="counter" sectionFormat="of" target="section-7.6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-setup-7">Test Setup</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.6.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.6.2.3.1"><xref derivedContent="7.6.3" format="counter" sectionFormat="of" target="section-7.6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-parameters-6">Test Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.6.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.6.2.4.1"><xref derivedContent="7.6.4" format="counter" sectionFormat="of" target="section-7.6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-procedures-and-expected-res">Test Procedures and Expected Results</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.7">
                <t indent="0" pn="section-toc.1-1.7.2.7.1"><xref derivedContent="7.7" format="counter" sectionFormat="of" target="section-7.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-https-throughput">HTTPS Throughput</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.7.2">
                  <li pn="section-toc.1-1.7.2.7.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.7.2.1.1"><xref derivedContent="7.7.1" format="counter" sectionFormat="of" target="section-7.7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-objective-7">Objective</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.7.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.7.2.2.1"><xref derivedContent="7.7.2" format="counter" sectionFormat="of" target="section-7.7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-setup-8">Test Setup</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.7.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.7.2.3.1"><xref derivedContent="7.7.3" format="counter" sectionFormat="of" target="section-7.7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-parameters-7">Test Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.7.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.7.2.4.1"><xref derivedContent="7.7.4" format="counter" sectionFormat="of" target="section-7.7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-procedures-and-expected-resu">Test Procedures and Expected Results</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.8">
                <t indent="0" pn="section-toc.1-1.7.2.8.1"><xref derivedContent="7.8" format="counter" sectionFormat="of" target="section-7.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-https-transaction-latency">HTTPS Transaction Latency</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.8.2">
                  <li pn="section-toc.1-1.7.2.8.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.8.2.1.1"><xref derivedContent="7.8.1" format="counter" sectionFormat="of" target="section-7.8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-objective-8">Objective</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.8.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.8.2.2.1"><xref derivedContent="7.8.2" format="counter" sectionFormat="of" target="section-7.8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-setup-9">Test Setup</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.8.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.8.2.3.1"><xref derivedContent="7.8.3" format="counter" sectionFormat="of" target="section-7.8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-parameters-8">Test Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.8.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.8.2.4.1"><xref derivedContent="7.8.4" format="counter" sectionFormat="of" target="section-7.8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-procedures-and-expected-resul">Test Procedures and Expected Results</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.9">
                <t indent="0" pn="section-toc.1-1.7.2.9.1"><xref derivedContent="7.9" format="counter" sectionFormat="of" target="section-7.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-concurrent-tcp-or-quic-conn">Concurrent TCP  or QUIC Connection Capacity with HTTPS Traffic</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.9.2">
                  <li pn="section-toc.1-1.7.2.9.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.9.2.1.1"><xref derivedContent="7.9.1" format="counter" sectionFormat="of" target="section-7.9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-objective-9">Objective</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.9.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.9.2.2.1"><xref derivedContent="7.9.2" format="counter" sectionFormat="of" target="section-7.9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-setup-10">Test Setup</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.9.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.9.2.3.1"><xref derivedContent="7.9.3" format="counter" sectionFormat="of" target="section-7.9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-parameters-9">Test Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.9.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.9.2.4.1"><xref derivedContent="7.9.4" format="counter" sectionFormat="of" target="section-7.9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-procedures-and-expected-result">Test Procedures and Expected Results</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-methodology-security-e">Test Methodology - Security Effectiveness Evaluation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-objective">Test Objective</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-testbed-setup">Testbed Setup</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.3">
                <t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-parameters-10">Test Parameters</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2.3.2">
                  <li pn="section-toc.1-1.11.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.11.2.3.2.1.1"><xref derivedContent="A.3.1" format="counter" sectionFormat="of" target="section-appendix.a.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dut-sut-configuration-parameters-5">DUT/SUT Configuration Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.11.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.11.2.3.2.2.1"><xref derivedContent="A.3.2" format="counter" sectionFormat="of" target="section-appendix.a.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-equipment-configuration-parame-3">Test Equipment Configuration Parameters</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.11.2.4">
                <t indent="0" pn="section-toc.1-1.11.2.4.1"><xref derivedContent="A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-results-validation-criteria-5">Test Results Validation Criteria</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.5">
                <t indent="0" pn="section-toc.1-1.11.2.5.1"><xref derivedContent="A.5" format="counter" sectionFormat="of" target="section-appendix.a.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-measurement-10">Measurement</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.6">
                <t indent="0" pn="section-toc.1-1.11.2.6.1"><xref derivedContent="A.6" format="counter" sectionFormat="of" target="section-appendix.a.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-procedures-and-expected-result-2">Test Procedures and Expected Results</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2.6.2">
                  <li pn="section-toc.1-1.11.2.6.2.1">
                    <t indent="0" pn="section-toc.1-1.11.2.6.2.1.1"><xref derivedContent="A.6.1" format="counter" sectionFormat="of" target="section-appendix.a.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-step-1-background-traffic">Step 1: Background Traffic</xref></t>
                  </li>
                  <li pn="section-toc.1-1.11.2.6.2.2">
                    <t indent="0" pn="section-toc.1-1.11.2.6.2.2.1"><xref derivedContent="A.6.2" format="counter" sectionFormat="of" target="section-appendix.a.6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-step-2-cve-emulation">Step 2: CVE Emulation</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dut-sut-classification">DUT/SUT Classification</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">It has been 18 years since the IETF initially recommended test
      methodology and terminology for firewalls <xref target="RFC3511" format="default" sectionFormat="of" derivedContent="RFC3511"/>.
      Firewalls have evolved significantly from the days of simple access control list (ACL)
      filters. As the underlying technology progresses and improves,
      recommending test methodology and terminology for firewalls,
      requirements, and expectations for network security elements has
      increased tremendously. Security function implementations have evolved
      and diversified into intrusion detection and prevention, threat
      management, analysis of encrypted traffic, and more. In an industry of
      growing importance, well-defined and reproducible key performance
      indicators (KPIs) are increasingly needed to enable fair and reasonable
      comparisons of network security functions. These reasons led to the
      creation of a new next-generation network security device benchmarking
      document, which makes <xref target="RFC3511" format="default" sectionFormat="of" derivedContent="RFC3511"/> obsolete. The measurement of
      performance for processing IP-fragmented traffic (see 
      <xref target="RFC3511" sectionFormat="of" section="5.9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3511#section-5.9" derivedContent="RFC3511"/>)is not included in this document since IP
      fragmentation does not commonly occur in traffic anymore, unlike how
      it might have at the time when <xref target="RFC3511" format="default" sectionFormat="of" derivedContent="RFC3511"/> was
      written. It should also be noted that <xref target="RFC2647" format="default" sectionFormat="of" derivedContent="RFC2647"/> retains
      significant value and was consulted frequently while creating this
      document.</t>
      <t indent="0" pn="section-1-2">For a more detailed explanation of what an NGFW is, see the Wikipedia
      article <xref target="Wiki-NGFW" format="default" sectionFormat="of" derivedContent="Wiki-NGFW"/>.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-scope">Scope</name>
      <t indent="0" pn="section-3-1">This document provides testing terminology and testing methodology
      for modern and next-generation network security devices that are
      configured in Active ("Inline", see Figures <xref target="figure1" format="counter" sectionFormat="of" derivedContent="1"/> and <xref target="figure2" format="counter" sectionFormat="of" derivedContent="2"/>) mode. It covers the validation of security
      effectiveness configurations of network security devices, followed by
      performance benchmark testing. This document focuses on advanced,
      realistic, and reproducible testing methods. Additionally, it describes
      testbed environments, test tool requirements, and test result
      formats.</t>
      <t indent="0" pn="section-3-2">The performance testing methodology described in this document is not
      intended for security devices or systems that rely on machine learning or
      behavioral analysis. If such features are present in a Device Under
      Test / System Under Test (DUT/SUT), they should be disabled.</t>
    </section>
    <section anchor="Test_Setup" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-test-setup">Test Setup</name>
      <t indent="0" pn="section-4-1">The test setup defined in this document applies to all benchmarking
      tests described in <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/>. The
      test setup <bcp14>MUST</bcp14> be contained within an isolated test environment (see
      <xref target="RFC6815" sectionFormat="of" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6815#section-3" derivedContent="RFC6815"/>).</t>
      <section anchor="Testbed_Configuration" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-testbed-configuration">Testbed Configuration</name>
        <t indent="0" pn="section-4.1-1">Testbed configuration <bcp14>MUST</bcp14> ensure that any performance implications
        that are discovered during the benchmark testing aren't due to the
        inherent physical network limitations, such as the number of physical
        links and forwarding performance capabilities (throughput and latency)
        of the network devices in the testbed. For this reason, this document
        recommends avoiding external devices, such as switches and routers, in
        the testbed wherever possible.</t>
        <t indent="0" pn="section-4.1-2">In some deployment scenarios, the network security devices
        (DUT/SUT) are connected to routers and switches, which will reduce the
        number of entries in MAC (Media Access Control) or Address Resolution Protocol /
        Neighbor Discovery (ARP/ND) tables of the DUT/SUT. If MAC or ARP/ND tables
        have many entries, this may impact the actual DUT/SUT performance due
        to MAC and ARP/ND table lookup processes. This document also
        recommends using test equipment with the capability of emulating layer
        3 routing functionality instead of adding external routers in the
        testbed.</t>
        <t indent="0" pn="section-4.1-3">The testbed setup for Option 1 (<xref target="figure1" format="default" sectionFormat="of" derivedContent="Figure 1"/>) is the
        <bcp14>RECOMMENDED</bcp14> testbed setup for the benchmarking test.</t>
        <figure anchor="figure1" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-testbed-setup-option-1">Testbed Setup - Option 1</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.1-4.1">
+-----------------------+                   +-----------------------+
| +-------------------+ |   +-----------+   | +-------------------+ |
| | Emulated Router(s)| |   |           |   | | Emulated Router(s)| |
| |    (Optional)     | +----- DUT/SUT  +-----+    (Optional)     | |
| +-------------------+ |   |           |   | +-------------------+ |
| +-------------------+ |   +-----------+   | +-------------------+ |
| |     Clients       | |                   | |      Servers      | |
| +-------------------+ |                   | +-------------------+ |
|                       |                   |                       |
|   Test Equipment      |                   |   Test Equipment      |
+-----------------------+                   +-----------------------+</artwork>
        </figure>
        <t indent="0" pn="section-4.1-5">If the test equipment used is not capable of emulating OSI layer 3
        routing functionality or if the number of used ports is mismatched
        between the test equipment and the DUT/SUT (which is needed for test equipment
        port aggregation), the test setup can be configured as shown in <xref target="figure2" format="default" sectionFormat="of" derivedContent="Figure 2"/>.</t>
        <figure anchor="figure2" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-testbed-setup-option-2">Testbed Setup - Option 2</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.1-6.1">
 +-------------------+      +-----------+      +--------------------+
 |Aggregation Switch/|      |           |      | Aggregation Switch/|
 | Router            +------+  DUT/SUT  +------+ Router             |
 |                   |      |           |      |                    |
 +----------+--------+      +-----------+      +--------+-----------+
            |                                           |
            |                                           |
+-----------+-----------+                   +-----------+-----------+
|                       |                   |                       |
| +-------------------+ |                   | +-------------------+ |
| | Emulated Router(s)| |                   | | Emulated Router(s)| |
| |     (Optional)    | |                   | |     (Optional)    | |
| +-------------------+ |                   | +-------------------+ |
| +-------------------+ |                   | +-------------------+ |
| |      Clients      | |                   | |      Servers      | |
| +-------------------+ |                   | +-------------------+ |
|                       |                   |                       |
|    Test Equipment     |                   |    Test Equipment     |
+-----------------------+                   +-----------------------+</artwork>
        </figure>
      </section>
      <section anchor="DUT-SUT_Configuration" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-dut-sut-configuration">DUT/SUT Configuration</name>
        <t indent="0" pn="section-4.2-1">The same DUT/SUT configuration <bcp14>MUST</bcp14> be used for all benchmarking
        tests described in <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/>. Since each DUT/SUT
        will have its own unique configuration, users <bcp14>MUST</bcp14> configure their
        devices with the same parameters and security features that would be
        used in the actual deployment of the device or a typical deployment.
        The DUT/SUT <bcp14>MUST</bcp14> be configured in "Inline" mode so that the traffic is
        actively inspected by the DUT/SUT.</t>
        <t indent="0" pn="section-4.2-2">Tables <xref target="NGFW_Security_Features" format="counter" sectionFormat="of" derivedContent="2"/> and <xref target="NGIPS_Security_Features" format="counter" sectionFormat="of" derivedContent="3"/> below describe the <bcp14>RECOMMENDED</bcp14> and
        <bcp14>OPTIONAL</bcp14> sets of network security features for NGFWs and NGIPSs,
        respectively. If the recommended security features are not enabled in
        the DUT/SUT for any reason, the reason <bcp14>MUST</bcp14> be reported with the
        benchmarking test results. For example, one reason for not enabling
        the anti-virus feature in an NGFW may be that this security feature was
        not required for a particular customer deployment scenario. It <bcp14>MUST</bcp14> be
        also noted in the benchmarking test report that not enabling the
        specific recommended security features may impact the performance of
        the DUT/SUT. The selected security features <bcp14>MUST</bcp14> be consistently
        enabled on the DUT/SUT for all benchmarking tests described in <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/>.</t>
        <t indent="0" pn="section-4.2-3">To improve repeatability, a summary of the DUT/SUT configuration,
        including a description of all enabled DUT/SUT features, <bcp14>MUST</bcp14> be
        published with the benchmarking results.</t>
        <t indent="0" pn="section-4.2-4">The following table provides a brief description of the security
        feature; these are approximate taxonomies of features commonly
        found in currently deployed NGFWs and NGIPSs. The features provided by
        specific implementations may be named differently and not necessarily
        have configuration settings that align with the taxonomy.</t>
        <table anchor="Security_Feature_Description" align="center" pn="table-1">
          <name slugifiedName="name-security-feature-descriptio">Security Feature Description</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">DUT/SUT Features</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">TLS Inspection</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT intercepts and decrypts inbound HTTPS traffic between
          servers and clients. Once the content inspection has been completed,
          the DUT/SUT encrypts the HTTPS traffic with ciphers and keys used by the
          clients and servers. For TLS 1.3, the DUT works as a middlebox
          (proxy) and holds the certificates and Pre-Shared Keys (PSKs) that
          are trusted by the client and represent the identity of the real
          server.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">IDS/IPS</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT detects and blocks exploits targeting known and
	  unknown vulnerabilities across the monitored network.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Malware</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT detects and prevents the transmission of malicious
          executable code and any associated communications across the
          monitored network. This includes data exfiltration as well as
          command and control channels.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Spyware</td>
              <td align="left" colspan="1" rowspan="1">Anti-Spyware is a subcategory of Anti-Malware. Spyware transmits
          information without the user's knowledge or permission. The DUT/SUT
          detects and blocks the initial infection or transmission of data.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Botnet</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT detects and blocks traffic to or from botnets.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Evasion</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT detects and mitigates attacks that have been obfuscated
          in some manner.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Web Filtering</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT detects and blocks malicious websites, including defined
          classifications of websites across the monitored network.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Data Loss Protection (DLP)</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT detects and prevents data breaches and data exfiltration,
          or it detects and blocks the transmission of sensitive data across
          the monitored network.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Certificate Validation</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT validates certificates used in encrypted communications
          across the monitored network.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Logging and Reporting</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT logs and reports all traffic at the flow level across the
          monitored network.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Application Identification</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT detects known applications as defined within the traffic
          mix selected across the monitored network.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Deep Packet Inspection (DPI)</td>
              <td align="left" colspan="1" rowspan="1">The DUT/SUT inspects the content of the data packet.</td>
            </tr>
          </tbody>
        </table>
        <table anchor="NGFW_Security_Features" align="center" pn="table-2">
          <name slugifiedName="name-ngfw-security-features">NGFW Security Features</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">DUT/SUT (NGFW) Features</th>
              <th align="center" colspan="1" rowspan="1">
                <bcp14>RECOMMENDED</bcp14></th>
              <th align="center" colspan="1" rowspan="1">
                <bcp14>OPTIONAL</bcp14></th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">TLS Inspection</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">IDS/IPS</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Spyware</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Virus</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Botnet</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Evasion</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Web Filtering</td>
              <td align="center" colspan="1" rowspan="1"/>
              <td align="center" colspan="1" rowspan="1">x</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Data Loss Protection (DLP)</td>
              <td align="center" colspan="1" rowspan="1"/>
              <td align="center" colspan="1" rowspan="1">x</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">DDoS Protection</td>
              <td align="center" colspan="1" rowspan="1"/>
              <td align="center" colspan="1" rowspan="1">x</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Certificate Validation</td>
              <td align="center" colspan="1" rowspan="1"/>
              <td align="center" colspan="1" rowspan="1">x</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Application Identification</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
          </tbody>
        </table>
        <table anchor="NGIPS_Security_Features" align="center" pn="table-3">
          <name slugifiedName="name-ngips-security-features">NGIPS Security Features</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">DUT/SUT (NGIPS) Features</th>
              <th align="center" colspan="1" rowspan="1">
                <bcp14>RECOMMENDED</bcp14></th>
              <th align="center" colspan="1" rowspan="1">
                <bcp14>OPTIONAL</bcp14></th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">TLS Inspection</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Malware</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Spyware</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Botnet</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Application Identification</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Deep Packet Inspection (DPI)</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Anti-Evasion</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"/>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-4.2-8">Note: With respect to TLS Inspection, there are scenarios where it
        will be optional.</t>
        <t indent="0" pn="section-4.2-9">Below is a summary of the DUT/SUT configuration:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2-10">
          <li pn="section-4.2-10.1">The DUT/SUT <bcp14>MUST</bcp14> be configured in "Inline" mode.</li>
          <li pn="section-4.2-10.2">"Fail-Open" behavior <bcp14>MUST</bcp14> be disabled.</li>
          <li pn="section-4.2-10.3">All <bcp14>RECOMMENDED</bcp14> security features are enabled.</li>
          <li pn="section-4.2-10.4">Logging and reporting <bcp14>MUST</bcp14> be enabled. The DUT/SUT <bcp14>SHOULD</bcp14> log all
            traffic at the flow level (5-tuple). If the DUT/SUT is designed to
            log all traffic at different levels (e.g., IP packet levels), it is
            acceptable to conduct tests. However, this <bcp14>MUST</bcp14> be noted in the
            test report. Logging to an external device is
            permissible.</li>
          <li pn="section-4.2-10.5">Geographical location filtering <bcp14>SHOULD</bcp14> be configured. If the
            DUT/SUT is not designed to perform geographical location
            filtering, it is acceptable to conduct tests without this feature.
            However, this <bcp14>MUST</bcp14> be noted in the test report.</li>
          <li pn="section-4.2-10.6">Application Identification and Control <bcp14>MUST</bcp14> be configured to
            trigger applications from the defined traffic mix.</li>
        </ul>
        <t indent="0" pn="section-4.2-11">In addition, a realistic number of access control lists (ACLs)
        <bcp14>SHOULD</bcp14> be configured on the DUT/SUT where ACLs are configurable and
        reasonable based on the deployment scenario. For example, it is
        acceptable not to configure ACLs in an NGIPS since NGIPS devices do
        not require the use of ACLs in most deployment scenarios. This
        document determines the number of access policy rules for four
        different classes of the DUT/SUT: Extra Small (XS), Small (S), Medium (M),
        and Large (L). A sample DUT/SUT classification is described in <xref target="DUT-Classification" format="default" sectionFormat="of" derivedContent="Appendix B"/>.</t>
        <t indent="0" pn="section-4.2-12">The ACLs defined in <xref target="figure3" format="default" sectionFormat="of" derivedContent="Table 4"/>
          <bcp14>MUST</bcp14> be configured from top to bottom in the correct order, as shown in
        the table. This is due to ACL types listed in specificity-decreasing
        order, with "block" first, followed by "allow", representing a typical
        ACL-based security policy. The ACL entries <bcp14>MUST</bcp14> be configured with
        routable IP prefixes by the DUT/SUT, where applicable. (Note: There
        will be differences between how security vendors implement ACL
        decision making.) The configured ACL <bcp14>MUST NOT</bcp14> block the test traffic
        used for the benchmarking tests.</t>
        <table anchor="figure3" align="center" pn="table-4">
          <name slugifiedName="name-dut-sut-access-list">DUT/SUT Access List</name>
          <thead>
            <tr>
              <th rowspan="1" colspan="4" align="left"/>
              <th rowspan="1" colspan="4" align="left">DUT/SUT Classification # Rules</th>
            </tr>
            <tr>
              <th align="left" colspan="1" rowspan="1">Rules Type</th>
              <th align="left" colspan="1" rowspan="1">Match Criteria</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Action</th>
              <th align="left" colspan="1" rowspan="1">XS</th>
              <th align="left" colspan="1" rowspan="1">S</th>
              <th align="left" colspan="1" rowspan="1">M</th>
              <th align="left" colspan="1" rowspan="1">L</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">Application layer</td>
              <td align="left" colspan="1" rowspan="1">Application</td>
              <td align="left" colspan="1" rowspan="1">Any application not included in the measurement traffic</td>
              <td align="left" colspan="1" rowspan="1">block</td>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">10</td>
              <td align="left" colspan="1" rowspan="1">20</td>
              <td align="left" colspan="1" rowspan="1">50</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Transport layer</td>
              <td align="left" colspan="1" rowspan="1">SRC IP and TCP/UDP DST ports</td>
              <td align="left" colspan="1" rowspan="1">Any SRC IP prefix used and any DST ports not used in the measurement traffic</td>
              <td align="left" colspan="1" rowspan="1">block</td>
              <td align="left" colspan="1" rowspan="1">25</td>
              <td align="left" colspan="1" rowspan="1">50</td>
              <td align="left" colspan="1" rowspan="1">100</td>
              <td align="left" colspan="1" rowspan="1">250</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">IP layer</td>
              <td align="left" colspan="1" rowspan="1">SRC/DST IP</td>
              <td align="left" colspan="1" rowspan="1">Any SRC/DST IP subnet not used in the measurement traffic</td>
              <td align="left" colspan="1" rowspan="1">block</td>
              <td align="left" colspan="1" rowspan="1">25</td>
              <td align="left" colspan="1" rowspan="1">50</td>
              <td align="left" colspan="1" rowspan="1">100</td>
              <td align="left" colspan="1" rowspan="1">250</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Application layer</td>
              <td align="left" colspan="1" rowspan="1">Application</td>
              <td align="left" colspan="1" rowspan="1">Half of the applications included in the measurement traffic (see the note below)</td>
              <td align="left" colspan="1" rowspan="1">allow</td>
              <td align="left" colspan="1" rowspan="1">10</td>
              <td align="left" colspan="1" rowspan="1">10</td>
              <td align="left" colspan="1" rowspan="1">10</td>
              <td align="left" colspan="1" rowspan="1">10</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Transport layer</td>
              <td align="left" colspan="1" rowspan="1">SRC IP and TCP/UDP DST ports</td>
              <td align="left" colspan="1" rowspan="1">Half of the SRC IPs used and any DST ports used in the measurement traffic (one rule per subnet)</td>
              <td align="left" colspan="1" rowspan="1">allow</td>
              <td align="left" colspan="1" rowspan="1">&gt;1</td>
              <td align="left" colspan="1" rowspan="1">&gt;1</td>
              <td align="left" colspan="1" rowspan="1">&gt;1</td>
              <td align="left" colspan="1" rowspan="1">&gt;1</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">IP layer</td>
              <td align="left" colspan="1" rowspan="1">SRC IP</td>
              <td align="left" colspan="1" rowspan="1">The rest of the SRC IP prefix range used in the measurement traffic (one rule per subnet)</td>
              <td align="left" colspan="1" rowspan="1">allow</td>
              <td align="left" colspan="1" rowspan="1">&gt;1</td>
              <td align="left" colspan="1" rowspan="1">&gt;1</td>
              <td align="left" colspan="1" rowspan="1">&gt;1</td>
              <td align="left" colspan="1" rowspan="1">&gt;1</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-4.2-14">Note 1: Based on the test customer's specific use case, the testers
        can increase the number of rules.</t>
        <t indent="0" pn="section-4.2-15">Note 2: If half of the applications included in the test traffic are
        less than 10, the missing number of ACL entries (placeholder rules) can be
        configured for any application traffic not included in the test
        traffic.</t>
        <t indent="0" pn="section-4.2-16">Note 3: In the event that the DUT/SUT is designed to not use ACLs, it is
        acceptable to conduct tests without them. However, this <bcp14>MUST</bcp14> be noted
        in the test report.</t>
        <section anchor="security_effectiveness" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-security-effectiveness-conf">Security Effectiveness Configuration</name>
          <t indent="0" pn="section-4.2.1-1">The selected security features (defined in Tables <xref target="NGFW_Security_Features" format="counter" sectionFormat="of" derivedContent="2"/> and <xref target="NGIPS_Security_Features" format="counter" sectionFormat="of" derivedContent="3"/>) of the DUT/SUT <bcp14>MUST</bcp14> be
          configured effectively to detect, prevent, and report the defined
          security vulnerability sets. This section defines the selection of
          the security vulnerability sets from the Common Vulnerabilities and
          Exposures (CVEs) list <xref target="CVE" format="default" sectionFormat="of" derivedContent="CVE"/> for testing. The vulnerability set should
          reflect a minimum of 500 CVEs from no older than 10 calendar years
          to the current year. These CVEs should be selected with a focus on
          in-use software commonly found in business applications, with a
          Common Vulnerability Scoring System (CVSS) Severity of High
          (7-10).</t>
          <t indent="0" pn="section-4.2.1-2">This document is primarily focused on performance benchmarking.
          However, it is <bcp14>RECOMMENDED</bcp14> to validate the security features
          configuration of the DUT/SUT by evaluating the security
          effectiveness as a prerequisite for performance benchmarking tests
          defined in <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/>. In case the benchmarking tests are performed
          without evaluating security effectiveness, the test report <bcp14>MUST</bcp14>
          explain the implications of this. The methodology for evaluating
          security effectiveness is defined in <xref target="Test-Methodology-Security-Effectiveness-Evaluation" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
        </section>
      </section>
      <section anchor="Test_Equipment_Configuration" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-test-equipment-configuratio">Test Equipment Configuration</name>
        <t indent="0" pn="section-4.3-1">In general, test equipment allows configuring parameters in
        different protocol layers. Extensive proof-of-concept tests conducted
        to support preparation of this document showed that benchmarking
        results are strongly affected by the choice of protocol stack
        parameters, especially OSI layer 4 transport protocol parameters. For
        more information on how TCP and QUIC parameters will impact
        performance, review <xref target="fastly" format="default" sectionFormat="of" derivedContent="fastly"/>. To achieve reproducible
        results that will be representative of real deployment scenarios,
        careful specification and documentation of the parameters are
        required.</t>
        <t indent="0" pn="section-4.3-2">This section specifies common test equipment configuration
        parameters applicable for all benchmarking tests defined in <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/>. Any benchmarking-test-specific
        parameters are described under the test setup section of each
        benchmarking test individually.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3.1">
          <name slugifiedName="name-client-configuration">Client Configuration</name>
          <t indent="0" pn="section-4.3.1-1">This section specifies which parameters should be considered
          while configuring emulated client endpoints in the test equipment.
          Also, this section specifies the <bcp14>RECOMMENDED</bcp14> values for certain
          parameters. The values are the defaults typically used in most of
          the client operating system types.</t>
          <t indent="0" pn="section-4.3.1-2">Pre-standard evaluations have shown that it is possible to set a
          wide range of arbitrary parameters for OSI layer 4 transport
          protocols on test equipment leading to optimization of client-specific results;
          however, only well-defined common parameter sets help
          to establish meaningful and comparable benchmarking results. For
          these reasons, this document recommends specific sets of transport
          protocol parameters to be configured on test equipment used for
          benchmarking.</t>
          <section anchor="TCP_Stack_client" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.3.1.1">
            <name slugifiedName="name-tcp-stack-attributes">TCP Stack Attributes</name>
            <t indent="0" pn="section-4.3.1.1-1">The TCP stack of the emulated client endpoints
            <bcp14>MUST</bcp14> fulfill the TCP requirements defined in <xref target="RFC9293" sectionFormat="of" section="B" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9293#appendix-B" derivedContent="RFC9293"/>. In addition,
            this section specifies the <bcp14>RECOMMENDED</bcp14> values for
            TCP parameters configured using the parameters described below.</t>
            <t indent="0" pn="section-4.3.1.1-2">The IPv4 and IPv6 Maximum Segment Sizes (MSSs) are set to 1460
            bytes and 1440 bytes, respectively. TX and RX initial receive
            window sizes are set to 65535 bytes. The client's initial
            congestion window should not exceed 10 times the MSS. Delayed ACKs
            are permitted, and the maximum client delayed ACK should not exceed
            10 times of the MSS before a forced ACK; also, the maximum delayed
            ACK timer is allowed to be set to 200 ms. Up to three retries are
            allowed before a timeout event is declared. The TCP PSH flag is set to
            high in all traffic. The source port range is  1024-65535.
	    The clients initiate TCP connections via a three-way
            handshake (SYN, SYN/ACK, ACK) and close TCP connections via either
            a TCP three-way close (FIN, FIN/ACK, ACK) or a TCP four-way close
            (FIN, ACK, FIN, ACK).</t>
          </section>
          <section anchor="QUIC_Spec_Client" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.3.1.2">
            <name slugifiedName="name-quic-specification">QUIC Specification</name>
            <t indent="0" pn="section-4.3.1.2-1">QUIC stack emulation on the test equipment <bcp14>MUST</bcp14>
            conform to <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/> and <xref target="RFC9001" format="default" sectionFormat="of" derivedContent="RFC9001"/>. This section specifies the
            <bcp14>RECOMMENDED</bcp14> values for certain QUIC parameters to
            be configured on test equipment used for benchmarking purposes
            only. The QUIC stream type (defined in <xref target="RFC9000" sectionFormat="of" section="2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9000#section-2.1" derivedContent="RFC9000"/>) is set to "Client-Initiated,
            Bidirectional". 0-RTT and early data are disabled. The QUIC connection
            termination method is an immediate close (<xref target="RFC9000" sectionFormat="of" section="10.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9000#section-10.2" derivedContent="RFC9000"/>). Flow control is enabled. UDP
            payloads are set to the datagram size of 1232 bytes for IPv6 and 1252
            bytes for IPv4.  In addition, transport parameters and default
            values defined in <xref target="RFC9000" sectionFormat="of" section="18.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9000#section-18.2" derivedContent="RFC9000"/> are <bcp14>RECOMMENDED</bcp14> to configure on
            test equipment. Also, this document references Appendices <xref target="RFC9002" section="B.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9002#appendix-B.1" derivedContent="RFC9002"/> and
            <xref target="RFC9002" section="B.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9002#appendix-B.2" derivedContent="RFC9002"/> of <xref target="RFC9002" format="default" sectionFormat="of" derivedContent="RFC9002"/> for congestion-control-related
	    constants and variables. Any configured QUIC and
            UDP parameter <bcp14>MUST</bcp14> be documented in the test
            report.</t>
          </section>
          <section anchor="Client_IP" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.3.1.3">
            <name slugifiedName="name-client-ip-address-space">Client IP Address Space</name>
            <t indent="0" pn="section-4.3.1.3-1">The client IP space contains the following attributes.</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1.3-2">
              <li pn="section-4.3.1.3-2.1">If multiple IP blocks are used, they <bcp14>MUST</bcp14> consist of
                multiple unique, discontinuous static address blocks.</li>
              <li pn="section-4.3.1.3-2.2">A default gateway <bcp14>MAY</bcp14> be used.</li>
              <li pn="section-4.3.1.3-2.3">The differentiated services code point (DSCP) marking
                should be set to Default Forwarding (DF) '000000' on the IPv4 Type
                of Service (ToS) field and IPv6 Traffic Class field.</li>
              <li pn="section-4.3.1.3-2.4">One or more extension headers <bcp14>MAY</bcp14> be used for IPv6 clients. If
                multiple extension headers are needed for traffic emulation,
                this document references <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> to choose
                the correct order of the extension headers within an IPv6
                packet. Testing with one or more extension headers may impact the
                performance of the DUT. The extension headers <bcp14>MUST</bcp14> be
                documented and reported.</li>
            </ul>
            <t indent="0" pn="section-4.3.1.3-3">The following equation can be used to define the total number
            of client IP addresses that need to be configured on the test
            equipment.</t>
            <t indent="3" pn="section-4.3.1.3-4">Desired total number of client IP addresses = Target throughput
            [Mbit/s] / Average throughput per IP address [Mbit/s]</t>
            <t indent="0" pn="section-4.3.1.3-5">As shown in the example list below, the value for "Average
            throughput per IP address" can be varied depending on the
            deployment and use case scenario.</t>
            <ol spacing="normal" type="Example %d" indent="adaptive" start="1" pn="section-4.3.1.3-6">
	      <li pn="section-4.3.1.3-6.1" derivedCounter="Example 1">DUT/SUT deployment scenario 1: 6-7 Mbit/s per IP (e.g.,
                1,400-1,700 IPs per 10 Gbit/s of throughput)</li>
              <li pn="section-4.3.1.3-6.2" derivedCounter="Example 2">DUT/SUT deployment scenario 2: 0.1-0.2 Mbit/s per IP (e.g.,
                50,000-100,000 IPs per 10 Gbit/s of throughput)</li>
            </ol>
            <t indent="0" pn="section-4.3.1.3-7">Client IP addresses <bcp14>MUST</bcp14> be distributed between IPv4 and IPv6
            based on the deployment and use case scenario. The following options
            <bcp14>MAY</bcp14> be considered for a selection of ratios for both IP addresses
            and traffic load distribution.</t>
            <ol spacing="normal" type="Option %d" indent="adaptive" start="1" pn="section-4.3.1.3-8">
	      <li pn="section-4.3.1.3-8.1" derivedCounter="Option 1">100 % IPv4, no IPv6</li>
              <li pn="section-4.3.1.3-8.2" derivedCounter="Option 2">80 % IPv4, 20% IPv6</li>
              <li pn="section-4.3.1.3-8.3" derivedCounter="Option 3">50 % IPv4, 50% IPv6</li>
              <li pn="section-4.3.1.3-8.4" derivedCounter="Option 4">20 % IPv4, 80% IPv6</li>
              <li pn="section-4.3.1.3-8.5" derivedCounter="Option 5">no IPv4, 100% IPv6</li>
            </ol>
            <t indent="0" pn="section-4.3.1.3-9">Note: IANA has assigned IP address ranges for testing purposes,
            as described in <xref target="IANA" format="default" sectionFormat="of" derivedContent="Section 8"/>. If the test scenario
            requires more IP addresses or subnets than IANA has assigned, this
            document recommends using private IPv4 address ranges or Unique
            Local Address (ULA) IPv6 address ranges for the testing.</t>
          </section>
          <section anchor="Emulated_web_Browser_attributes" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.3.1.4">
            <name slugifiedName="name-emulated-web-browser-attrib">Emulated Web Browser Attributes</name>
            <t indent="0" pn="section-4.3.1.4-1">The client (emulated web browser) contains attributes that will
            materially affect the traffic load. The objective is to emulate
            modern, typical browser attributes to improve the relevance of the
            result set for typical deployment scenarios.</t>
            <t indent="0" pn="section-4.3.1.4-2">The emulated browser <bcp14>MUST</bcp14> negotiate HTTP version 1.1 or higher.
            The emulated browser <bcp14>SHOULD</bcp14> advertise a User-Agent header. The
            emulated browser <bcp14>MUST</bcp14> enforce content length validation. HTTP
            header compression <bcp14>MAY</bcp14> be set to enable. If HTTP header
            compression is configurable in the test equipment, it <bcp14>MUST</bcp14> be
            documented if it was enabled or disabled. Depending on test
            scenarios and the chosen HTTP version, the emulated browser <bcp14>MAY</bcp14> open
            multiple TCP or QUIC connections per server endpoint IP at any
            time, depending on how many sequential transactions need to be
            processed.</t>
            <t indent="0" pn="section-4.3.1.4-3">For HTTP/2 traffic emulation, the emulated browser opens
            multiple concurrent streams per connection (multiplexing). For
            HTTPS requests, the emulated browser <bcp14>MUST</bcp14> send an "h2" protocol
            identifier using the TLS extension Application-Layer Protocol
            Negotiation (ALPN). The following default values (see <xref target="Undertow" format="default" sectionFormat="of" derivedContent="Undertow"/>) are the <bcp14>RECOMMENDED</bcp14> settings for certain
            HTTP/2 parameters to be configured on test equipment used for
            benchmarking purposes only:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.1.4-4">
              <li pn="section-4.3.1.4-4.1">Maximum frame size: 16384 bytes</li>
              <li pn="section-4.3.1.4-4.2">Initial window size: 65535 bytes</li>
              <li pn="section-4.3.1.4-4.3">HPACK header field table size: 4096 bytes</li>
              <li pn="section-4.3.1.4-4.4">Server push enable: false (Note: In <xref target="Undertow" format="default" sectionFormat="of" derivedContent="Undertow"/>, the default setting is true. However, for
                testing purposes, this document recommends setting the value to 
                false for server push.)</li>
            </ul>
            <t indent="0" pn="section-4.3.1.4-5">This document refers to <xref target="RFC9113" format="default" sectionFormat="of" derivedContent="RFC9113"/> for further
            details of HTTP/2. If any additional parameters are used to
            configure the test equipment, they <bcp14>MUST</bcp14> be documented.</t>
            <t indent="0" pn="section-4.3.1.4-6">For HTTP/3 traffic emulation, the emulated browsers initiate
            secure QUIC connections using TLS 1.3 (<xref target="RFC9001" format="default" sectionFormat="of" derivedContent="RFC9001"/>
            describes how TLS is used to secure QUIC). This document refers to
            <xref target="RFC9114" format="default" sectionFormat="of" derivedContent="RFC9114"/> for HTTP/3 specifications. The
            specification for transport protocol parameters is defined in
            <xref target="QUIC_Spec_Client" format="default" sectionFormat="of" derivedContent="Section 4.3.1.2"/>. QPACK
            configuration settings, such as MAX_TABLE_CAPACITY and
            QPACK_BLOCKED_STREAMS, are set to zero (default), as defined in
            <xref target="RFC9204" format="default" sectionFormat="of" derivedContent="RFC9204"/>. Any HTTP/3 parameters used for test
            equipment configuration <bcp14>MUST</bcp14> be documented.</t>
            <t indent="0" pn="section-4.3.1.4-7">For encrypted traffic, the following attributes are defined as
            the negotiated encryption parameters. The test clients <bcp14>MUST</bcp14> use
            TLS version 1.2 or higher. The TLS record size <bcp14>MAY</bcp14> be optimized
            for the HTTPS response object size, up to a record size of 16
            KB. If Server Name Indication (SNI) is required (especially if
            the server is identified by a domain name), the client endpoint
            <bcp14>MUST</bcp14> send TLS extension SNI information
            when opening a security tunnel. Each client connection <bcp14>MUST</bcp14>
            perform a full TLS handshake, and session reuse or resumption <bcp14>MUST</bcp14>
            be disabled. (Note: Real web browsers use session reuse or
            resumption. However, for testing purposes, this feature must not
            be used to measure the DUT/SUT performance in the worst-case
            scenario.)</t>
            <t indent="0" pn="section-4.3.1.4-8">The following ciphers and keys supported by TLS 1.2 are
            <bcp14>RECOMMENDED</bcp14> for the HTTPS-based benchmarking tests defined in <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/>.</t>
            <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.3.1.4-9">
	      <li pn="section-4.3.1.4-9.1" derivedCounter="1.">ECDHE-ECDSA-AES128-GCM-SHA256 with Prime256v1 (Signature
                Hash Algorithm: ecdsa_secp256r1_sha256 and Supported group:
                secp256r1)</li>
              <li pn="section-4.3.1.4-9.2" derivedCounter="2.">ECDHE-RSA-AES128-GCM-SHA256 with RSA 2048 (Signature Hash
                Algorithm: rsa_pkcs1_sha256 and Supported group:
                secp256r1)</li>
              <li pn="section-4.3.1.4-9.3" derivedCounter="3.">ECDHE-ECDSA-AES256-GCM-SHA384 with Secp384r1 (Signature
                Hash Algorithm: ecdsa_secp384r1_sha384 and Supported group:
                secp384r1)</li>
              <li pn="section-4.3.1.4-9.4" derivedCounter="4.">ECDHE-RSA-AES256-GCM-SHA384 with RSA 4096 (Signature Hash
                Algorithm: rsa_pkcs1_sha384 and Supported group:
                secp384r1)</li>
            </ol>
            <t indent="0" pn="section-4.3.1.4-10">Note: The above ciphers and keys were those commonly used for
            enterprise-grade encryption cipher suites for TLS 1.2 at of the
            time of publication (2023). Individual certification bodies should
            use ciphers and keys that reflect evolving use cases. These
            choices <bcp14>MUST</bcp14> be documented in the resulting test reports with
            detailed information on the ciphers and keys used, along with
            reasons for the choices.</t>
            <t indent="0" pn="section-4.3.1.4-11">IANA recommends the following cipher suites for use with TLS
            1.3, as defined in <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>.</t>
            <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.3.1.4-12">
	      <li pn="section-4.3.1.4-12.1" derivedCounter="1.">TLS_AES_128_GCM_SHA256</li>
              <li pn="section-4.3.1.4-12.2" derivedCounter="2.">TLS_AES_256_GCM_SHA384</li>
              <li pn="section-4.3.1.4-12.3" derivedCounter="3.">TLS_CHACHA20_POLY1305_SHA256</li>
              <li pn="section-4.3.1.4-12.4" derivedCounter="4.">TLS_AES_128_CCM_SHA256</li>
            </ol>
          </section>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2">
          <name slugifiedName="name-backend-server-configuratio">Backend Server Configuration</name>
          <t indent="0" pn="section-4.3.2-1">This section specifies which parameters should be considered
          while configuring emulated backend servers using test equipment.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.3.2.1">
            <name slugifiedName="name-tcp-stack-attributes-2">TCP Stack Attributes</name>
            <t indent="0" pn="section-4.3.2.1-1">The TCP stack on the server-side <bcp14>MUST</bcp14> be configured similarly to
            the client-side configuration described in <xref target="TCP_Stack_client" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>.</t>
          </section>
          <section anchor="QUIC_Spec_Server" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.3.2.2">
            <name slugifiedName="name-quic-specification-2">QUIC Specification</name>
            <t indent="0" pn="section-4.3.2.2-1">The QUIC parameters on the server-side <bcp14>MUST</bcp14> be configured
            similarly to the client-side configuration. Any configured QUIC
            parameter <bcp14>MUST</bcp14> be documented in the report.</t>
          </section>
          <section anchor="Server_IP" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.3.2.3">
            <name slugifiedName="name-server-endpoint-ip-addressi">Server Endpoint IP Addressing</name>
            <t indent="0" pn="section-4.3.2.3-1">The sum of the server IP space <bcp14>MUST</bcp14> contain the following
            attributes.</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.2.3-2">
              <li pn="section-4.3.2.3-2.1">The server IP blocks <bcp14>MUST</bcp14> consist of unique, discontinuous
                static address blocks with one IP per server Fully Qualified
                Domain Name (FQDN) endpoint per test port.</li>
              <li pn="section-4.3.2.3-2.2">A default gateway is permitted. The 
                DSCP marking is set to DF
                '000000' on the IPv4 ToS field and IPv6 Traffic
                Class field. One or more extension headers for the IPv6 server are
                permitted. If multiple extension headers are required, this
                document references <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> to choose the
                correct order of the extension headers within an IPv6
                packet.</li>
              <li pn="section-4.3.2.3-2.3">The server IP address distribution between IPv4 and IPv6
                <bcp14>MUST</bcp14> be identical to the client IP address distribution
                ratio.</li>
            </ul>
            <t indent="0" pn="section-4.3.2.3-3">Note: IANA has assigned IP address blocks for the testing
            purpose described in <xref target="IANA" format="default" sectionFormat="of" derivedContent="Section 8"/>. If the test
            scenario requires more IP addresses or address blocks than
            IANA has assigned, this document recommends using private IPv4 address
            ranges or Unique Local Address (ULA) IPv6 address ranges for the
            testing.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.3.2.4">
            <name slugifiedName="name-http-https-server-pool-endp">HTTP/HTTPS Server Pool Endpoint Attributes</name>
            <t indent="0" pn="section-4.3.2.4-1">The HTTP 1.1 and HTTP/2 server pools listen on TCP ports 80 and
            443 for HTTP and HTTPS.
	    The HTTP/3 server pool listens on any UDP port. The server <bcp14>MUST</bcp14> emulate the same HTTP version (HTTP
            1.1, HTTP/2, or HTTP/3) and settings chosen by the client
            (emulated web browser). For the HTTPS server, TLS version 1.2 or higher
            <bcp14>MUST</bcp14> be used with a maximum record size of 16 KB. Ticket
            resumption or session ID reuse <bcp14>MUST NOT</bcp14> be used for TLS 1.2;
            also, session ticket or session cache <bcp14>MUST NOT</bcp14> be used for TLS 1.3.
            The server <bcp14>MUST</bcp14> serve a certificate to the client. The cipher suite
            and key size on the server-side <bcp14>MUST</bcp14> be configured similarly to the
            client-side configuration described in <xref target="Emulated_web_Browser_attributes" format="default" sectionFormat="of" derivedContent="Section 4.3.1.4"/>.</t>
          </section>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3.3">
          <name slugifiedName="name-traffic-flow-definition">Traffic Flow Definition</name>
          <t indent="0" pn="section-4.3.3-1">   At the beginning of the test (the init phase; see <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>), 
   the server endpoint initializes, and the server endpoint will be 
   ready to accept TCP or QUIC connections as well as inbound HTTP and 
   HTTPS requests.  The client endpoints initialize and are given 
   attributes such as a MAC and IP address. After the init phase of 
   the test, each client sweeps through the given server IP space,
   generating a service recognizable by the DUT.  Sequential and
          pseudorandom sweep methods are acceptable. The method used <bcp14>MUST</bcp14> be
          stated in the final report. Thus, a balanced mesh between client
          endpoints and server endpoints will be generated in a client IP and
          port to server IP and port combination. Each client endpoint
          performs the same actions as other endpoints, with the difference
          being the source IP of the client endpoint and the target server IP
          pool. The client <bcp14>MUST</bcp14> use the server IP address or FQDN in the host
          header.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.3.3.1">
            <name slugifiedName="name-description-of-intra-client">Description of Intra-Client Behavior</name>
            <t indent="0" pn="section-4.3.3.1-1">Client endpoints are independent of other clients that are
            concurrently executing. When a client endpoint initiates traffic,
            this section describes how the client steps through different
            services. Once the test is initialized, the client endpoints
            randomly hold (perform no operation) for a few milliseconds for
            better randomization of the start of client traffic. Each client
            (HTTP 1.1 or HTTP/2) will either open a new TCP connection or
            connect to an HTTP persistent connection that is still open to that
            specific server. HTTP/3 clients will open UDP streams within QUIC
            connections. At any point that the traffic profile may require
            encryption, a TLS encryption tunnel will form, presenting the URL
            or IP address request to the server.    If using SNI, the server
	    <bcp14>MUST</bcp14> then perform an SNI name check 
	    by comparing the proposed FQDN to the domain embedded in
	    the certificate. Only when correct will
            the server process the HTTPS response object. The initial response
            object to the server is based on benchmarking tests described in
            <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/>. Multiple additional
            sub-URLs (response objects on the service page) <bcp14>MAY</bcp14> be requested
            simultaneously. This <bcp14>MAY</bcp14> be to the same server IP as the initial
            URL. Each sub-object will also use a canonical FQDN and URL
            path.</t>
          </section>
        </section>
        <section anchor="Traffic_Load_Profile" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.4">
          <name slugifiedName="name-traffic-load-profile">Traffic Load Profile</name>
          <t indent="0" pn="section-4.3.4-1">The loading of traffic is described in this section. The loading
          of a traffic load profile has five phases: Init, ramp up, sustain,
          ramp down, and collection.</t>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.3.4-2">
            <dt pn="section-4.3.4-2.1">Init phase:</dt>
            <dd pn="section-4.3.4-2.2">Testbed devices, including the client and server
              endpoints, should negotiate layer 2-3 connectivity, such as MAC
              learning and ARP/ND. Only after successful MAC learning or
              ARP/ND <bcp14>SHALL</bcp14> the test iteration move to the next phase. No
              measurements are made in this phase. The minimum recommended
              time for the Init phase is 5 seconds. During this phase, the
              emulated clients <bcp14>MUST NOT</bcp14> initiate any sessions with the
              DUT/SUT; in contrast, the emulated servers should be ready to
              accept requests from the DUT/SUT or emulated clients.</dd>
            <dt pn="section-4.3.4-2.3">Ramp Up phase:</dt>
            <dd pn="section-4.3.4-2.4">The test equipment <bcp14>MUST</bcp14> start to generate the
	    test traffic. It <bcp14>MUST</bcp14> use a set of the approximate
	    number of unique client IP addresses to generate traffic. The
	    traffic <bcp14>MUST</bcp14> ramp up from zero to the desired target
	    objective. The target objective is defined for each benchmarking
	    test. The duration for the ramp up phase <bcp14>MUST</bcp14> be
	    configured long enough that the test equipment does not overwhelm
	    the DUT's/SUT's stated performance metrics defined in <xref target="Key_Performance_Indicators" format="default" sectionFormat="of" derivedContent="Section 6.3"/>, namely TCP or QUIC
	    connections per second, inspected throughput, concurrent
	    TCP or QUIC connections, and application transactions per
	    second. No measurements are made in this phase.</dd>
            <dt pn="section-4.3.4-2.5">Sustain phase:</dt>
            <dd pn="section-4.3.4-2.6">This phase starts when all required clients are active
              and operating at their desired load condition. In the sustain
              phase, the test equipment <bcp14>MUST</bcp14> continue generating traffic to a
              constant target value for a constant number of active clients.
              The minimum <bcp14>RECOMMENDED</bcp14> time duration for the sustain phase is 300
              seconds. This is the phase where measurements occur. The test
              equipment <bcp14>MUST</bcp14> measure and record statistics continuously. The
              sampling interval for collecting the raw results and calculating
              the statistics <bcp14>MUST</bcp14> be less than 2 seconds.</dd>
            <dt pn="section-4.3.4-2.7">Ramp Down phase:</dt>
            <dd pn="section-4.3.4-2.8">The test traffic slows down from the target
              number to 0, and no measurements are made.</dd>
            <dt pn="section-4.3.4-2.9">Collection phase:</dt>
            <dd pn="section-4.3.4-2.10">The last phase is administrative and will
              occur when the test equipment merges and collates the report
              data.</dd>
          </dl>
        </section>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-testbed-considerations">Testbed Considerations</name>
      <t indent="0" pn="section-5-1">This section describes steps for a reference test (pre-test) that
      controls the test environment, including test equipment, focusing on
      physical and virtualized environments and test equipment.
      Below are the <bcp14>RECOMMENDED</bcp14> steps for the reference test.</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5-2">
	<li pn="section-5-2.1" derivedCounter="1.">Perform the reference test either by configuring the DUT/SUT in
          the most trivial setup (fast forwarding) or without the presence of
          the DUT/SUT.</li>
        <li pn="section-5-2.2" derivedCounter="2.">Generate traffic from the traffic generator. Choose a traffic profile
          used for the HTTP or HTTPS throughput performance test with the
          smallest object size.</li>
        <li pn="section-5-2.3" derivedCounter="3.">Ensure that any ancillary switching or routing functions added in
       the test equipment do not limit performance by introducing
       packet loss or latency. This is
          specifically important for virtualized components (e.g., vSwitches or 
          vRouters).</li>
        <li pn="section-5-2.4" derivedCounter="4.">Verify that the generated traffic (performance) of the test
          equipment matches and reasonably exceeds the expected maximum
          performance of the DUT/SUT.</li>
        <li pn="section-5-2.5" derivedCounter="5.">Record the network performance metrics packet loss and latency
          introduced by the test environment (without the DUT/SUT).</li>
        <li pn="section-5-2.6" derivedCounter="6.">Assert that the testbed characteristics are stable during the
          entire test session. Several factors might influence stability,
          specifically for virtualized testbeds, for example, additional
          workloads in a virtualized system, load balancing, and movement of
          virtual machines during the test or simple issues, such as
          additional heat created by high workloads leading to an emergency
          CPU performance reduction.</li>
      </ol>
      <t indent="0" pn="section-5-3">The reference test <bcp14>MUST</bcp14> be performed before the benchmarking tests
      (described in <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/>) start.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-reporting">Reporting</name>
      <t indent="0" pn="section-6-1">This section describes how the benchmarking test report should be
      formatted and presented. It is <bcp14>RECOMMENDED</bcp14> to include two main sections
      in the report: the introduction and the detailed test results
      sections.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-introduction-2">Introduction</name>
        <t indent="0" pn="section-6.1-1">The following attributes should be present in the introduction
        section of the test report.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6.1-2">
	  <li pn="section-6.1-2.1" derivedCounter="1.">Time and date of the execution of the tests</li>
          <li pn="section-6.1-2.2" derivedCounter="2.">
            <t indent="0" pn="section-6.1-2.2.1">Summary of testbed software and hardware details</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-6.1-2.2.2"><li pn="section-6.1-2.2.2.1" derivedCounter="a.">
                <t indent="0" pn="section-6.1-2.2.2.1.1">DUT/SUT hardware/virtual configuration</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-2.2.2.1.2">
                  <li pn="section-6.1-2.2.2.1.2.1">Make and model
                    of the DUT/SUT, which should be clearly identified</li>
                  <li pn="section-6.1-2.2.2.1.2.2">Port interfaces, including speed and link
                  information</li>
                  <li pn="section-6.1-2.2.2.1.2.3">If the DUT/SUT is a Virtual Network Function (VNF)</li>
                  <li pn="section-6.1-2.2.2.1.2.4">Host (server) hardware and software details</li>
                  <li pn="section-6.1-2.2.2.1.2.5">Interface acceleration type (such as Data Plane Development Kit (DPDK) and single-root input/output
		  virtualization (SR-IOV))</li>
                  <li pn="section-6.1-2.2.2.1.2.6">Used CPU cores</li>
                  <li pn="section-6.1-2.2.2.1.2.7">Used RAM</li>
                  <li pn="section-6.1-2.2.2.1.2.8">Resource sharing (e.g., pinning details and Non-Uniform Memory Access (NUMA)
                  node) configuration details</li>
                  <li pn="section-6.1-2.2.2.1.2.9">Hypervisor version</li>
                  <li pn="section-6.1-2.2.2.1.2.10">Virtual switch version</li>
                  <li pn="section-6.1-2.2.2.1.2.11">Details of any additional hardware relevant to the
                    DUT/SUT, such as controllers</li>
                </ul>
              </li>
              <li pn="section-6.1-2.2.2.2" derivedCounter="b.">
                <t indent="0" pn="section-6.1-2.2.2.2.1">DUT/SUT software</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-2.2.2.2.2">
                  <li pn="section-6.1-2.2.2.2.2.1">Operating system name</li>
                  <li pn="section-6.1-2.2.2.2.2.2">Version</li>
                  <li pn="section-6.1-2.2.2.2.2.3">Specific configuration details (if any)</li>
                </ul>
              </li>
              <li pn="section-6.1-2.2.2.3" derivedCounter="c.">
                <t indent="0" pn="section-6.1-2.2.2.3.1">DUT-/SUT-enabled features</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-2.2.2.3.2">
                  <li pn="section-6.1-2.2.2.3.2.1">Configured DUT/SUT features (see Tables <xref target="NGFW_Security_Features" format="counter" sectionFormat="of" derivedContent="2"/> and <xref target="NGIPS_Security_Features" format="counter" sectionFormat="of" derivedContent="3"/>)</li>
                  <li pn="section-6.1-2.2.2.3.2.2">Attributes of the abovementioned features</li>
                  <li pn="section-6.1-2.2.2.3.2.3">Any additional relevant information about the
                    features</li>
                </ul>
              </li>
              <li pn="section-6.1-2.2.2.4" derivedCounter="d.">
                <t indent="0" pn="section-6.1-2.2.2.4.1">Test equipment hardware and software </t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-2.2.2.4.2">
                  <li pn="section-6.1-2.2.2.4.2.1">Test equipment vendor name</li>
                  <li pn="section-6.1-2.2.2.4.2.2">Hardware details, including model number and interface
                    type</li>
                  <li pn="section-6.1-2.2.2.4.2.3">Test equipment firmware and test application software
                    version</li>
                  <li pn="section-6.1-2.2.2.4.2.4">If the test equipment is a virtual solution</li>
                  <li pn="section-6.1-2.2.2.4.2.5">The host
                    (server) hardware and software details</li>
                  <li pn="section-6.1-2.2.2.4.2.6">Interface acceleration type (such as DPDK and SR-IOV)</li>
                  <li pn="section-6.1-2.2.2.4.2.7">Used CPU cores</li>
                  <li pn="section-6.1-2.2.2.4.2.8">Used RAM</li>
                  <li pn="section-6.1-2.2.2.4.2.9">Resource sharing (e.g., pinning details and NUMA
                    node) configuration details</li>
                  <li pn="section-6.1-2.2.2.4.2.10">Hypervisor version</li>
                  <li pn="section-6.1-2.2.2.4.2.11">Virtual switch version</li>
                </ul>
              </li>
              <li pn="section-6.1-2.2.2.5" derivedCounter="e.">
                <t indent="0" pn="section-6.1-2.2.2.5.1">Key test parameters</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-2.2.2.5.2">
                  <li pn="section-6.1-2.2.2.5.2.1">Used cipher suites and keys</li>
                  <li pn="section-6.1-2.2.2.5.2.2">IPv4 and IPv6 traffic distribution</li>
                  <li pn="section-6.1-2.2.2.5.2.3">Number of configured ACLs</li>
                  <li pn="section-6.1-2.2.2.5.2.4">TCP and UDP stack parameter, if tested</li>
                  <li pn="section-6.1-2.2.2.5.2.5">QUIC, HTTP/2, and HTTP/3 parameters, if tested</li>
                </ul>
              </li>
              <li pn="section-6.1-2.2.2.6" derivedCounter="f.">
                <t indent="0" pn="section-6.1-2.2.2.6.1">Details of the application traffic mix used in the benchmarking
                test <xref format="default" target="Throughput_Performance_With_Traffic_Mix" sectionFormat="of" derivedContent="Section 7.1">Throughput
                Performance with Application Traffic Mix</xref></t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-2.2.2.6.2">
                  <li pn="section-6.1-2.2.2.6.2.1">Name of applications and layer 7 protocols</li>
                  <li pn="section-6.1-2.2.2.6.2.2">Percentage of emulated traffic for each application and
                    layer 7 protocols</li>
                  <li pn="section-6.1-2.2.2.6.2.3">Percentage of encrypted traffic, used cipher suites,
                    and keys (the <bcp14>RECOMMENDED</bcp14> ciphers and keys are defined in
                    <xref target="Emulated_web_Browser_attributes" format="default" sectionFormat="of" derivedContent="Section 4.3.1.4"/>)</li>
                  <li pn="section-6.1-2.2.2.6.2.4">Used object sizes for each application and layer 7
                    protocols</li>
                </ul>
              </li>
            </ol>
          </li>
          <li pn="section-6.1-2.3" derivedCounter="3.">
            <t indent="0" pn="section-6.1-2.3.1">Results Summary / Executive Summary</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-6.1-2.3.2">
	      <li pn="section-6.1-2.3.2.1" derivedCounter="a.">Results should be presented with an introduction section
                documenting the summary of results in a prominent, easy-to-read block.</li>
            </ol>
          </li>
        </ol>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-detailed-test-results">Detailed Test Results</name>
        <t indent="0" pn="section-6.2-1">In the results section of the test report, the following attributes
        should be present for each benchmarking test.</t>
        <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-6.2-2">
	  <li pn="section-6.2-2.1" derivedCounter="a.">KPIs <bcp14>MUST</bcp14> be documented separately for each benchmarking test.
            The format of the KPI metrics <bcp14>MUST</bcp14> be presented as described in
            <xref target="Key_Performance_Indicators" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</li>
          <li pn="section-6.2-2.2" derivedCounter="b.">The next level of details should be graphs showing each of these
            metrics over the duration (sustain phase) of the test. This allows
            the user to see the measured performance stability changes over
            time.</li>
        </ol>
      </section>
      <section anchor="Key_Performance_Indicators" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-benchmarks-and-key-performa">Benchmarks and Key Performance Indicators</name>
        <t indent="0" pn="section-6.3-1">This section lists key performance indicators (KPIs) for overall
        benchmarking tests. All KPIs <bcp14>MUST</bcp14> be measured during the sustain phase
        of the traffic load profile described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>. Also, the KPIs <bcp14>MUST</bcp14> be measured from
        the result output of test equipment.</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-6.3-2">
          <dt pn="section-6.3-2.1">Concurrent TCP Connections</dt>
          <dd pn="section-6.3-2.2">The aggregate number of simultaneous connections between hosts
            across the DUT/SUT or between hosts and the DUT/SUT (defined in
            <xref target="RFC2647" format="default" sectionFormat="of" derivedContent="RFC2647"/>).</dd>
          <dt pn="section-6.3-2.3">Concurrent QUIC Connections</dt>
          <dd pn="section-6.3-2.4">The aggregate number of simultaneous connections between hosts
            across the DUT/SUT.</dd>
          <dt pn="section-6.3-2.5">TCP Connections Per Second</dt>
          <dd pn="section-6.3-2.6">The average number of successfully established TCP connections
            per second between hosts across the DUT/SUT or between hosts and
            the DUT/SUT. As described in <xref target="TCP_Stack_client" format="default" sectionFormat="of" derivedContent="Section 4.3.1.1"/>, the TCP connections are initiated by clients
            via a TCP three-way handshake (SYN, SYN/ACK, ACK). Then, the TCP
            session data is sent, and then the TCP sessions are closed via
            either a TCP three-way close (FIN, FIN/ACK, ACK) or a TCP four-way
            close (FIN, ACK, FIN, ACK). The TCP sessions <bcp14>MUST NOT</bcp14> be closed by RST.</dd>
          <dt pn="section-6.3-2.7">QUIC Connections Per Second</dt>
          <dd pn="section-6.3-2.8">
            <t indent="0" pn="section-6.3-2.8.1">The average number of successfully established QUIC
            connections per second between hosts across the DUT/SUT. As
            described in <xref target="QUIC_Spec_Client" format="default" sectionFormat="of" derivedContent="Section 4.3.1.2"/>,
            the QUIC connections are initiated by clients. Then, the data is
            sent, and then the QUIC sessions are closed by the "immediate close"
            method.</t>
            <t indent="0" pn="section-6.3-2.8.2">Since the QUIC specification defined in <xref target="QUIC_Spec_Client" format="default" sectionFormat="of" derivedContent="Section 4.3.1.2"/> recommends disabling
            0-RTT and early data, this KPI is focused on the
 1-RTT handshake. If
            required, 0-RTT can be also measured in separate test runs while
            enabling 0-RTT and early data in the test equipment.</t>
          </dd>
          <dt pn="section-6.3-2.9">Application Transactions Per Second</dt>
          <dd pn="section-6.3-2.10">The average number of successfully completed transactions per
            second. For a particular transaction to be considered successful,
            all data <bcp14>MUST</bcp14> have been transferred in its
            entirety. In case of an HTTP(S) transaction, it <bcp14>MUST</bcp14>
            have a valid status code (200 OK).</dd>
          <dt pn="section-6.3-2.11">TLS Handshake Rate</dt>
          <dd pn="section-6.3-2.12">
            <t indent="0" pn="section-6.3-2.12.1">The average number of successfully established TLS connections
            per second between hosts across the DUT/SUT or between hosts and
            the DUT/SUT.</t>
            <t indent="0" pn="section-6.3-2.12.2">For TLS 1.3, the handshake rate can be measured with the 0-RTT or
            1-RTT handshake. The transport protocol can be either TCP or
            QUIC.</t>
          </dd>
          <dt pn="section-6.3-2.13">Inspected Throughput</dt>
          <dd pn="section-6.3-2.14">The number of bits per second of examined and allowed traffic
            a network security device is able to transmit to the correct
            destination interface(s) in response to a specified offered
            load. The throughput benchmarking tests defined in <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/> <bcp14>SHOULD</bcp14>
            measure the average layer 2 throughput value when the DUT/SUT is
            "inspecting" traffic. It is also acceptable to measure other OSI
            layer throughput. However, the measured layer (e.g., layer 3
            throughput) <bcp14>MUST</bcp14> be noted in the report, and the
            user <bcp14>MUST</bcp14> be aware of the implication while
            comparing the throughput performance of multiple DUTs/SUTs measured
            in different OSI layers. This document recommends presenting the
            inspected throughput value in Gbit/s rounded to two places of
            precision with a more specific kbit/s in parenthesis.</dd>
          <dt pn="section-6.3-2.15">Time to First Byte (TTFB)</dt>
          <dd pn="section-6.3-2.16">The elapsed time between the start of sending the TCP
            SYN packet or QUIC initial Client Hello from the client and the
            client receiving the first packet of application data from the
            server via the DUT/SUT. The benchmarking tests <xref target="HTTP-Latency" format="default" sectionFormat="of" derivedContent="Section 7.4">HTTP transaction
            latency</xref> and <xref target="HTTPS-Latency" format="default" sectionFormat="of" derivedContent="Section 7.8">HTTPS transaction latency</xref> measure the
            minimum, average, and maximum TTFB. The value should be expressed
            in milliseconds.</dd>
          <dt pn="section-6.3-2.17">URL Response Time / Time to Last Byte (TTLB)</dt>
          <dd pn="section-6.3-2.18">The elapsed time between the start
            of sending the TCP SYN packet or QUIC initial Client Hello from
            the client and the client receiving the last packet of application
            data from the server via the DUT/SUT. The benchmarking tests <xref target="HTTP-Latency" format="default" sectionFormat="of" derivedContent="Section 7.4">HTTP transaction
            latency</xref> and <xref target="HTTPS-Latency" format="default" sectionFormat="of" derivedContent="Section 7.8">HTTPS transaction latency</xref> measure the
            minimum, average, and maximum TTLB. The value should be expressed
            in milliseconds.</dd>
        </dl>
      </section>
    </section>
    <section anchor="Benchmarking" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-benchmarking-tests">Benchmarking Tests</name>
      <t indent="0" pn="section-7-1">This section mainly focuses on the benchmarking tests with HTTP/1.1
      or HTTP/2 traffic, which uses TCP as the transport protocol. In
      particular, this section does not define specific benchmarking tests for
      KPIs related to QUIC or HTTP/3.
      However, the test methodology defined in
      the benchmarking tests <xref format="default" target="HTTPS_CPS" sectionFormat="of" derivedContent="Section 7.6">TCP or QUIC connections per second with HTTPS
      traffic</xref>, <xref format="default" target="HTTPS-Latency" sectionFormat="of" derivedContent="Section 7.8">HTTPS
      transaction latency</xref>, <xref format="default" target="HTTPS_TP" sectionFormat="of" derivedContent="Section 7.7">HTTPS throughput</xref>, and <xref format="default" target="HTTPS_CC" sectionFormat="of" derivedContent="Section 7.9">concurrent TCP or QUIC connection capacity with HTTPS
      traffic</xref> can be used to test KPIs related to QUIC or HTTP/3. The
      throughput performance test with the application traffic mix defined in
      <xref target="Throughput_Performance_With_Traffic_Mix" format="default" sectionFormat="of" derivedContent="Section 7.1"/>
      can be performed with any other application traffic, including
      HTTP/3.</t>
      <section anchor="Throughput_Performance_With_Traffic_Mix" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-throughput-performance-with">Throughput Performance with Application Traffic Mix</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1.1">
          <name slugifiedName="name-objective">Objective</name>
          <t indent="0" pn="section-7.1.1-1">Using a relevant application traffic mix, determine the
          sustainable inspected throughput supported by the DUT/SUT.</t>
          <t indent="0" pn="section-7.1.1-2">Based on the test customer's specific use case, testers can
          choose the relevant application traffic mix for this test. The
          details about the traffic mix <bcp14>MUST</bcp14> be documented in the report. At
          least, the following traffic mix details <bcp14>MUST</bcp14> be documented and
          reported together with the test results:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.1.1-3">
            <li pn="section-7.1.1-3.1">Name of applications and layer 7 protocols</li>
            <li pn="section-7.1.1-3.2">Percentage of emulated traffic for each application and layer
              7 protocol</li>
            <li pn="section-7.1.1-3.3">Percentage of encrypted traffic and used cipher suites and
              keys (the <bcp14>RECOMMENDED</bcp14> ciphers and keys are defined in <xref target="Emulated_web_Browser_attributes" format="default" sectionFormat="of" derivedContent="Section 4.3.1.4"/>)</li>
            <li pn="section-7.1.1-3.4">Used object sizes for each application and layer 7
              protocols</li>
          </ul>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1.2">
          <name slugifiedName="name-test-setup-2">Test Setup</name>
          <t indent="0" pn="section-7.1.2-1">The testbed setup <bcp14>MUST</bcp14> be configured as defined in <xref target="Test_Setup" format="default" sectionFormat="of" derivedContent="Section 4"/>. Any benchmarking-test-specific testbed
          configuration changes <bcp14>MUST</bcp14> be documented.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1.3">
          <name slugifiedName="name-test-parameters">Test Parameters</name>
          <t indent="0" pn="section-7.1.3-1">In this section, the benchmarking-test-specific parameters are
          defined.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.1.3.1">
            <name slugifiedName="name-dut-sut-configuration-param">DUT/SUT Configuration Parameters</name>
            <t indent="0" pn="section-7.1.3.1-1">DUT/SUT parameters <bcp14>MUST</bcp14> conform to the requirements defined in
            <xref target="DUT-SUT_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Any configuration changes
            for this specific benchmarking test <bcp14>MUST</bcp14> be documented. If the DUT/SUT is configured without TLS inspection, the test report <bcp14>MUST</bcp14> explain how this impacts the encrypted traffic of the relevant application traffic mix.</t>
          </section>
          <section anchor="Test_Equipment_Configuration_Parameters_TC_7_1" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.1.3.2">
            <name slugifiedName="name-test-equipment-configuration">Test Equipment Configuration Parameters</name>
            <t indent="0" pn="section-7.1.3.2-1">Test equipment configuration parameters <bcp14>MUST</bcp14> conform to the
            requirements defined in <xref target="Test_Equipment_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.3"/>. The following parameters
            <bcp14>MUST</bcp14> be documented for this benchmarking test:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.1.3.2-2">
              <li pn="section-7.1.3.2-2.1">Client IP address ranges defined in <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.1.3.2-2.2">Server IP address ranges defined in <xref target="Server_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.2.3"/></li>
              <li pn="section-7.1.3.2-2.3">Traffic distribution ratio between IPv4 and IPv6 defined in
                <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.1.3.2-2.4">Target inspected throughput: Aggregated line rate of one or 
                more interfaces used in the DUT/SUT or the value defined based on
                the requirement for a specific deployment scenario</li>
              <li pn="section-7.1.3.2-2.5">
                <t indent="0" pn="section-7.1.3.2-2.5.1">Initial throughput: 10% of the "Target inspected
              throughput"</t>
                <t indent="0" pn="section-7.1.3.2-2.5.2">Note: Initial throughput is not a KPI to report.  This value
              is configured on the traffic generator and used to perform Step
              1 (Test Initialization and Qualification) described in <xref target="Test_Procedures_and_Expected_Results_TC_7_1" format="default" sectionFormat="of" derivedContent="Section 7.1.4"/>.</t>
              </li>
              <li pn="section-7.1.3.2-2.6">One of the ciphers and keys defined in <xref target="Emulated_web_Browser_attributes" format="default" sectionFormat="of" derivedContent="Section 4.3.1.4"/> is
              <bcp14>RECOMMENDED</bcp14> to use for this benchmarking
              test.</li>
            </ul>
          </section>
          <section anchor="Traffic_Profile" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.1.3.3">
            <name slugifiedName="name-traffic-profile">Traffic Profile</name>
            <t indent="0" pn="section-7.1.3.3-1">This test <bcp14>MUST</bcp14> be run with a relevant
            application traffic mix profile.</t>
          </section>
          <section anchor="Test_Results_Validation_Criteria_7_1" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.1.3.4">
            <name slugifiedName="name-test-results-validation-cri">Test Results Validation Criteria</name>
            <t indent="0" pn="section-7.1.3.4-1">The following criteria are the test results validation
            criteria. The test results validation criteria <bcp14>MUST</bcp14> be monitored
            during the whole sustain phase of the traffic load profile.</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-7.1.3.4-2">
	      <li pn="section-7.1.3.4-2.1" derivedCounter="a.">The number of failed application transactions <bcp14>MUST</bcp14> be less than
                0.001% (1 out of 100,000 transactions) of the attempted
                transactions.</li>
              <li pn="section-7.1.3.4-2.2" derivedCounter="b.">The number of terminated TCP connections due to unexpected TCP
                RST sent by the DUT/SUT <bcp14>MUST</bcp14> be less than 0.001% (1 out of 100,000
                connections) of the total initiated TCP connections.</li>
              <li pn="section-7.1.3.4-2.3" derivedCounter="c.">If HTTP/3 is used, the number of failed QUIC connections
                due to unexpected HTTP/3 error codes <bcp14>MUST</bcp14> be less than 0.001%
                (1 out of 100,000 connections) of the total initiated QUIC
                connections.</li>
            </ol>
          </section>
          <section anchor="Measurement_7_1" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.1.3.5">
            <name slugifiedName="name-measurement">Measurement</name>
            <t indent="0" pn="section-7.1.3.5-1">The following KPI metrics <bcp14>MUST</bcp14> be reported for this
            benchmarking test:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.1.3.5-2">
              <li pn="section-7.1.3.5-2.1">
                <t indent="0" pn="section-7.1.3.5-2.1.1">Mandatory KPIs (benchmarks): inspected throughput and
	      application transactions per second</t>
                <t indent="0" pn="section-7.1.3.5-2.1.2">Note: The TTLB <bcp14>MUST</bcp14> be reported along
              with the object size used in the traffic profile.</t>
              </li>
              <li pn="section-7.1.3.5-2.2">Optional TCP-stack-related KPIs: TCP connections per second,
	      TLS handshake rate, TTFB (minimum, average, and maximum), TTLB
	      (minimum, average, and maximum)</li>
              <li pn="section-7.1.3.5-2.3">Optional QUIC-stack-related KPIs: QUIC connections per second
	      and concurrent QUIC connections</li>
            </ul>
          </section>
        </section>
        <section anchor="Test_Procedures_and_Expected_Results_TC_7_1" numbered="true" toc="include" removeInRFC="false" pn="section-7.1.4">
          <name slugifiedName="name-test-procedures-and-expecte">Test Procedures and Expected Results</name>
          <t indent="0" pn="section-7.1.4-1">The test procedures are designed to measure the inspected
          throughput performance of the DUT/SUT at the sustaining period of
          the traffic load profile. The test procedure consists of three major
          steps. Step 1 ensures the DUT/SUT is able to reach the performance
          value (initial throughput) and meets the test results validation
          criteria when it was very minimally utilized. Step 2 determines
          whether the DUT/SUT is able to reach the target performance value
          within the test results validation criteria.  Step 3 determines the
          maximum achievable performance value within the test results
          validation criteria.</t>
          <t indent="0" pn="section-7.1.4-2">This test procedure <bcp14>MAY</bcp14> be repeated multiple times with different
          IP types: IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic
          distribution.</t>
          <section anchor="Step1_Test_Initialization" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.1.4.1">
            <name slugifiedName="name-step-1-test-initialization-">Step 1: Test Initialization and Qualification</name>
            <t indent="0" pn="section-7.1.4.1-1">Verify the link status of all connected physical interfaces.
            All interfaces are expected to be in "UP" status.</t>
            <t indent="0" pn="section-7.1.4.1-2">Configure the traffic load profile of the test equipment to
            generate test traffic at the "initial throughput" rate, as
            described in <xref target="Test_Equipment_Configuration_Parameters_TC_7_1" format="default" sectionFormat="of" derivedContent="Section 7.1.3.2"/>. The
            test equipment <bcp14>MUST</bcp14> follow the traffic load profile definition
            described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>. The DUT/SUT
            <bcp14>MUST</bcp14> reach the "initial throughput" during the sustain phase.
            Measure all KPIs, as defined in <xref target="Measurement_7_1" format="default" sectionFormat="of" derivedContent="Section 7.1.3.5"/>. The measured KPIs during the sustain
            phase <bcp14>MUST</bcp14> meet all the test results validation criteria defined
            in <xref target="Test_Results_Validation_Criteria_7_1" format="default" sectionFormat="of" derivedContent="Section 7.1.3.4"/>.</t>
            <t indent="0" pn="section-7.1.4.1-3">If the KPI metrics do not meet the test results validation
            criteria, the test procedure <bcp14>MUST NOT</bcp14> be continued to Step 2.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.1.4.2">
            <name slugifiedName="name-step-2-test-run-with-target">Step 2: Test Run with Target Objective</name>
            <t indent="0" pn="section-7.1.4.2-1">Configure test equipment to generate traffic at the "Target
            inspected throughput" rate defined in <xref target="Test_Equipment_Configuration_Parameters_TC_7_1" format="default" sectionFormat="of" derivedContent="Section 7.1.3.2"/>. The
            test equipment <bcp14>MUST</bcp14> follow the traffic load profile definition
            described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>. The test
            equipment <bcp14>MUST</bcp14> start to measure and record all specified KPIs.
            Continue the test until all traffic profile phases are
            completed.</t>
            <t indent="0" pn="section-7.1.4.2-2">Within the test results validation criteria, the DUT/SUT is
            expected to reach the desired value of the target objective
            ("Target inspected throughput") in the sustain phase. Follow Step
            3 if the measured value does not meet the target value or does
            not fulfill the test results validation criteria.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.1.4.3">
            <name slugifiedName="name-step-3-test-iteration">Step 3: Test Iteration</name>
            <t indent="0" pn="section-7.1.4.3-1">Determine the achievable average inspected throughput within
            the test results validation criteria. The final test iteration
            <bcp14>MUST</bcp14> be performed for the test duration defined in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
          </section>
        </section>
      </section>
      <section anchor="HTTP_CPS" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-tcp-connections-per-second-">TCP Connections Per Second with HTTP Traffic</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.2.1">
          <name slugifiedName="name-objective-2">Objective</name>
          <t indent="0" pn="section-7.2.1-1">Using HTTP traffic, determine the sustainable TCP connection
          establishment rate supported by the DUT/SUT under different
          throughput load conditions.</t>
          <t indent="0" pn="section-7.2.1-2">To measure connections per second, test iterations <bcp14>MUST</bcp14> use
          different fixed HTTP response object sizes (the different load
          conditions) defined in <xref target="Test_Equipment_Configuration_Parameters_HTTP_CPS" format="default" sectionFormat="of" derivedContent="Section 7.2.3.2"/>.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.2.2">
          <name slugifiedName="name-test-setup-3">Test Setup</name>
          <t indent="0" pn="section-7.2.2-1">The testbed setup <bcp14>MUST</bcp14> be configured as defined in <xref target="Test_Setup" format="default" sectionFormat="of" derivedContent="Section 4"/>. Any specific testbed configuration changes
          (number of interfaces, interface type, etc.) <bcp14>MUST</bcp14> be
          documented.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.2.3">
          <name slugifiedName="name-test-parameters-2">Test Parameters</name>
          <t indent="0" pn="section-7.2.3-1">In this section, benchmarking-test-specific parameters are
          defined.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.3.1">
            <name slugifiedName="name-dut-sut-configuration-parame">DUT/SUT Configuration Parameters</name>
            <t indent="0" pn="section-7.2.3.1-1">DUT/SUT parameters <bcp14>MUST</bcp14> conform to the requirements defined in
            <xref target="DUT-SUT_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Any configuration changes
            for this specific benchmarking test <bcp14>MUST</bcp14> be documented.</t>
          </section>
          <section anchor="Test_Equipment_Configuration_Parameters_HTTP_CPS" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.3.2">
            <name slugifiedName="name-test-equipment-configuration-">Test Equipment Configuration Parameters</name>
            <t indent="0" pn="section-7.2.3.2-1">Test equipment configuration parameters <bcp14>MUST</bcp14>
            conform to the requirements defined in <xref target="Test_Equipment_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.3"/>. The
            following parameters <bcp14>MUST</bcp14> be documented for this
            benchmarking test:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.2.3.2-2">
              <li pn="section-7.2.3.2-2.1">Client IP address ranges defined in <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.2.3.2-2.2">Server IP address ranges defined in <xref target="Server_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.2.3"/></li>
              <li pn="section-7.2.3.2-2.3">Traffic distribution ratio between IPv4 and IPv6 defined in
	      <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.2.3.2-2.4">Target connections per second: Initial value from the product
	      datasheet or the value defined based on the requirement for a
	      specific deployment scenario</li>
              <li pn="section-7.2.3.2-2.5">
                <t indent="0" pn="section-7.2.3.2-2.5.1">Initial connections per second: 10% of "Target connections
	      per second"</t>
                <t indent="0" pn="section-7.2.3.2-2.5.2">Note: Initial connections per second is not a KPI
	      to report. This value is configured on the traffic generator and
	      used to perform Step 1 (Test Initialization and Qualification)
	      described in <xref target="Test_Procedures_and_Expected_Results_TC_7_2" format="default" sectionFormat="of" derivedContent="Section 7.2.4"/>.</t>
              </li>
              <li pn="section-7.2.3.2-2.6">The <bcp14>RECOMMENDED</bcp14> response object sizes are 1,
	      2, 4, 16, and 64 KB.</li>
            </ul>
            <t indent="0" pn="section-7.2.3.2-3">The client <bcp14>MUST</bcp14> negotiate HTTP and close the
	      connection with FIN immediately after the completion of one
	      transaction. In each test iteration, the client
	      <bcp14>MUST</bcp14> send a GET request requesting a fixed HTTP
	      response object size.</t>
          </section>
          <section anchor="Validation_Criteria_HTTP_CPS" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.3.3">
            <name slugifiedName="name-test-results-validation-crit">Test Results Validation Criteria</name>
            <t indent="0" pn="section-7.2.3.3-1">The following criteria are the test results validation
            criteria. The test results validation criteria <bcp14>MUST</bcp14> be monitored
            during the whole sustain phase of the traffic load profile.</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-7.2.3.3-2">
	      <li pn="section-7.2.3.3-2.1" derivedCounter="a.">The number of failed application transactions (receiving any
                HTTP response code other than 200 OK) <bcp14>MUST</bcp14> be less than 0.001%
                (1 out of 100,000 transactions) of the attempted
                transactions.</li>
              <li pn="section-7.2.3.3-2.2" derivedCounter="b.">The number of terminated TCP connections due to unexpected TCP
                RST sent by the DUT/SUT <bcp14>MUST</bcp14> be less than 0.001% (1 out of 100,000
                connections) of the total initiated TCP connections.</li>
              <li pn="section-7.2.3.3-2.3" derivedCounter="c.">During the sustain phase, traffic <bcp14>MUST</bcp14> be forwarded at a
                constant rate (it is considered as a constant rate if any deviation
                of the traffic forwarding rate is less than 5%).</li>
              <li pn="section-7.2.3.3-2.4" derivedCounter="d.">Concurrent TCP connections <bcp14>MUST</bcp14> be constant during steady
                state, and any deviation of concurrent TCP connections <bcp14>MUST</bcp14> be
                less than 10%. This confirms the DUT opens and closes TCP
                connections at approximately the same rate.</li>
            </ol>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.3.4">
            <name slugifiedName="name-measurement-2">Measurement</name>
            <t indent="0" pn="section-7.2.3.4-1">TCP connections per second <bcp14>MUST</bcp14> be reported for each test
            iteration (for each object size).</t>
          </section>
        </section>
        <section anchor="Test_Procedures_and_Expected_Results_TC_7_2" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.4">
          <name slugifiedName="name-test-procedures-and-expected">Test Procedures and Expected Results</name>
          <t indent="0" pn="section-7.2.4-1">   The test procedure is designed to measure the DUT/SUT's rate of TCP 
   connections per second during the sustaining period of the traffic
   load profile. The test procedure consists of three major steps. Step
          1 ensures the DUT/SUT is able to reach the performance value
          (Initial connections per second) and meets the test results
          validation criteria when it was very minimally utilized.  Step 2
          determines whether the DUT/SUT is able to reach the target
          performance value within the test results validation criteria.  Step
          3 determines the maximum achievable performance value within the
          test results validation criteria.</t>
          <t indent="0" pn="section-7.2.4-2">This test procedure <bcp14>MAY</bcp14> be repeated multiple times with different
          IP types: IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic
          distribution.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.4.1">
            <name slugifiedName="name-step-1-test-initialization-a">Step 1: Test Initialization and Qualification</name>
            <t indent="0" pn="section-7.2.4.1-1">Verify the link status of all connected physical interfaces.
            All interfaces are expected to be in "UP" status.</t>
            <t indent="0" pn="section-7.2.4.1-2">Configure the traffic load profile of the test equipment to
            establish "Initial connections per second", as defined in <xref target="Test_Equipment_Configuration_Parameters_HTTP_CPS" format="default" sectionFormat="of" derivedContent="Section 7.2.3.2"/>. The
            traffic load profile <bcp14>MUST</bcp14> be defined as described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.2.4.1-3">The DUT/SUT <bcp14>MUST</bcp14> reach the "Initial connections per second"
            before the sustain phase. The measured KPIs during the sustain
            phase <bcp14>MUST</bcp14> meet all the test results validation criteria defined
            in <xref target="Validation_Criteria_HTTP_CPS" format="default" sectionFormat="of" derivedContent="Section 7.2.3.3"/>.</t>
            <t indent="0" pn="section-7.2.4.1-4">If the KPI metrics do not meet the test results validation
            criteria, the test procedure <bcp14>MUST NOT</bcp14> continue to Step 2.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.4.2">
            <name slugifiedName="name-step-2-test-run-with-target-">Step 2: Test Run with Target Objective</name>
            <t indent="0" pn="section-7.2.4.2-1">Configure test equipment to establish the target objective
            ("Target connections per second") defined in <xref target="Test_Equipment_Configuration_Parameters_HTTP_CPS" format="default" sectionFormat="of" derivedContent="Section 7.2.3.2"/>. The
            test equipment <bcp14>MUST</bcp14> follow the traffic load profile definition
            described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.2.4.2-2">During the ramp up and sustain phases of each test iteration,
            other KPIs, such as inspected throughput, concurrent TCP
            connections, and application transactions per second, <bcp14>MUST NOT</bcp14>
            reach the maximum value the DUT/SUT can support. The test results
            for specific test iterations <bcp14>MUST NOT</bcp14> be reported as valid results
            if the abovementioned KPI (especially inspected throughput)
            reaches the maximum value. (For example, if the test iteration with 64
            KB of HTTP response object size reached the maximum inspected
            throughput limitation of the DUT/SUT, the test iteration <bcp14>MAY</bcp14> be
            interrupted and the result for 64 KB must not be reported.)</t>
            <t indent="0" pn="section-7.2.4.2-3">The test equipment <bcp14>MUST</bcp14> start to measure and record all
            specified KPIs. Continue the test until all traffic profile phases
            are completed.</t>
            <t indent="0" pn="section-7.2.4.2-4">Within the test results validation criteria, the DUT/SUT is
            expected to reach the desired value of the target objective
            ("Target connections per second") in the sustain phase. Follow
            Step 3 if the measured value does not meet the target value or
            does not fulfill the test results validation criteria.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.4.3">
            <name slugifiedName="name-step-3-test-iteration-2">Step 3: Test Iteration</name>
            <t indent="0" pn="section-7.2.4.3-1">Determine the achievable TCP connections per second within the
            test results validation criteria.</t>
          </section>
        </section>
      </section>
      <section anchor="HTTP_TP" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-http-throughput">HTTP Throughput</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3.1">
          <name slugifiedName="name-objective-3">Objective</name>
          <t indent="0" pn="section-7.3.1-1">Determine the sustainable inspected throughput of the DUT/SUT for
          HTTP transactions varying the HTTP response object size.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3.2">
          <name slugifiedName="name-test-setup-4">Test Setup</name>
          <t indent="0" pn="section-7.3.2-1">The testbed setup <bcp14>MUST</bcp14> be configured as defined in <xref target="Test_Setup" format="default" sectionFormat="of" derivedContent="Section 4"/>. Any specific testbed configuration changes
          (number of interfaces, interface type, etc.) <bcp14>MUST</bcp14> be
          documented.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3.3">
          <name slugifiedName="name-test-parameters-3">Test Parameters</name>
          <t indent="0" pn="section-7.3.3-1">In this section, benchmarking-test-specific parameters are
          defined.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.3.3.1">
            <name slugifiedName="name-dut-sut-configuration-paramet">DUT/SUT Configuration Parameters</name>
            <t indent="0" pn="section-7.3.3.1-1">DUT/SUT parameters <bcp14>MUST</bcp14> conform to the requirements defined in
            <xref target="DUT-SUT_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Any configuration changes
            for this specific benchmarking test <bcp14>MUST</bcp14> be documented.</t>
          </section>
          <section anchor="Test_Equipment_Configuration_Parameters_HTTP_TP" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.3.3.2">
            <name slugifiedName="name-test-equipment-configuration-p">Test Equipment Configuration Parameters</name>
            <t indent="0" pn="section-7.3.3.2-1">Test equipment configuration parameters <bcp14>MUST</bcp14> conform to the
            requirements defined in <xref target="Test_Equipment_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.3"/>. The following parameters
            <bcp14>MUST</bcp14> be documented for this benchmarking test:</t>
            <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.3.3.2-2">
              <li pn="section-7.3.3.2-2.1">Client IP address ranges defined in <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.3.3.2-2.2">Server IP address ranges defined in <xref target="Server_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.2.3"/></li>
              <li pn="section-7.3.3.2-2.3">Traffic distribution ratio between IPv4 and IPv6 defined in
	      <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.3.3.2-2.4">Target inspected throughput: Aggregated line rate of one
	      or more interfaces used in the DUT/SUT or the value defined based on
	      the requirement for a specific deployment scenario</li>
              <li pn="section-7.3.3.2-2.5">
                <t indent="0" pn="section-7.3.3.2-2.5.1">Initial throughput: 10% of "Target inspected throughput"</t>
                <t indent="0" pn="section-7.3.3.2-2.5.2">Note: Initial throughput is not a KPI to report. This value is
	      configured on the traffic generator and used to perform Step 1
	      (Test Initialization and Qualification) described in <xref target="Test_Procedures_and_Expected_Results_TC_7_3" format="default" sectionFormat="of" derivedContent="Section 7.3.4"/>.</t>
              </li>
              <li pn="section-7.3.3.2-2.6">Number of HTTP response object requests (transactions) per
	      connection: 10</li>
              <li pn="section-7.3.3.2-2.7">
                <bcp14>RECOMMENDED</bcp14> HTTP response object size: 1, 16,
	      64, and 256 KB and mixed objects defined in <xref target="table4" format="default" sectionFormat="of" derivedContent="Table 5"/></li>
            </ul>
            <table anchor="table4" align="center" pn="table-5">
              <name slugifiedName="name-mixed-objects">Mixed Objects</name>
              <thead>
                <tr>
                  <th align="left" colspan="1" rowspan="1">Object size (KB)</th>
                  <th align="left" colspan="1" rowspan="1">Number of requests / Weight</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0.2</td>
                  <td align="left" colspan="1" rowspan="1">1</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">6</td>
                  <td align="left" colspan="1" rowspan="1">1</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">8</td>
                  <td align="left" colspan="1" rowspan="1">1</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">9</td>
                  <td align="left" colspan="1" rowspan="1">1</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">10</td>
                  <td align="left" colspan="1" rowspan="1">1</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">25</td>
                  <td align="left" colspan="1" rowspan="1">1</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">26</td>
                  <td align="left" colspan="1" rowspan="1">1</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">35</td>
                  <td align="left" colspan="1" rowspan="1">1</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">59</td>
                  <td align="left" colspan="1" rowspan="1">1</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">347</td>
                  <td align="left" colspan="1" rowspan="1">1</td>
                </tr>
              </tbody>
            </table>
          </section>
          <section anchor="Validation_Criteria_HTTP_TP" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.3.3.3">
            <name slugifiedName="name-test-results-validation-crite">Test Results Validation Criteria</name>
            <t indent="0" pn="section-7.3.3.3-1">The following criteria are the test results validation
            criteria. The test results validation criteria <bcp14>MUST</bcp14> be monitored
            during the whole sustain phase of the traffic load profile.</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-7.3.3.3-2">
	      <li pn="section-7.3.3.3-2.1" derivedCounter="a.">The number of failed application transactions (receiving any
                HTTP response code other than 200 OK) <bcp14>MUST</bcp14> be less than 0.001%
                (1 out of 100,000 transactions) of the total attempted transactions.</li>
              <li pn="section-7.3.3.3-2.2" derivedCounter="b.">Traffic <bcp14>MUST</bcp14> be forwarded at a constant rate (it is considered as
                a constant rate if any deviation of the traffic forwarding rate is
                less than 5%).</li>
              <li pn="section-7.3.3.3-2.3" derivedCounter="c.">Concurrent TCP connections <bcp14>MUST</bcp14> be constant during steady
                state, and any deviation of concurrent TCP connections <bcp14>MUST</bcp14> be
                less than 10%. This confirms the DUT opens and closes TCP
                connections at approximately the same rate.</li>
            </ol>
          </section>
          <section anchor="Measurement_TP" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.3.3.4">
            <name slugifiedName="name-measurement-3">Measurement</name>
            <t indent="0" pn="section-7.3.3.4-1">Inspected throughput and HTTP transactions per second <bcp14>MUST</bcp14> be
            reported for each object size.</t>
          </section>
        </section>
        <section anchor="Test_Procedures_and_Expected_Results_TC_7_3" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.4">
          <name slugifiedName="name-test-procedures-and-expected-">Test Procedures and Expected Results</name>
          <t indent="0" pn="section-7.3.4-1">The test procedure is designed to measure HTTP throughput of the
          DUT/ SUT. The test procedure consists of three major steps. Step 1
          ensures the DUT/SUT is able to reach the performance value (initial
          throughput) and meets the test results validation criteria when it
          was very minimally utilized.  Step 2 determines whether the DUT/SUT is
          able to reach the target performance value within the test results
          validation criteria.  Step 3 determines the maximum achievable
          performance value within the test results validation criteria.</t>
          <t indent="0" pn="section-7.3.4-2">This test procedure <bcp14>MAY</bcp14> be repeated multiple
	    times with different IPv4 and IPv6 traffic distributions and HTTP
	    response object sizes.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.3.4.1">
            <name slugifiedName="name-step-1-test-initialization-an">Step 1: Test Initialization and Qualification</name>
            <t indent="0" pn="section-7.3.4.1-1">Verify the link status of all connected physical interfaces.
            All interfaces are expected to be in "UP" status.</t>
            <t indent="0" pn="section-7.3.4.1-2">Configure the traffic load profile of the test equipment to
            establish "initial throughput", as defined in <xref target="Test_Equipment_Configuration_Parameters_HTTP_TP" format="default" sectionFormat="of" derivedContent="Section 7.3.3.2"/>.</t>
            <t indent="0" pn="section-7.3.4.1-3">The traffic load profile <bcp14>MUST</bcp14> be defined as described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>. The DUT/SUT <bcp14>MUST</bcp14> reach the
            "initial throughput" during the sustain phase. Measure
            all KPIs, as defined in <xref target="Measurement_TP" format="default" sectionFormat="of" derivedContent="Section 7.3.3.4"/>.</t>
            <t indent="0" pn="section-7.3.4.1-4">The measured KPIs during the sustain phase <bcp14>MUST</bcp14> meet the test
            results validation criteria "a" defined in <xref target="Validation_Criteria_HTTP_TP" format="default" sectionFormat="of" derivedContent="Section 7.3.3.3"/>. The test results
            validation criteria "b" and "c" are <bcp14>OPTIONAL</bcp14> for Step 1.</t>
            <t indent="0" pn="section-7.3.4.1-5">If the KPI metrics do not meet the test results validation
            criteria, the test procedure <bcp14>MUST NOT</bcp14> be continued to Step
            2.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.3.4.2">
            <name slugifiedName="name-step-2-test-run-with-target-o">Step 2: Test Run with Target Objective</name>
            <t indent="0" pn="section-7.3.4.2-1">Configure test equipment to establish the target objective
            ("Target inspected throughput") defined in <xref target="Test_Equipment_Configuration_Parameters_HTTP_TP" format="default" sectionFormat="of" derivedContent="Section 7.3.3.2"/>. The
            test equipment <bcp14>MUST</bcp14> start to measure and record all specified
            KPIs. Continue the test until all traffic profile phases are
            completed.</t>
            <t indent="0" pn="section-7.3.4.2-2">Within the test results validation criteria, the DUT/SUT is
            expected to reach the desired value of the target objective in the
            sustain phase. Follow Step 3 if the measured value does not meet
            the target value or does not fulfill the test results validation
            criteria.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.3.4.3">
            <name slugifiedName="name-step-3-test-iteration-3">Step 3: Test Iteration</name>
            <t indent="0" pn="section-7.3.4.3-1">Determine the achievable inspected throughput within the test
            results validation criteria and measure the KPI metric
            transactions per second. The final test iteration <bcp14>MUST</bcp14> be
            performed for the test duration defined in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
          </section>
        </section>
      </section>
      <section anchor="HTTP-Latency" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-http-transaction-latency">HTTP Transaction Latency</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.4.1">
          <name slugifiedName="name-objective-4">Objective</name>
          <t indent="0" pn="section-7.4.1-1">Using HTTP traffic, determine the HTTP transaction latency when the
          DUT is running with sustainable HTTP transactions per second
          supported by the DUT/SUT under different HTTP response object
          sizes.</t>
          <t indent="0" pn="section-7.4.1-2">Test iterations <bcp14>MUST</bcp14> be performed with different HTTP response
          object sizes in two different scenarios: one with a single
          transaction and the other with multiple transactions within a single
          TCP connection. For consistency, both the single and multiple
          transaction tests <bcp14>MUST</bcp14> be configured with the same HTTP version.</t>
          <t indent="0" pn="section-7.4.1-3">Scenario 1: The client <bcp14>MUST</bcp14> negotiate HTTP and close the
          connection with FIN immediately after the completion of a single
          transaction (GET and RESPONSE).</t>
          <t indent="0" pn="section-7.4.1-4">Scenario 2: The client <bcp14>MUST</bcp14> negotiate HTTP and close the
          connection with FIN immediately after the completion of 10 transactions
          (GET and RESPONSE) within a single TCP connection.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.4.2">
          <name slugifiedName="name-test-setup-5">Test Setup</name>
          <t indent="0" pn="section-7.4.2-1">The testbed setup <bcp14>MUST</bcp14> be configured as defined in <xref target="Test_Setup" format="default" sectionFormat="of" derivedContent="Section 4"/>. Any specific testbed configuration changes
          (number of interfaces, interface type, etc.) <bcp14>MUST</bcp14> be
          documented.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.4.3">
          <name slugifiedName="name-test-parameters-4">Test Parameters</name>
          <t indent="0" pn="section-7.4.3-1">In this section, benchmarking-test-specific parameters are
          defined.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.4.3.1">
            <name slugifiedName="name-dut-sut-configuration-paramete">DUT/SUT Configuration Parameters</name>
            <t indent="0" pn="section-7.4.3.1-1">DUT/SUT parameters <bcp14>MUST</bcp14> conform to the requirements defined in
            <xref target="DUT-SUT_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Any configuration changes
            for this specific benchmarking test <bcp14>MUST</bcp14> be documented.</t>
          </section>
          <section anchor="Test_Equipment_Configuration_Parameters_HTTP_latency" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.4.3.2">
            <name slugifiedName="name-test-equipment-configuration-pa">Test Equipment Configuration Parameters</name>
            <t indent="0" pn="section-7.4.3.2-1">Test equipment configuration parameters <bcp14>MUST</bcp14> conform to the
            requirements defined in <xref target="Test_Equipment_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.3"/>. The following parameters
            <bcp14>MUST</bcp14> be documented for this benchmarking test:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.4.3.2-2">
              <li pn="section-7.4.3.2-2.1">Client IP address ranges defined in <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.4.3.2-2.2">Server IP address ranges defined in <xref target="Server_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.2.3"/></li>
              <li pn="section-7.4.3.2-2.3">Traffic distribution ratio between IPv4 and IPv6 defined in
	      <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.4.3.2-2.4">Target objective for scenario 1: 50% of the connections per
	      second measured in the benchmarking test <xref format="default" target="HTTP_CPS" sectionFormat="of" derivedContent="Section 7.2">TCP connections per second with HTTP traffic</xref></li>
              <li pn="section-7.4.3.2-2.5">Target objective for scenario 2: 50% of the inspected
	      throughput measured in the benchmarking test <xref format="default" target="HTTP_TP" sectionFormat="of" derivedContent="Section 7.3">HTTP throughput</xref></li>
              <li pn="section-7.4.3.2-2.6">Initial objective for scenario 1: 10% of "Target objective
	      for scenario 1"</li>
              <li pn="section-7.4.3.2-2.7">
                <t indent="0" pn="section-7.4.3.2-2.7.1">Initial objective for scenario 2: 10% of "Target objective
	      for scenario 2"</t>
                <t indent="0" pn="section-7.4.3.2-2.7.2">Note: The initial objectives are not KPIs to
	      report. These values are configured on the traffic generator and
	      used to perform Step 1 (Test Initialization and Qualification)
	      described in <xref target="Test_Procedures_and_Expected_Results_TC_7_4" format="default" sectionFormat="of" derivedContent="Section 7.4.4"/>.</t>
              </li>
              <li pn="section-7.4.3.2-2.8">HTTP transaction per TCP connection: Test scenario 1 with a
	      single transaction and test scenario 2 with 10 transactions</li>
              <li pn="section-7.4.3.2-2.9">HTTP with GET request requesting a single object: The
	      <bcp14>RECOMMENDED</bcp14> object sizes are 1, 16, and 64
	      KB. For each test iteration, the client <bcp14>MUST</bcp14>
	      request a single HTTP response object size.</li>
            </ul>
          </section>
          <section anchor="Validation_Criteria_HTTP_Latency" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.4.3.3">
            <name slugifiedName="name-test-results-validation-criter">Test Results Validation Criteria</name>
            <t indent="0" pn="section-7.4.3.3-1">The following criteria are the test results validation
            criteria. The test results validation criteria <bcp14>MUST</bcp14> be monitored
            during the whole sustain phase of the traffic load profile.</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-7.4.3.3-2">
	      <li pn="section-7.4.3.3-2.1" derivedCounter="a.">The number of failed application transactions (receiving any
                HTTP response code other than 200 OK) <bcp14>MUST</bcp14> be less than 0.001%
                (1 out of 100,000 transactions) of the total attempted transactions.</li>
              <li pn="section-7.4.3.3-2.2" derivedCounter="b.">The number of terminated TCP connections due to unexpected TCP
                RST sent by the DUT/SUT <bcp14>MUST</bcp14> be less than 0.001% (1 out of 100,000
                connections) of the total initiated TCP connections.</li>
              <li pn="section-7.4.3.3-2.3" derivedCounter="c.">During the sustain phase, traffic <bcp14>MUST</bcp14> be forwarded at a
                constant rate (it is considered as a constant rate if any deviation
                of the traffic forwarding rate is less than 5%).</li>
              <li pn="section-7.4.3.3-2.4" derivedCounter="d.">Concurrent TCP connections <bcp14>MUST</bcp14> be constant during steady
                state, and any deviation of concurrent TCP connections <bcp14>MUST</bcp14> be
                less than 10%. This confirms the DUT opens and closes TCP
                connections at approximately the same rate.</li>
              <li pn="section-7.4.3.3-2.5" derivedCounter="e.">After ramp up, the DUT <bcp14>MUST</bcp14> achieve the target objectives
                defined in <xref target="Test_Equipment_Configuration_Parameters_HTTP_latency" format="default" sectionFormat="of" derivedContent="Section 7.4.3.2"/>
                and remain in that state for the entire test duration (sustain
                phase).</li>
            </ol>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.4.3.4">
            <name slugifiedName="name-measurement-4">Measurement</name>
            <t indent="0" pn="section-7.4.3.4-1">The TTFB (minimum, average, and maximum) and TTLB (minimum,
            average, and maximum) <bcp14>MUST</bcp14> be reported for each object size.</t>
          </section>
        </section>
        <section anchor="Test_Procedures_and_Expected_Results_TC_7_4" numbered="true" toc="include" removeInRFC="false" pn="section-7.4.4">
          <name slugifiedName="name-test-procedures-and-expected-r">Test Procedures and Expected Results</name>
          <t indent="0" pn="section-7.4.4-1">The test procedure is designed to measure the TTFB or TTLB when the
          DUT/SUT is operating close to 50% of its maximum achievable
          connections per second or inspected throughput. The test procedure
          consists of two major steps. Step 1 ensures the DUT/SUT is able to
          reach the initial performance values and meets the test results
          validation criteria when it was very minimally utilized.  Step 2
          measures the latency values within the test results validation
          criteria.</t>
          <t indent="0" pn="section-7.4.4-2">This test procedure <bcp14>MAY</bcp14> be repeated multiple times
          with different IP types (IPv4 only, IPv6 only, and IPv4 and IPv6
          mixed traffic distribution), HTTP response object sizes, and single
          and multiple transactions per connection scenarios.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.4.4.1">
            <name slugifiedName="name-step-1-test-initialization-and">Step 1: Test Initialization and Qualification</name>
            <t indent="0" pn="section-7.4.4.1-1">Verify the link status of all connected physical interfaces.
            All interfaces are expected to be in "UP" status.</t>
            <t indent="0" pn="section-7.4.4.1-2">Configure the traffic load profile of the test equipment to
            establish the initial objectives, as defined in <xref target="Test_Equipment_Configuration_Parameters_HTTP_latency" format="default" sectionFormat="of" derivedContent="Section 7.4.3.2"/>.
            The traffic load profile <bcp14>MUST</bcp14> be defined as described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.4.4.1-3">The DUT/SUT <bcp14>MUST</bcp14> reach the initial objectives before the
            sustain phase. The measured KPIs during the sustain phase <bcp14>MUST</bcp14>
            meet all the test results validation criteria defined in <xref target="Validation_Criteria_HTTP_Latency" format="default" sectionFormat="of" derivedContent="Section 7.4.3.3"/>.</t>
            <t indent="0" pn="section-7.4.4.1-4">If the KPI metrics do not meet the test results validation
            criteria, the test procedure <bcp14>MUST NOT</bcp14> be continued to Step
            2.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.4.4.2">
            <name slugifiedName="name-step-2-test-run-with-target-ob">Step 2: Test Run with Target Objective</name>
            <t indent="0" pn="section-7.4.4.2-1">Configure test equipment to establish the target objectives
            defined in <xref target="Test_Equipment_Configuration_Parameters_HTTP_latency" format="default" sectionFormat="of" derivedContent="Section 7.4.3.2"/>.
            The test equipment <bcp14>MUST</bcp14> follow the traffic load profile definition
            described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.4.4.2-2">The test equipment <bcp14>MUST</bcp14> start to measure and record all
            specified KPIs. Continue the test until all traffic profile phases
            are completed.</t>
            <t indent="0" pn="section-7.4.4.2-3">Within the test results validation criteria, the DUT/SUT <bcp14>MUST</bcp14>
            reach the desired value of the target objective in the sustain
            phase.</t>
            <t indent="0" pn="section-7.4.4.2-4">Measure the minimum, average, and maximum values of the TTFB and
            TTLB.</t>
          </section>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.5">
        <name slugifiedName="name-concurrent-tcp-connection-c">Concurrent TCP Connection Capacity with HTTP Traffic</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.5.1">
          <name slugifiedName="name-objective-5">Objective</name>
          <t indent="0" pn="section-7.5.1-1">Determine the number of concurrent TCP connections that the DUT/SUT sustains when
	  using HTTP traffic.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.5.2">
          <name slugifiedName="name-test-setup-6">Test Setup</name>
          <t indent="0" pn="section-7.5.2-1">The testbed setup <bcp14>MUST</bcp14> be configured as defined in <xref target="Test_Setup" format="default" sectionFormat="of" derivedContent="Section 4"/>. Any specific testbed configuration changes
          (number of interfaces, interface type, etc.) <bcp14>MUST</bcp14> be
          documented.</t>
        </section>
        <section anchor="CC_parameter" numbered="true" toc="include" removeInRFC="false" pn="section-7.5.3">
          <name slugifiedName="name-test-parameters-5">Test Parameters</name>
          <t indent="0" pn="section-7.5.3-1">In this section, benchmarking-test-specific parameters are
          defined.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.5.3.1">
            <name slugifiedName="name-dut-sut-configuration-parameter">DUT/SUT Configuration Parameters</name>
            <t indent="0" pn="section-7.5.3.1-1">DUT/SUT parameters <bcp14>MUST</bcp14> conform to the requirements defined in
            <xref target="DUT-SUT_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Any configuration changes
            for this specific benchmarking test <bcp14>MUST</bcp14> be documented.</t>
          </section>
          <section anchor="Test_Equipment_Configuration_Parameters_HTTP_CC" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.5.3.2">
            <name slugifiedName="name-test-equipment-configuration-par">Test Equipment Configuration Parameters</name>
            <t indent="0" pn="section-7.5.3.2-1">Test equipment configuration parameters <bcp14>MUST</bcp14> conform to the
            requirements defined in <xref target="Test_Equipment_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.3"/>. The following parameters
            <bcp14>MUST</bcp14> be noted for this benchmarking test:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.5.3.2-2">
              <li pn="section-7.5.3.2-2.1">Client IP address ranges defined in <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.5.3.2-2.2">Server IP address ranges defined in <xref target="Server_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.2.3"/></li>
              <li pn="section-7.5.3.2-2.3">Traffic distribution ratio between IPv4 and IPv6 defined in
                <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.5.3.2-2.4">Target concurrent connection: Initial value from the product
                datasheet or the value defined based on the requirement for a
                specific deployment scenario</li>
              <li pn="section-7.5.3.2-2.5">
                <t indent="0" pn="section-7.5.3.2-2.5.1">Initial concurrent connection: 10% of "Target concurrent
                connection"</t>
                <t indent="0" pn="section-7.5.3.2-2.5.2">Note: Initial concurrent connection is not a KPI to
		report. This value is configured on the traffic generator and
		used to perform Step 1 (Test Initialization and Qualification)
		described in <xref target="Test_Procedures_and_Expected_Results_TC_7_5" format="default" sectionFormat="of" derivedContent="Section 7.5.4"/>.</t>
              </li>
              <li pn="section-7.5.3.2-2.6">Maximum connections per second during ramp up phase: 50% of
                maximum connections per second measured in the benchmarking test
                <xref target="HTTP_CPS" format="default" sectionFormat="of" derivedContent="Section 7.2">TCP connections per
                second with HTTP traffic</xref></li>
              <li pn="section-7.5.3.2-2.7">Ramp up time (in traffic load profile for "Target
                concurrent connection"): "Target concurrent connection" /
                "Maximum connections per second during ramp up phase"</li>
              <li pn="section-7.5.3.2-2.8">Ramp up time (in traffic load profile for "Initial
                concurrent connection"): "Initial concurrent connection" /
                "Maximum connections per second during ramp up phase"</li>
            </ul>
            <t indent="0" pn="section-7.5.3.2-3">The client <bcp14>MUST</bcp14> negotiate HTTP, and each
		client <bcp14>MAY</bcp14> open multiple concurrent TCP
		connections per server endpoint IP.</t>
            <t indent="0" pn="section-7.5.3.2-4">Each client sends 10 GET requests requesting 1 KB HTTP
		response object in the same TCP connection (10
		transactions / TCP connections), and the delay (think time)
		between each transaction <bcp14>MUST</bcp14> be X seconds, where X is as follows.</t>
            <t indent="3" pn="section-7.5.3.2-5">X = ("Ramp up time" + "steady state time") / 10</t>
            <t indent="0" pn="section-7.5.3.2-6">The established connections <bcp14>MUST</bcp14> remain open until the ramp
            down phase of the test. During the ramp down phase, all
            connections <bcp14>MUST</bcp14> be successfully closed with FIN.</t>
          </section>
          <section anchor="CC_Test_Results_Validation_Criteria" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.5.3.3">
            <name slugifiedName="name-test-results-validation-criteri">Test Results Validation Criteria</name>
            <t indent="0" pn="section-7.5.3.3-1">The following criteria are the test results validation
            criteria. The test results validation criteria <bcp14>MUST</bcp14> be monitored
            during the whole sustain phase of the traffic load profile.</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-7.5.3.3-2">
	      <li pn="section-7.5.3.3-2.1" derivedCounter="a.">The number of failed application transactions (receiving any
                HTTP response code other than 200 OK) <bcp14>MUST</bcp14> be less than 0.001%
                (1 out of 100,000 transactions) of the total attempted
                transactions.</li>
              <li pn="section-7.5.3.3-2.2" derivedCounter="b.">The number of terminated TCP connections due to unexpected TCP
                RST sent by the DUT/SUT <bcp14>MUST</bcp14> be less than 0.001% (1 out of 100,000
                connections) of the total initiated TCP connections.</li>
              <li pn="section-7.5.3.3-2.3" derivedCounter="c.">During the sustain phase, traffic <bcp14>MUST</bcp14> be forwarded at a
                constant rate (it is considered as a constant rate if any deviation
                of the traffic forwarding rate is less than 5%).</li>
            </ol>
          </section>
          <section anchor="CC_Measurement" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.5.3.4">
            <name slugifiedName="name-measurement-5">Measurement</name>
            <t indent="0" pn="section-7.5.3.4-1">Average concurrent TCP connections <bcp14>MUST</bcp14> be reported for this
            benchmarking test.</t>
          </section>
        </section>
        <section anchor="Test_Procedures_and_Expected_Results_TC_7_5" numbered="true" toc="include" removeInRFC="false" pn="section-7.5.4">
          <name slugifiedName="name-test-procedures-and-expected-re">Test Procedures and Expected Results</name>
          <t indent="0" pn="section-7.5.4-1">The test procedure is designed to measure the concurrent TCP
          connection capacity of the DUT/SUT at the sustaining period of the
          traffic load profile. The test procedure consists of three major
          steps. Step 1 ensures the DUT/SUT is able to reach the performance
          value (Initial concurrent connection) and meets the test results
          validation criteria when it was very minimally utilized.  Step 2
          determines whether the DUT/SUT is able to reach the target
          performance value within the test results validation criteria.  Step
          3 determines the maximum achievable performance value within the
          test results validation criteria.</t>
          <t indent="0" pn="section-7.5.4-2">This test procedure <bcp14>MAY</bcp14> be repeated multiple times with different
          IPv4 and IPv6 traffic distributions.</t>
          <section anchor="CC_Step1_Test_Initialization" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.5.4.1">
            <name slugifiedName="name-step-1-test-initialization-and-">Step 1: Test Initialization and Qualification</name>
            <t indent="0" pn="section-7.5.4.1-1">Verify the link status of all connected physical interfaces.
            All interfaces are expected to be in "UP" status.</t>
            <t indent="0" pn="section-7.5.4.1-2">Configure test equipment to establish "Initial concurrent
            connections" defined in <xref target="Test_Equipment_Configuration_Parameters_HTTP_CC" format="default" sectionFormat="of" derivedContent="Section 7.5.3.2"/>. Except
            ramp up time, the traffic load profile <bcp14>MUST</bcp14> be defined as
            described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.5.4.1-3">During the sustain phase, the DUT/SUT <bcp14>MUST</bcp14> reach the "Initial
            concurrent connections". The measured KPIs during the sustain
            phase <bcp14>MUST</bcp14> meet all the test results validation criteria defined
            in <xref target="CC_Test_Results_Validation_Criteria" format="default" sectionFormat="of" derivedContent="Section 7.5.3.3"/>.</t>
            <t indent="0" pn="section-7.5.4.1-4">If the KPI metrics do not meet the test results validation
            criteria, the test procedure <bcp14>MUST NOT</bcp14> be continued to Step
            2.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.5.4.2">
            <name slugifiedName="name-step-2-test-run-with-target-obj">Step 2: Test Run with Target Objective</name>
            <t indent="0" pn="section-7.5.4.2-1">Configure test equipment to establish the target objective
            ("Target concurrent TCP connections"). The test equipment <bcp14>MUST</bcp14>
            follow the traffic load profile definition (except ramp up time)
            as described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.5.4.2-2">During the ramp up and sustain phases, the other KPIs, such as
            inspected throughput, TCP connections per second, and application
            transactions per second, <bcp14>MUST NOT</bcp14> reach the maximum value the
            DUT/SUT can support.</t>
            <t indent="0" pn="section-7.5.4.2-3">The test equipment <bcp14>MUST</bcp14> start to measure and record KPIs
            defined in <xref target="CC_Measurement" format="default" sectionFormat="of" derivedContent="Section 7.5.3.4"/>. Continue the test
            until all traffic profile phases are completed.</t>
            <t indent="0" pn="section-7.5.4.2-4">Within the test results validation criteria, the DUT/SUT is
            expected to reach the desired value of the target objective in the
            sustain phase. Follow Step 3 if the measured value does not meet
            the target value or does not fulfill the test results validation
            criteria.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.5.4.3">
            <name slugifiedName="name-step-3-test-iteration-4">Step 3: Test Iteration</name>
            <t indent="0" pn="section-7.5.4.3-1">Determine the achievable concurrent TCP connections capacity
            within the test results validation criteria.</t>
          </section>
        </section>
      </section>
      <section anchor="HTTPS_CPS" numbered="true" toc="include" removeInRFC="false" pn="section-7.6">
        <name slugifiedName="name-tcp-or-quic-connections-per">TCP or QUIC Connections per Second with HTTPS Traffic</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.6.1">
          <name slugifiedName="name-objective-6">Objective</name>
          <t indent="0" pn="section-7.6.1-1">Using HTTPS traffic, determine the sustainable TLS session
          establishment rate supported by the DUT/SUT under different
          throughput load conditions.</t>
          <t indent="0" pn="section-7.6.1-2">Test iterations <bcp14>MUST</bcp14> include common cipher suites and key
          strengths, as well as forward-looking stronger keys. Specific test
          iterations <bcp14>MUST</bcp14> include ciphers and keys defined in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_CPS" format="default" sectionFormat="of" derivedContent="Section 7.6.3.2"/>.</t>
          <t indent="0" pn="section-7.6.1-3">For each cipher suite and key strength, test iterations <bcp14>MUST</bcp14> use
          a single HTTPS response object size defined in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_CPS" format="default" sectionFormat="of" derivedContent="Section 7.6.3.2"/> to
          measure connections per second performance under a variety of
          DUT/SUT security inspection load conditions.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.6.2">
          <name slugifiedName="name-test-setup-7">Test Setup</name>
          <t indent="0" pn="section-7.6.2-1">The testbed setup <bcp14>MUST</bcp14> be configured as defined in <xref target="Test_Setup" format="default" sectionFormat="of" derivedContent="Section 4"/>. Any specific testbed configuration changes
          (number of interfaces, interface type, etc.) <bcp14>MUST</bcp14> be
          documented.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.6.3">
          <name slugifiedName="name-test-parameters-6">Test Parameters</name>
          <t indent="0" pn="section-7.6.3-1">In this section, benchmarking-test-specific parameters are
          defined.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.6.3.1">
            <name slugifiedName="name-dut-sut-configuration-parameters">DUT/SUT Configuration Parameters</name>
            <t indent="0" pn="section-7.6.3.1-1">DUT/SUT parameters <bcp14>MUST</bcp14> conform to the requirements defined in
            <xref target="DUT-SUT_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Any configuration changes
            for this specific benchmarking test <bcp14>MUST</bcp14> be documented.</t>
          </section>
          <section anchor="Test_Equipment_Configuration_Parameters_HTTPS_CPS" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.6.3.2">
            <name slugifiedName="name-test-equipment-configuration-para">Test Equipment Configuration Parameters</name>
            <t indent="0" pn="section-7.6.3.2-1">Test equipment configuration parameters <bcp14>MUST</bcp14> conform to the
            requirements defined in <xref target="Test_Equipment_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.3"/>. The following parameters
            <bcp14>MUST</bcp14> be documented for this benchmarking test:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.6.3.2-2">
              <li pn="section-7.6.3.2-2.1">Client IP address ranges defined in <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.6.3.2-2.2">Server IP address ranges defined in <xref target="Server_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.2.3"/></li>
              <li pn="section-7.6.3.2-2.3">Traffic distribution ratio between IPv4 and IPv6 defined in
	      <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.6.3.2-2.4">Target connections per second: Initial value from the product
	      datasheet or the value defined based on the requirement for a
	      specific deployment scenario</li>
              <li pn="section-7.6.3.2-2.5">
                <t indent="0" pn="section-7.6.3.2-2.5.1">Initial connections per second: 10% of "Target connections
	      per second"</t>
                <t indent="0" pn="section-7.6.3.2-2.5.2">Note: Initial connections per second is not a KPI
	      to report. This value is configured on the traffic generator and
	      used to perform Step 1 (Test Initialization and Qualification)
	      described in <xref target="Test_Procedures_and_Expected_Results_TC_7_6" format="default" sectionFormat="of" derivedContent="Section 7.6.4"/>.)</t>
              </li>
              <li pn="section-7.6.3.2-2.6">
                <bcp14>RECOMMENDED</bcp14> ciphers and keys defined in <xref target="Emulated_web_Browser_attributes" format="default" sectionFormat="of" derivedContent="Section 4.3.1.4"/></li>
              <li pn="section-7.6.3.2-2.7">The <bcp14>RECOMMENDED</bcp14>
            object sizes are 1, 2, 4, 16, and 64 KB.</li>
            </ul>
            <t indent="0" pn="section-7.6.3.2-3">The client <bcp14>MUST</bcp14> negotiate HTTPS and close the connection
            without error immediately after the completion of one transaction.
            In each test iteration, the client <bcp14>MUST</bcp14> send a GET request
            requesting a fixed HTTPS response object size.</t>
          </section>
          <section anchor="Validation_Criteria_HTTPS_CPS" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.6.3.3">
            <name slugifiedName="name-test-results-validation-criteria">Test Results Validation Criteria</name>
            <t indent="0" pn="section-7.6.3.3-1">The following criteria are the test results validation
            criteria. The test results validation criteria <bcp14>MUST</bcp14> be monitored
            during the whole test duration.</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-7.6.3.3-2">
	      <li pn="section-7.6.3.3-2.1" derivedCounter="a.">The number of failed application transactions (receiving any
                HTTP response code other than 200 OK) <bcp14>MUST</bcp14> be less than 0.001%
                (1 out of 100,000 transactions) of the attempted transactions.</li>
              <li pn="section-7.6.3.3-2.2" derivedCounter="b.">The number of terminated TCP connections due to unexpected TCP
                RST sent by the DUT/SUT <bcp14>MUST</bcp14> be less than 0.001% (1 out of 100,000
                connections) of the total initiated TCP connections. If HTTP/3 is
                used, the number of terminated QUIC connections due to
                unexpected errors <bcp14>MUST</bcp14> be less than 0.001% (1 out of 100,000
                connections) of the total initiated QUIC connections.</li>
              <li pn="section-7.6.3.3-2.3" derivedCounter="c.">During the sustain phase, traffic <bcp14>MUST</bcp14> be forwarded at a
                constant rate (it is considered as a constant rate if any deviation
                of the traffic forwarding rate is less than 5%).</li>
              <li pn="section-7.6.3.3-2.4" derivedCounter="d.">The concurrent TCP connections generation rate <bcp14>MUST</bcp14> be constant
                during steady state, and any deviation of concurrent TCP
                connections <bcp14>MUST</bcp14> be less than 10%. If HTTP/3 is used, the
                concurrent QUIC connections generation rate <bcp14>MUST</bcp14> be constant
                during steady state, and any deviation of concurrent QUIC
                connections <bcp14>MUST</bcp14> be less than 10%. This confirms the DUT opens
                and closes connections at approximately the same rate.</li>
            </ol>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.6.3.4">
            <name slugifiedName="name-measurement-6">Measurement</name>
            <t indent="0" pn="section-7.6.3.4-1">If HTTP 1.1 or HTTP/2 is used, TCP connections per second <bcp14>MUST</bcp14>
            be reported for each test iteration (for each object size).</t>
            <t indent="0" pn="section-7.6.3.4-2">If HTTP/3 is used, QUIC connections per second <bcp14>MUST</bcp14> be measured
            and reported for each test iteration (for each object size).</t>
            <t indent="0" pn="section-7.6.3.4-3">The KPI metric TLS handshake rate can be measured in the test
            using 1 KB object size.</t>
          </section>
        </section>
        <section anchor="Test_Procedures_and_Expected_Results_TC_7_6" numbered="true" toc="include" removeInRFC="false" pn="section-7.6.4">
          <name slugifiedName="name-test-procedures-and-expected-res">Test Procedures and Expected Results</name>
          <t indent="0" pn="section-7.6.4-1">   The test procedure is designed to measure the DUT/SUT's rate of TCP
   or QUIC connections per second during the sustaining period of the
   traffic load profile. The test procedure consists of three
          major steps. Step 1 ensures the DUT/SUT is able to reach the
          performance value (Initial connections per second) and meets the
          test results validation criteria when it was very minimally
          utilized.  Step 2 determines whether the DUT/SUT is able to reach
          the target performance value within the test results validation
          criteria.  Step 3 determines the maximum achievable performance
          value within the test results validation criteria.</t>
          <t indent="0" pn="section-7.6.4-2">This test procedure <bcp14>MAY</bcp14> be repeated multiple times with different
          IPv4 and IPv6 traffic distributions.</t>
          <section anchor="TLS_Handshake_Step1_Test_Initialization" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.6.4.1">
            <name slugifiedName="name-step-1-test-initialization-and-q">Step 1: Test Initialization and Qualification</name>
            <t indent="0" pn="section-7.6.4.1-1">Verify the link status of all connected physical interfaces.
            All interfaces are expected to be in "UP" status.</t>
            <t indent="0" pn="section-7.6.4.1-2">Configure the traffic load profile of the test equipment to
            establish "Initial connections per second", as defined in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_CPS" format="default" sectionFormat="of" derivedContent="Section 7.6.3.2"/>. The
            traffic load profile <bcp14>MUST</bcp14> be defined as described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.6.4.1-3">The DUT/SUT <bcp14>MUST</bcp14> reach the "Initial connections per second"
            before the sustain phase. The measured KPIs during the sustain
            phase <bcp14>MUST</bcp14> meet all the test results validation criteria defined
            in <xref target="Validation_Criteria_HTTPS_CPS" format="default" sectionFormat="of" derivedContent="Section 7.6.3.3"/>.</t>
            <t indent="0" pn="section-7.6.4.1-4">If the KPI metrics do not meet the test results validation
            criteria, the test procedure <bcp14>MUST NOT</bcp14> be continued to Step
            2.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.6.4.2">
            <name slugifiedName="name-step-2-test-run-with-target-obje">Step 2: Test Run with Target Objective</name>
            <t indent="0" pn="section-7.6.4.2-1">Configure test equipment to establish "Target connections per
            second", as defined in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_CPS" format="default" sectionFormat="of" derivedContent="Section 7.6.3.2"/>. The
            test equipment <bcp14>MUST</bcp14> follow the traffic load profile definition
            described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.6.4.2-2">During the ramp up and sustain phases, other KPIs, such as
            inspected throughput, concurrent TCP or QUIC connections, and
            application transactions per second, <bcp14>MUST NOT</bcp14> reach the maximum
            value the DUT/SUT can support. The test results for the specific
            test iteration <bcp14>MUST NOT</bcp14> be reported as valid results if the
	    abovementioned KPI (especially inspected throughput) reaches the
            maximum value. (For example, if the test iteration with 64 KB of
            HTTPS response object size reached the maximum inspected
            throughput limitation of the DUT, the test iteration <bcp14>MAY</bcp14> be
            interrupted, and the result for 64 KB should not be
            reported).</t>
            <t indent="0" pn="section-7.6.4.2-3">The test equipment <bcp14>MUST</bcp14> start to measure and record all
            specified KPIs. Continue the test until all traffic profile phases
            are completed.</t>
            <t indent="0" pn="section-7.6.4.2-4">Within the test results validation criteria, the DUT/SUT is
            expected to reach the desired value of the target objective
            ("Target connections per second") in the sustain phase. Follow
            Step 3 if the measured value does not meet the target value or
            does not fulfill the test results validation criteria.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.6.4.3">
            <name slugifiedName="name-step-3-test-iteration-5">Step 3: Test Iteration</name>
            <t indent="0" pn="section-7.6.4.3-1">Determine the achievable connections per second within the test
            results validation criteria.</t>
          </section>
        </section>
      </section>
      <section anchor="HTTPS_TP" numbered="true" toc="include" removeInRFC="false" pn="section-7.7">
        <name slugifiedName="name-https-throughput">HTTPS Throughput</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.7.1">
          <name slugifiedName="name-objective-7">Objective</name>
          <t indent="0" pn="section-7.7.1-1">Determine the sustainable inspected throughput of the DUT/SUT for
          HTTPS transactions by varying the HTTPS response object size.</t>
          <t indent="0" pn="section-7.7.1-2">Test iterations <bcp14>MUST</bcp14> include common cipher suites and key
          strengths, as well as forward-looking stronger keys. Specific test
          iterations <bcp14>MUST</bcp14> include the ciphers and keys defined in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_TP" format="default" sectionFormat="of" derivedContent="Section 7.7.3.2"/>.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.7.2">
          <name slugifiedName="name-test-setup-8">Test Setup</name>
          <t indent="0" pn="section-7.7.2-1">The testbed setup <bcp14>MUST</bcp14> be configured as defined in <xref target="Test_Setup" format="default" sectionFormat="of" derivedContent="Section 4"/>. Any specific testbed configuration changes
          (number of interfaces, interface type, etc.) <bcp14>MUST</bcp14> be
          documented.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.7.3">
          <name slugifiedName="name-test-parameters-7">Test Parameters</name>
          <t indent="0" pn="section-7.7.3-1">In this section, benchmarking-test-specific parameters are
          defined.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.7.3.1">
            <name slugifiedName="name-dut-sut-configuration-parameters-2">DUT/SUT Configuration Parameters</name>
            <t indent="0" pn="section-7.7.3.1-1">DUT/SUT parameters <bcp14>MUST</bcp14> conform to the requirements defined in
            <xref target="DUT-SUT_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Any configuration changes
            for this specific benchmarking test <bcp14>MUST</bcp14> be documented.</t>
          </section>
          <section anchor="Test_Equipment_Configuration_Parameters_HTTPS_TP" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.7.3.2">
            <name slugifiedName="name-test-equipment-configuration-param">Test Equipment Configuration Parameters</name>
            <t indent="0" pn="section-7.7.3.2-1">Test equipment configuration parameters <bcp14>MUST</bcp14> conform to the
            requirements defined in <xref target="Test_Equipment_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.3"/>. The following parameters
            <bcp14>MUST</bcp14> be documented for this benchmarking test:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.7.3.2-2">
              <li pn="section-7.7.3.2-2.1">Client IP address ranges defined in <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.7.3.2-2.2">Server IP address ranges defined in <xref target="Server_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.2.3"/></li>
              <li pn="section-7.7.3.2-2.3">Traffic distribution ratio between IPv4 and IPv6 defined in
	      <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.7.3.2-2.4">Target inspected throughput: Aggregated line rate of one or more
	      interfaces used in the DUT/SUT or the value defined based on
	      the requirement for a specific deployment scenario</li>
              <li pn="section-7.7.3.2-2.5">
                <t indent="0" pn="section-7.7.3.2-2.5.1">Initial throughput: 10% of "Target inspected throughput"</t>
                <t indent="0" pn="section-7.7.3.2-2.5.2">Note: Initial throughput is not a KPI to report. This value is
	      configured on the traffic generator and used to perform Step 1
	      (Test Initialization and Qualification) described in <xref target="Test_Procedures_and_Expected_Results_TC_7_7" format="default" sectionFormat="of" derivedContent="Section 7.7.4"/>.</t>
              </li>
              <li pn="section-7.7.3.2-2.6">Number of HTTPS response object requests (transactions) per
	      connection: 10</li>
              <li pn="section-7.7.3.2-2.7">
                <bcp14>RECOMMENDED</bcp14> ciphers and keys defined in <xref target="Emulated_web_Browser_attributes" format="default" sectionFormat="of" derivedContent="Section 4.3.1.4"/></li>
              <li pn="section-7.7.3.2-2.8">
                <bcp14>RECOMMENDED</bcp14> HTTPS response object size: 1,
	      16, 64, and 256 KB and mixed objects defined in <xref target="table4" format="default" sectionFormat="of" derivedContent="Table 5"/> of <xref target="Test_Equipment_Configuration_Parameters_HTTP_TP" format="default" sectionFormat="of" derivedContent="Section 7.3.3.2"/></li>
            </ul>
          </section>
          <section anchor="Validation_Criteria_HTTPS_TP" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.7.3.3">
            <name slugifiedName="name-test-results-validation-criteria-2">Test Results Validation Criteria</name>
            <t indent="0" pn="section-7.7.3.3-1">The following criteria are the test results validation
            criteria. The test results validation criteria <bcp14>MUST</bcp14> be monitored
            during the whole sustain phase of the traffic load profile.</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-7.7.3.3-2">
	      <li pn="section-7.7.3.3-2.1" derivedCounter="a.">The number of failed application transactions (receiving any
                HTTP response code other than 200 OK) <bcp14>MUST</bcp14> be less than 0.001%
                (1 out of 100,000 transactions) of the attempted transactions.</li>
              <li pn="section-7.7.3.3-2.2" derivedCounter="b.">Traffic <bcp14>MUST</bcp14> be generated at a constant rate (it is considered as
                a constant rate if any deviation of the traffic forwarding rate is
                less than 5%).</li>
              <li pn="section-7.7.3.3-2.3" derivedCounter="c.">The concurrent generated TCP connections <bcp14>MUST</bcp14> be constant
                during steady state, and any deviation of concurrent TCP
                connections <bcp14>MUST</bcp14> be less than 10%. If HTTP/3 is used, the
                concurrent generated QUIC connections <bcp14>MUST</bcp14> be constant during
                steady state, and any deviation of concurrent QUIC connections
                <bcp14>MUST</bcp14> be less than 10%. This confirms the DUT opens and closes
                connections at approximately the same rate.</li>
            </ol>
          </section>
          <section anchor="Measurement_HTTPS_TP" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.7.3.4">
            <name slugifiedName="name-measurement-7">Measurement</name>
            <t indent="0" pn="section-7.7.3.4-1">Inspected throughput and HTTPS transactions per second <bcp14>MUST</bcp14> be
            reported for each object size.</t>
          </section>
        </section>
        <section anchor="Test_Procedures_and_Expected_Results_TC_7_7" numbered="true" toc="include" removeInRFC="false" pn="section-7.7.4">
          <name slugifiedName="name-test-procedures-and-expected-resu">Test Procedures and Expected Results</name>
          <t indent="0" pn="section-7.7.4-1">The test procedure consists of three major steps. Step 1 ensures
          the DUT/SUT is able to reach the performance value (initial
          throughput) and meets the test results validation criteria when it
          was very minimally utilized.  Step 2 determines whether the DUT/SUT
          is able to reach the target performance value within the test
          results validation criteria.  Step 3 determines the maximum
          achievable performance value within the test results validation
          criteria.</t>
          <t indent="0" pn="section-7.7.4-2">This test procedure <bcp14>MAY</bcp14> be repeated multiple times with different
          IPv4 and IPv6 traffic distributions and HTTPS response object
          sizes.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.7.4.1">
            <name slugifiedName="name-step-1-test-initialization-and-qu">Step 1: Test Initialization and Qualification</name>
            <t indent="0" pn="section-7.7.4.1-1">Verify the link status of all connected physical interfaces.
            All interfaces are expected to be in "UP" status.</t>
            <t indent="0" pn="section-7.7.4.1-2">Configure the traffic load profile of the test equipment to
            establish "initial throughput", as defined in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_TP" format="default" sectionFormat="of" derivedContent="Section 7.7.3.2"/>.</t>
            <t indent="0" pn="section-7.7.4.1-3">The traffic load profile <bcp14>MUST</bcp14> be defined as described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>. The DUT/SUT <bcp14>MUST</bcp14> reach the
            "initial throughput" during the sustain phase. Measure all KPIs, as
            defined in <xref target="Measurement_HTTPS_TP" format="default" sectionFormat="of" derivedContent="Section 7.7.3.4"/>.</t>
            <t indent="0" pn="section-7.7.4.1-4">The measured KPIs during the sustain phase <bcp14>MUST</bcp14> meet the test
            results validation criteria "a" defined in <xref target="Validation_Criteria_HTTPS_TP" format="default" sectionFormat="of" derivedContent="Section 7.7.3.3"/>. The test results
            validation criteria "b" and "c" are <bcp14>OPTIONAL</bcp14> for Step 1.</t>
            <t indent="0" pn="section-7.7.4.1-5">If the KPI metrics do not meet the test results validation
            criteria, the test procedure <bcp14>MUST NOT</bcp14> be continued to Step
            2.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.7.4.2">
            <name slugifiedName="name-step-2-test-run-with-target-objec">Step 2: Test Run with Target Objective</name>
            <t indent="0" pn="section-7.7.4.2-1">Configure test equipment to establish the target objective
            ("Target inspected throughput") defined in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_TP" format="default" sectionFormat="of" derivedContent="Section 7.7.3.2"/>. The
            test equipment <bcp14>MUST</bcp14> start to measure and record all specified
            KPIs. Continue the test until all traffic profile phases are
            completed.</t>
            <t indent="0" pn="section-7.7.4.2-2">Within the test results validation criteria, the DUT/SUT is
            expected to reach the desired value of the target objective in the
            sustain phase. Follow Step 3 if the measured value does not meet
            the target value or does not fulfill the test results validation
            criteria.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.7.4.3">
            <name slugifiedName="name-step-3-test-iteration-6">Step 3: Test Iteration</name>
            <t indent="0" pn="section-7.7.4.3-1">Determine the achievable average inspected throughput within
            the test results validation criteria. The final test iteration
            <bcp14>MUST</bcp14> be performed for the test duration defined in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
          </section>
        </section>
      </section>
      <section anchor="HTTPS-Latency" numbered="true" toc="include" removeInRFC="false" pn="section-7.8">
        <name slugifiedName="name-https-transaction-latency">HTTPS Transaction Latency</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.8.1">
          <name slugifiedName="name-objective-8">Objective</name>
          <t indent="0" pn="section-7.8.1-1">Using HTTPS traffic, determine the HTTPS transaction latency when
          the DUT/SUT is running with sustainable HTTPS transactions per second
          supported by the DUT/SUT under different HTTPS response object
          sizes.</t>
          <t indent="0" pn="section-7.8.1-2">Scenario 1: The client <bcp14>MUST</bcp14> negotiate HTTPS and close the
          connection immediately after the completion of a single transaction
          (GET and RESPONSE).</t>
          <t indent="0" pn="section-7.8.1-3">Scenario 2: The client <bcp14>MUST</bcp14> negotiate HTTPS and close the
          connection immediately after the completion of 10 transactions (GET
          and RESPONSE) within a single TCP or QUIC connection.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.8.2">
          <name slugifiedName="name-test-setup-9">Test Setup</name>
          <t indent="0" pn="section-7.8.2-1">The testbed setup <bcp14>MUST</bcp14> be configured as defined in <xref target="Test_Setup" format="default" sectionFormat="of" derivedContent="Section 4"/>. Any specific testbed configuration changes
          (number of interfaces, interface type, etc.) <bcp14>MUST</bcp14> be
          documented.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.8.3">
          <name slugifiedName="name-test-parameters-8">Test Parameters</name>
          <t indent="0" pn="section-7.8.3-1">In this section, benchmarking-test-specific parameters are
          defined.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.8.3.1">
            <name slugifiedName="name-dut-sut-configuration-parameters-3">DUT/SUT Configuration Parameters</name>
            <t indent="0" pn="section-7.8.3.1-1">DUT/SUT parameters <bcp14>MUST</bcp14> conform to the requirements defined in
            <xref target="DUT-SUT_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Any configuration changes
            for this specific benchmarking test <bcp14>MUST</bcp14> be documented.</t>
          </section>
          <section anchor="Test_Equipment_Configuration_Parameters_HTTPS_Latency" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.8.3.2">
            <name slugifiedName="name-test-equipment-configuration-parame">Test Equipment Configuration Parameters</name>
            <t indent="0" pn="section-7.8.3.2-1">Test equipment configuration parameters <bcp14>MUST</bcp14> conform to the
            requirements defined in <xref target="Test_Equipment_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.3"/>. The following parameters
            <bcp14>MUST</bcp14> be documented for this benchmarking test:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.8.3.2-2">
              <li pn="section-7.8.3.2-2.1">Client IP address ranges defined in <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.8.3.2-2.2">Server IP address ranges defined in <xref target="Server_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.2.3"/></li>
              <li pn="section-7.8.3.2-2.3">Traffic distribution ratio between IPv4 and IPv6 defined in
	      <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.8.3.2-2.4">
                <bcp14>RECOMMENDED</bcp14> cipher suites and key sizes
	      defined in <xref target="Emulated_web_Browser_attributes" format="default" sectionFormat="of" derivedContent="Section 4.3.1.4"/></li>
              <li pn="section-7.8.3.2-2.5">Target objective for scenario 1: 50% of the connections per
	      second measured in the benchmarking test <xref target="HTTPS_CPS" format="default" sectionFormat="of" derivedContent="Section 7.6">TCP or QUIC connections per second with HTTPS
	      traffic</xref></li>
              <li pn="section-7.8.3.2-2.6">Target objective for scenario 2: 50% of the inspected
	      throughput measured in the benchmarking test <xref format="default" target="HTTPS_TP" sectionFormat="of" derivedContent="Section 7.7">HTTPS throughput</xref></li>
              <li pn="section-7.8.3.2-2.7">Initial objective for scenario 1: 10% of "Target objective
	      for scenario 1"</li>
              <li pn="section-7.8.3.2-2.8">
                <t indent="0" pn="section-7.8.3.2-2.8.1">Initial objective for scenario 2: 10% of "Target objective
	      for scenario 2"</t>
                <t indent="0" pn="section-7.8.3.2-2.8.2">Note: The initial objectives are not KPIs to
	      report. These values are configured on the traffic generator and
	      used to perform Step 1 (Test Initialization and Qualification)
	      described in <xref target="Test_Procedures_and_Expected_Results_TC_7_8" format="default" sectionFormat="of" derivedContent="Section 7.8.4"/>.</t>
              </li>
              <li pn="section-7.8.3.2-2.9">HTTPS transaction per TCP or QUIC connection: Test scenario
	      1 with a single transaction and scenario 2 with 10
	      transactions</li>
              <li pn="section-7.8.3.2-2.10">HTTPS with GET request requesting a single object: The
	      <bcp14>RECOMMENDED</bcp14> object sizes are 1, 16, and 64
	      KB. For each test iteration, the client <bcp14>MUST</bcp14>
	      request a single HTTPS response object size.</li>
            </ul>
          </section>
          <section anchor="Validation_Criteria_HTTPS_Latency" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.8.3.3">
            <name slugifiedName="name-test-results-validation-criteria-3">Test Results Validation Criteria</name>
            <t indent="0" pn="section-7.8.3.3-1">The following criteria are the test results validation
            criteria. The test results validation criteria <bcp14>MUST</bcp14> be monitored
            during the whole sustain phase of the traffic load profile.</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-7.8.3.3-2">
	      <li pn="section-7.8.3.3-2.1" derivedCounter="a.">The number of failed application transactions (receiving any
                HTTP response code other than 200 OK) <bcp14>MUST</bcp14> be less than 0.001%
                (1 out of 100,000 transactions) of the total attempted transactions.</li>
              <li pn="section-7.8.3.3-2.2" derivedCounter="b.">The number of terminated TCP connections due to unexpected TCP
                RST sent by the DUT/SUT <bcp14>MUST</bcp14> be less than 0.001% (1 out of 100,000
                connections) of the total initiated TCP connections. If HTTP/3 is
                used, the number of terminated QUIC connections due to
                unexpected errors <bcp14>MUST</bcp14> be less than 0.001% (1 out of 100,000
                connections) of the total initiated QUIC connections.</li>
              <li pn="section-7.8.3.3-2.3" derivedCounter="c.">During the sustain phase, traffic <bcp14>MUST</bcp14> be forwarded at a
                constant rate (it is considered as a constant rate if any deviation
                of the traffic forwarding rate is less than 5%).</li>
              <li pn="section-7.8.3.3-2.4" derivedCounter="d.">Concurrent TCP or QUIC connections <bcp14>MUST</bcp14> be constant during
                steady state, and any deviation of concurrent TCP connections
                <bcp14>MUST</bcp14> be less than 10%. If HTTP/3 is used, the concurrent
                generated QUIC connections <bcp14>MUST</bcp14> be constant during steady
                state, and any deviation of concurrent QUIC connections <bcp14>MUST</bcp14> be
                less than 10%. This confirms the DUT opens and closes
                connections at approximately the same rate.</li>
              <li pn="section-7.8.3.3-2.5" derivedCounter="e.">After ramp up, the DUT/SUT <bcp14>MUST</bcp14> achieve the target
                objectives defined in the parameters in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_Latency" format="default" sectionFormat="of" derivedContent="Section 7.8.3.2"/>
                and remain in that state for the entire test duration (sustain
                phase).</li>
            </ol>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.8.3.4">
            <name slugifiedName="name-measurement-8">Measurement</name>
            <t indent="0" pn="section-7.8.3.4-1">The TTFB (minimum, average, and maximum) and TTLB (minimum,
            average, and maximum) <bcp14>MUST</bcp14> be reported for each object size.</t>
          </section>
        </section>
        <section anchor="Test_Procedures_and_Expected_Results_TC_7_8" numbered="true" toc="include" removeInRFC="false" pn="section-7.8.4">
          <name slugifiedName="name-test-procedures-and-expected-resul">Test Procedures and Expected Results</name>
          <t indent="0" pn="section-7.8.4-1">The test procedure is designed to measure the TTFB or TTLB when the
          DUT/SUT is operating close to 50% of its maximum achievable
          connections per second or inspected throughput. The test procedure
          consists of two major steps. Step 1 ensures the DUT/SUT is able to
          reach the initial performance values and meets the test results
          validation criteria when it is very minimally utilized.  Step 2
          measures the latency values within the test results validation
          criteria.</t>
          <t indent="0" pn="section-7.8.4-2">This test procedure <bcp14>MAY</bcp14> be repeated multiple times with different
          IP types (IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic
          distribution), HTTPS response object sizes, and single and multiple
          transactions per connection scenarios.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.8.4.1">
            <name slugifiedName="name-step-1-test-initialization-and-qua">Step 1: Test Initialization and Qualification</name>
            <t indent="0" pn="section-7.8.4.1-1">Verify the link status of all connected physical interfaces.
            All interfaces are expected to be in "UP" status.</t>
            <t indent="0" pn="section-7.8.4.1-2">Configure the traffic load profile of the test equipment to
            establish the initial objectives, as defined in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_Latency" format="default" sectionFormat="of" derivedContent="Section 7.8.3.2"/>.
            The traffic load profile <bcp14>MUST</bcp14> be defined as described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.8.4.1-3">The DUT/SUT <bcp14>MUST</bcp14> reach the initial objectives before the
            sustain phase. The measured KPIs during the sustain phase <bcp14>MUST</bcp14>
            meet all the test results validation criteria defined in <xref target="Validation_Criteria_HTTPS_Latency" format="default" sectionFormat="of" derivedContent="Section 7.8.3.3"/>.</t>
            <t indent="0" pn="section-7.8.4.1-4">If the KPI metrics do not meet the test results validation
            criteria, the test procedure <bcp14>MUST NOT</bcp14> be continued to Step
            2.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.8.4.2">
            <name slugifiedName="name-step-2-test-run-with-target-object">Step 2: Test Run with Target Objective</name>
            <t indent="0" pn="section-7.8.4.2-1">Configure test equipment to establish the target objectives
            defined in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_Latency" format="default" sectionFormat="of" derivedContent="Section 7.8.3.2"/>.
            The test equipment <bcp14>MUST</bcp14> follow the traffic load profile definition
            described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.8.4.2-2">The test equipment <bcp14>MUST</bcp14> start to measure and record all
            specified KPIs. Continue the test until all traffic profile phases
            are completed.</t>
            <t indent="0" pn="section-7.8.4.2-3">Within the test results validation criteria, the DUT/SUT <bcp14>MUST</bcp14>
            reach the desired value of the target objective in the sustain
            phase.</t>
            <t indent="0" pn="section-7.8.4.2-4">Measure the minimum, average, and maximum values of the TTFB and
            TTLB.</t>
          </section>
        </section>
      </section>
      <section anchor="HTTPS_CC" numbered="true" toc="include" removeInRFC="false" pn="section-7.9">
        <name slugifiedName="name-concurrent-tcp-or-quic-conn">Concurrent TCP  or QUIC Connection Capacity with HTTPS Traffic</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.9.1">
          <name slugifiedName="name-objective-9">Objective</name>
          <t indent="0" pn="section-7.9.1-1">Determine the number of concurrent TCP or QUIC connections the
          DUT/SUT sustains when using HTTPS traffic.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.9.2">
          <name slugifiedName="name-test-setup-10">Test Setup</name>
          <t indent="0" pn="section-7.9.2-1">The testbed setup <bcp14>MUST</bcp14> be configured as defined in <xref target="Test_Setup" format="default" sectionFormat="of" derivedContent="Section 4"/>. Any specific testbed configuration changes
          (number of interfaces, interface type, etc.) <bcp14>MUST</bcp14> be
          documented.</t>
        </section>
        <section anchor="HTTPS_CC_parameter" numbered="true" toc="include" removeInRFC="false" pn="section-7.9.3">
          <name slugifiedName="name-test-parameters-9">Test Parameters</name>
          <t indent="0" pn="section-7.9.3-1">In this section, benchmarking-test-specific parameters are
          defined.</t>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.9.3.1">
            <name slugifiedName="name-dut-sut-configuration-parameters-4">DUT/SUT Configuration Parameters</name>
            <t indent="0" pn="section-7.9.3.1-1">DUT/SUT parameters <bcp14>MUST</bcp14> conform to the requirements defined in
            <xref target="DUT-SUT_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Any configuration changes
            for this specific benchmarking test <bcp14>MUST</bcp14> be documented.</t>
          </section>
          <section anchor="Test_Equipment_Configuration_Parameters_HTTPS_CC" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.9.3.2">
            <name slugifiedName="name-test-equipment-configuration-parame-2">Test Equipment Configuration Parameters</name>
            <t indent="0" pn="section-7.9.3.2-1">Test equipment configuration parameters <bcp14>MUST</bcp14> conform to the
            requirements defined in <xref target="Test_Equipment_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.3"/>. The following parameters
            <bcp14>MUST</bcp14> be documented for this benchmarking test:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.9.3.2-2">
              <li pn="section-7.9.3.2-2.1">Client IP address ranges defined in <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.9.3.2-2.2">Server IP address ranges defined in <xref target="Server_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.2.3"/></li>
              <li pn="section-7.9.3.2-2.3">Traffic distribution ratio between IPv4 and IPv6 defined in
                <xref target="Client_IP" format="default" sectionFormat="of" derivedContent="Section 4.3.1.3"/></li>
              <li pn="section-7.9.3.2-2.4">
                <bcp14>RECOMMENDED</bcp14> cipher suites and key sizes defined in <xref target="Emulated_web_Browser_attributes" format="default" sectionFormat="of" derivedContent="Section 4.3.1.4"/></li>
              <li pn="section-7.9.3.2-2.5">Target concurrent connections: Initial value from the product
                datasheet or the value defined based on the requirement for a
                specific deployment scenario</li>
              <li pn="section-7.9.3.2-2.6">
                <t indent="0" pn="section-7.9.3.2-2.6.1">Initial concurrent connections: 10% of "Target concurrent
                connections"</t>
                <t indent="0" pn="section-7.9.3.2-2.6.2">Note: Initial concurrent connections is not a KPI
                to report. This value is configured on the traffic generator
                and used to perform Step 1 (Test Initialization and
                Qualification) described in <xref target="Test_Procedures_and_Expected_Results_TC_7_9" format="default" sectionFormat="of" derivedContent="Section 7.9.4"/>.</t>
              </li>
              <li pn="section-7.9.3.2-2.7">Connections per second during ramp up phase: 50% of maximum
                connections per second measured in the benchmarking test <xref target="HTTPS_CPS" format="default" sectionFormat="of" derivedContent="Section 7.6">TCP or QUIC connections per second with HTTPS
                traffic</xref></li>
              <li pn="section-7.9.3.2-2.8">Ramp up time (in traffic load profile for "Target
                concurrent connections"): "Target concurrent connections" /
                "Maximum connections per second during ramp up phase"</li>
              <li pn="section-7.9.3.2-2.9">Ramp up time (in traffic load profile for "Initial
                concurrent connections"): "Initial concurrent connections" /
                "Maximum connections per second during ramp up phase"</li>
            </ul>
            <t indent="0" pn="section-7.9.3.2-3">The client <bcp14>MUST</bcp14> perform HTTPS transactions with
            persistence, and each client can open multiple concurrent
            connections per server endpoint IP.</t>
            <t indent="0" pn="section-7.9.3.2-4">Each client sends 10 GET requests requesting 1 KB HTTPS
            response objects in the same TCP or QUIC connections (10
            transactions/connections), and the delay (think time) between each
            transaction <bcp14>MUST</bcp14> be X seconds, where X is as follows.</t>
            <t indent="3" pn="section-7.9.3.2-5">X = ("Ramp up time" + "steady state time") / 10</t>
            <t indent="0" pn="section-7.9.3.2-6">The established connections <bcp14>MUST</bcp14> remain open until the ramp
            down phase of the test. During the ramp down phase, all
            connections <bcp14>MUST</bcp14> be successfully closed with FIN.</t>
          </section>
          <section anchor="HTTPS_CC_Test_Results_Validation_Criteria" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.9.3.3">
            <name slugifiedName="name-test-results-validation-criteria-4">Test Results Validation Criteria</name>
            <t indent="0" pn="section-7.9.3.3-1">The following criteria are the test results validation
            criteria. The test results validation criteria <bcp14>MUST</bcp14> be monitored
            during the whole sustain phase of the traffic load profile.</t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-7.9.3.3-2">
	      <li pn="section-7.9.3.3-2.1" derivedCounter="a.">The number of failed application transactions (receiving any
                HTTP response code other than 200 OK) <bcp14>MUST</bcp14> be less than 0.001%
                (1 out of 100,000 transactions) of the total attempted
                transactions.</li>
              <li pn="section-7.9.3.3-2.2" derivedCounter="b.">The number of terminated TCP connections due to unexpected TCP
                RSTs sent by the DUT/SUT <bcp14>MUST</bcp14> be less than 0.001% (1 out of 100,000
                connections) of the total initiated TCP connections. If HTTP/3 is
                used, the number of terminated QUIC connections due to
                unexpected errors <bcp14>MUST</bcp14> be less than 0.001% (1 out of 100,000
                connections) of the total initiated QUIC connections.</li>
              <li pn="section-7.9.3.3-2.3" derivedCounter="c.">During the sustain phase, traffic <bcp14>MUST</bcp14> be forwarded at a
                constant rate (it is considered as a constant rate if any deviation
                of the traffic forwarding rate is less than 5%).</li>
            </ol>
          </section>
          <section anchor="HTTPS_CC_Measurement" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.9.3.4">
            <name slugifiedName="name-measurement-9">Measurement</name>
            <t indent="0" pn="section-7.9.3.4-1">Average concurrent TCP or QUIC connections <bcp14>MUST</bcp14> be reported for
            this benchmarking test.</t>
          </section>
        </section>
        <section anchor="Test_Procedures_and_Expected_Results_TC_7_9" numbered="true" toc="include" removeInRFC="false" pn="section-7.9.4">
          <name slugifiedName="name-test-procedures-and-expected-result">Test Procedures and Expected Results</name>
          <t indent="0" pn="section-7.9.4-1">The test procedure is designed to measure the concurrent TCP
          connection capacity of the DUT/SUT at the sustaining period of the
          traffic load profile. The test procedure consists of three major
          steps. Step 1 ensures the DUT/SUT is able to reach the performance
          value (Initial concurrent connection) and meets the test results
          validation criteria when it was very minimally utilized.  Step 2
          determines whether the DUT/SUT is able to reach the target
          performance value within the test results validation criteria.  Step
          3 determines the maximum achievable performance value within the
          test results validation criteria.</t>
          <t indent="0" pn="section-7.9.4-2">This test procedure <bcp14>MAY</bcp14> be repeated multiple times with different
          IPv4 and IPv6 traffic distributions.</t>
          <section anchor="HTTPS_CC_Step1_Test_Initialization" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.9.4.1">
            <name slugifiedName="name-step-1-test-initialization-and-qual">Step 1: Test Initialization and Qualification</name>
            <t indent="0" pn="section-7.9.4.1-1">Verify the link status of all connected physical interfaces.
            All interfaces are expected to be in "UP" status.</t>
            <t indent="0" pn="section-7.9.4.1-2">Configure test equipment to establish "Initial concurrent
            connections" defined in <xref target="Test_Equipment_Configuration_Parameters_HTTPS_CC" format="default" sectionFormat="of" derivedContent="Section 7.9.3.2"/>.
            Except ramp up time, the traffic load profile <bcp14>MUST</bcp14> be defined as
            described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.9.4.1-3">During the sustain phase, the DUT/SUT <bcp14>MUST</bcp14> reach the "Initial
            concurrent connections". The measured KPIs during the sustain
            phase <bcp14>MUST</bcp14> meet the test results validation criteria "a" and "b"
            defined in <xref target="HTTPS_CC_Test_Results_Validation_Criteria" format="default" sectionFormat="of" derivedContent="Section 7.9.3.3"/>.</t>
            <t indent="0" pn="section-7.9.4.1-4">If the KPI metrics do not meet the test results validation
            criteria, the test procedure <bcp14>MUST NOT</bcp14> be continued to Step
            2.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.9.4.2">
            <name slugifiedName="name-step-2-test-run-with-target-objecti">Step 2: Test Run with Target Objective</name>
            <t indent="0" pn="section-7.9.4.2-1">Configure test equipment to establish the target objective
            ("Target concurrent connections"). The test equipment <bcp14>MUST</bcp14> follow
            the traffic load profile definition (except ramp up time)
            described in <xref target="Traffic_Load_Profile" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/>.</t>
            <t indent="0" pn="section-7.9.4.2-2">During the ramp up and sustain phases, the other KPIs, such as
            inspected throughput, TCP or QUIC connections per second, and
            application transactions per second, <bcp14>MUST NOT</bcp14> reach the maximum
            value that the DUT/SUT can support.</t>
            <t indent="0" pn="section-7.9.4.2-3">The test equipment <bcp14>MUST</bcp14> start to measure and record KPIs
            defined in <xref target="HTTPS_CC_Measurement" format="default" sectionFormat="of" derivedContent="Section 7.9.3.4"/>. Continue the
            test until all traffic profile phases are completed.</t>
            <t indent="0" pn="section-7.9.4.2-4">Within the test results validation criteria, the DUT/SUT is
            expected to reach the desired value of the target objective in the
            sustain phase. Follow Step 3 if the measured value does not meet
            the target value or does not fulfill the test results validation
            criteria.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-7.9.4.3">
            <name slugifiedName="name-step-3-test-iteration-7">Step 3: Test Iteration</name>
            <t indent="0" pn="section-7.9.4.3-1">Determine the achievable concurrent TCP or QUIC connections within
            the test results validation criteria.</t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">This document makes no specific request of IANA.</t>
      <t indent="0" pn="section-8-2">IANA has assigned IPv4 and IPv6 address blocks in <xref target="RFC6890" format="default" sectionFormat="of" derivedContent="RFC6890"/> that have been registered for special purposes. The
      IPv6 address block 2001:2::/48 has been allocated for the purpose of
      IPv6 benchmarking <xref target="RFC5180" format="default" sectionFormat="of" derivedContent="RFC5180"/>, and the IPv4 address block
      198.18.0.0/15 has been allocated for the purpose of IPv4 benchmarking
      <xref target="RFC2544" format="default" sectionFormat="of" derivedContent="RFC2544"/>. This assignment was made to minimize the
      chance of conflict in case a testing device were to be accidentally
      connected to the part of the Internet.</t>
    </section>
    <section anchor="Security_consieration" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">The primary goal of this document is to provide benchmarking
      terminology and methodology for next-generation network security devices
      for use in a laboratory-isolated test environment. However, readers
      should be aware that there is some overlap between performance and
      security issues. Specifically, the optimal configuration for network
      security device performance may not be the most secure, and vice versa.
      Testing security platforms with working exploits and malware carries
      risks. Ensure proper access controls are implemented to prevent
      unintended exposure to vulnerable networks or systems. The cipher suites
      recommended in this document are for test purposes only. The cipher
      suite recommendation for a real deployment is outside the scope of this
      document.</t>
      <t indent="0" pn="section-9-2">Security assessment of an NGFW/NGIPS product could also include an
      analysis whether any type of uncommon traffic characteristics would have
      a significant impact on performance. Such performance impacts would
      allow an attacker to use such specifically crafted traffic as a DoS
      attack to reduce the remaining performance available to other traffic
      through the NGFW/NGIPS. Such uncommon traffic characteristics might
      include, for example, IP-fragmented traffic, a specific type of application
      traffic, or uncommonly high HTTP transaction rate traffic.</t>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="CVE" target="https://www.cvedetails.com/" quoteTitle="true" derivedAnchor="CVE">
          <front>
            <title>Current CVSS Score Distribution For All Vulnerabilities</title>
            <author>
              <organization showOnFrontPage="true">CVE</organization>
            </author>
          </front>
        </reference>
        <reference anchor="fastly" target="https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency" quoteTitle="true" derivedAnchor="fastly">
          <front>
            <title>QUIC vs TCP: Which is Better?</title>
            <author fullname="Kazuho Oku"/>
            <author fullname="Jana Iyengar"/>
            <date month="April" year="2020"/>
          </front>
        </reference>
        <reference anchor="RFC2544" target="https://www.rfc-editor.org/info/rfc2544" quoteTitle="true" derivedAnchor="RFC2544">
          <front>
            <title>Benchmarking Methodology for Network Interconnect Devices</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <author fullname="J. McQuaid" initials="J." surname="McQuaid"/>
            <date month="March" year="1999"/>
            <abstract>
              <t indent="0">This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2544"/>
          <seriesInfo name="DOI" value="10.17487/RFC2544"/>
        </reference>
        <reference anchor="RFC2647" target="https://www.rfc-editor.org/info/rfc2647" quoteTitle="true" derivedAnchor="RFC2647">
          <front>
            <title>Benchmarking Terminology for Firewall Performance</title>
            <author fullname="D. Newman" initials="D." surname="Newman"/>
            <date month="August" year="1999"/>
            <abstract>
              <t indent="0">This document defines terms used in measuring the performance of firewalls.  It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2647"/>
          <seriesInfo name="DOI" value="10.17487/RFC2647"/>
        </reference>
        <reference anchor="RFC3511" target="https://www.rfc-editor.org/info/rfc3511" quoteTitle="true" derivedAnchor="RFC3511">
          <front>
            <title>Benchmarking Methodology for Firewall Performance</title>
            <author fullname="B. Hickman" initials="B." surname="Hickman"/>
            <author fullname="D. Newman" initials="D." surname="Newman"/>
            <author fullname="S. Tadjudin" initials="S." surname="Tadjudin"/>
            <author fullname="T. Martin" initials="T." surname="Martin"/>
            <date month="April" year="2003"/>
            <abstract>
              <t indent="0">This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls.  In addition to defining the tests, this document also describes specific formats for reporting the results of the tests.  This document is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF).  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3511"/>
          <seriesInfo name="DOI" value="10.17487/RFC3511"/>
        </reference>
        <reference anchor="RFC5180" target="https://www.rfc-editor.org/info/rfc5180" quoteTitle="true" derivedAnchor="RFC5180">
          <front>
            <title>IPv6 Benchmarking Methodology for Network Interconnect Devices</title>
            <author fullname="C. Popoviciu" initials="C." surname="Popoviciu"/>
            <author fullname="A. Hamza" initials="A." surname="Hamza"/>
            <author fullname="G. Van de Velde" initials="G." surname="Van de Velde"/>
            <author fullname="D. Dugatkin" initials="D." surname="Dugatkin"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">The benchmarking methodologies defined in RFC 2544 are IP version independent.  However, RFC 2544 does not address some of the specificities of IPv6.  This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices.  IPv6 transition mechanisms are outside the scope of this document.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5180"/>
          <seriesInfo name="DOI" value="10.17487/RFC5180"/>
        </reference>
        <reference anchor="RFC6815" target="https://www.rfc-editor.org/info/rfc6815" quoteTitle="true" derivedAnchor="RFC6815">
          <front>
            <title>Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <author fullname="K. Dubray" initials="K." surname="Dubray"/>
            <author fullname="J. McQuaid" initials="J." surname="McQuaid"/>
            <author fullname="A. Morton" initials="A." surname="Morton"/>
            <date month="November" year="2012"/>
            <abstract>
              <t indent="0">The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present.  The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity.  Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods.  This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6815"/>
          <seriesInfo name="DOI" value="10.17487/RFC6815"/>
        </reference>
        <reference anchor="RFC6890" target="https://www.rfc-editor.org/info/rfc6890" quoteTitle="true" derivedAnchor="RFC6890">
          <front>
            <title>Special-Purpose IP Address Registries</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="L. Vegoda" initials="L." surname="Vegoda"/>
            <author fullname="R. Bonica" initials="R." role="editor" surname="Bonica"/>
            <author fullname="B. Haberman" initials="B." surname="Haberman"/>
            <date month="April" year="2013"/>
            <abstract>
              <t indent="0">This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA.  It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries.  Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="153"/>
          <seriesInfo name="RFC" value="6890"/>
          <seriesInfo name="DOI" value="10.17487/RFC6890"/>
        </reference>
        <reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8200" quoteTitle="true" derivedAnchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6).  It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9000" quoteTitle="true" derivedAnchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration.  QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC9001" target="https://www.rfc-editor.org/info/rfc9001" quoteTitle="true" derivedAnchor="RFC9001">
          <front>
            <title>Using TLS to Secure QUIC</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="S. Turner" initials="S." role="editor" surname="Turner"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document describes how Transport Layer Security (TLS) is used to secure QUIC.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9001"/>
          <seriesInfo name="DOI" value="10.17487/RFC9001"/>
        </reference>
        <reference anchor="RFC9002" target="https://www.rfc-editor.org/info/rfc9002" quoteTitle="true" derivedAnchor="RFC9002">
          <front>
            <title>QUIC Loss Detection and Congestion Control</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="I. Swett" initials="I." role="editor" surname="Swett"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document describes loss detection and congestion control mechanisms for QUIC.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9002"/>
          <seriesInfo name="DOI" value="10.17487/RFC9002"/>
        </reference>
        <reference anchor="RFC9113" target="https://www.rfc-editor.org/info/rfc9113" quoteTitle="true" derivedAnchor="RFC9113">
          <front>
            <title>HTTP/2</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t>
              <t indent="0">This document obsoletes RFCs 7540 and 8740.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9113"/>
          <seriesInfo name="DOI" value="10.17487/RFC9113"/>
        </reference>
        <reference anchor="RFC9114" target="https://www.rfc-editor.org/info/rfc9114" quoteTitle="true" derivedAnchor="RFC9114">
          <front>
            <title>HTTP/3</title>
            <author fullname="M. Bishop" initials="M." role="editor" surname="Bishop"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9114"/>
          <seriesInfo name="DOI" value="10.17487/RFC9114"/>
        </reference>
        <reference anchor="RFC9204" target="https://www.rfc-editor.org/info/rfc9204" quoteTitle="true" derivedAnchor="RFC9204">
          <front>
            <title>QPACK: Field Compression for HTTP/3</title>
            <author fullname="C. Krasic" initials="C." surname="Krasic"/>
            <author fullname="M. Bishop" initials="M." surname="Bishop"/>
            <author fullname="A. Frindell" initials="A." role="editor" surname="Frindell"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3.  This is a variation of HPACK compression that seeks to reduce head-of-line blocking.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9204"/>
          <seriesInfo name="DOI" value="10.17487/RFC9204"/>
        </reference>
        <reference anchor="RFC9293" target="https://www.rfc-editor.org/info/rfc9293" quoteTitle="true" derivedAnchor="RFC9293">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document specifies the Transmission Control Protocol (TCP).  TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet.  Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion.  This document collects and brings those changes together with the protocol specification from RFC 793.  This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793.  It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements.  It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state.  The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
        <reference anchor="Undertow" target="https://undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html" quoteTitle="true" derivedAnchor="Undertow">
          <front>
            <title>An in depth overview of HTTP/2</title>
            <author>
              <organization showOnFrontPage="true">undertow</organization>
            </author>
          </front>
        </reference>
        <reference anchor="Wiki-NGFW" target="https://en.wikipedia.org/w/index.php?title=Next-generation_firewall&amp;oldid=1133673904" quoteTitle="true" derivedAnchor="Wiki-NGFW">
          <front>
            <title>Next-generation firewall</title>
            <author>
              <organization showOnFrontPage="true">Wikipedia</organization>
            </author>
            <date month="January" year="2023"/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="Test-Methodology-Security-Effectiveness-Evaluation" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-test-methodology-security-e">Test Methodology - Security Effectiveness Evaluation</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.1">
        <name slugifiedName="name-test-objective">Test Objective</name>
        <t indent="0" pn="section-appendix.a.1-1">This test methodology verifies the DUT/SUT is able to detect,
        prevent, and report the vulnerabilities.</t>
        <t indent="0" pn="section-appendix.a.1-2">In this test, background test traffic will be generated to utilize
        the DUT/SUT. In parallel, some malicious traffic will be sent
        to the DUT/SUT as encrypted and cleartext payload formats
        using a traffic generator. <xref target="security_effectiveness" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>
        defines the selection of the malicious traffic from the Common
        Vulnerabilities and Exposures (CVEs) list for testing.</t>
        <t indent="0" pn="section-appendix.a.1-3">The following KPIs are measured in this test:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-4">
          <li pn="section-appendix.a.1-4.1">Number of blocked CVEs</li>
          <li pn="section-appendix.a.1-4.2">Number of bypassed (non-blocked) CVEs</li>
          <li pn="section-appendix.a.1-4.3">Background traffic performance (verify if the background
            traffic is impacted while sending CVEs toward the DUT/SUT)</li>
          <li pn="section-appendix.a.1-4.4">Accuracy of DUT/SUT statistics in terms of vulnerabilities
            reporting</li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.2">
        <name slugifiedName="name-testbed-setup">Testbed Setup</name>
        <t indent="0" pn="section-appendix.a.2-1">The same testbed <bcp14>MUST</bcp14> be used for security effectiveness tests and
        for benchmarking test cases defined in <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.3">
        <name slugifiedName="name-test-parameters-10">Test Parameters</name>
        <t indent="0" pn="section-appendix.a.3-1">In this section, the benchmarking-test-specific parameters are
        defined.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.3.1">
          <name slugifiedName="name-dut-sut-configuration-parameters-5">DUT/SUT Configuration Parameters</name>
          <t indent="0" pn="section-appendix.a.3.1-1">DUT/SUT configuration parameters <bcp14>MUST</bcp14> conform to the requirements
          defined in <xref target="DUT-SUT_Configuration" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. The same DUT
          configuration <bcp14>MUST</bcp14> be used for the security effectiveness test and
          for benchmarking test cases defined in <xref target="Benchmarking" format="default" sectionFormat="of" derivedContent="Section 7"/>. The DUT/SUT <bcp14>MUST</bcp14> be configured in "Inline"
          mode, all detected attack traffic <bcp14>MUST</bcp14> be dropped, and the session
          <bcp14>MUST</bcp14> be reset</t>
        </section>
        <section anchor="Test_Equipment_Configuration_Parameters_CVE" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.3.2">
          <name slugifiedName="name-test-equipment-configuration-parame-3">Test Equipment Configuration Parameters</name>
          <t indent="0" pn="section-appendix.a.3.2-1">Test equipment configuration parameters <bcp14>MUST</bcp14> conform to the
          requirements defined in <xref format="default" target="Test_Equipment_Configuration" sectionFormat="of" derivedContent="Section 4.3"/>. The same client and server
          IP ranges <bcp14>MUST</bcp14> be configured as used in the benchmarking test cases.
          In addition, the following parameters <bcp14>MUST</bcp14> be documented for this
          benchmarking test:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3.2-2">
            <li pn="section-appendix.a.3.2-2.1">Background Traffic: 45% of maximum HTTP throughput and 45% of
              maximum HTTPS throughput supported by the DUT/SUT (measured with
              object size 64 KB in the benchmarking tests HTTP(S)
              Throughput defined in Sections <xref target="HTTP_TP" format="counter" sectionFormat="of" derivedContent="7.3"/>
              and <xref target="HTTPS_TP" format="counter" sectionFormat="of" derivedContent="7.7"/>)</li>
            <li pn="section-appendix.a.3.2-2.2">
              <bcp14>RECOMMENDED</bcp14> CVE traffic transmission Rate: 10 CVEs per
              second</li>
            <li pn="section-appendix.a.3.2-2.3">It is <bcp14>RECOMMENDED</bcp14> to generate each CVE multiple times
              (sequentially) at 10 CVEs per second.</li>
            <li pn="section-appendix.a.3.2-2.4">Ciphers and keys for the encrypted CVE traffic <bcp14>MUST</bcp14> use the
              same cipher configured for HTTPS-traffic-related benchmarking
              tests (Sections <xref target="HTTPS_CPS" format="counter" sectionFormat="of" derivedContent="7.6"/>-<xref target="HTTPS_CC" format="counter" sectionFormat="of" derivedContent="7.9"/>)</li>
          </ul>
        </section>
      </section>
      <section anchor="CVE_Criteria" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.4">
        <name slugifiedName="name-test-results-validation-criteria-5">Test Results Validation Criteria</name>
        <t indent="0" pn="section-appendix.a.4-1">The following criteria are the test results validation criteria.
        The test results validation criteria <bcp14>MUST</bcp14> be monitored during the
        whole test duration.</t>
        <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-appendix.a.4-2">
	  <li pn="section-appendix.a.4-2.1" derivedCounter="a.">The number of failed application transactions in the background
            traffic <bcp14>MUST</bcp14> be less than 0.01% of the attempted transactions.</li>
          <li pn="section-appendix.a.4-2.2" derivedCounter="b.">The number of terminated TCP or QUIC connections of the background
            traffic (due to unexpected errors) <bcp14>MUST</bcp14> be less than 0.01% of the
            total initiated TCP connections in the background traffic.</li>
          <li pn="section-appendix.a.4-2.3" derivedCounter="c.">During the sustain phase, traffic <bcp14>MUST</bcp14> be forwarded at a
            constant rate (it is considered as a constant rate if any deviation of the
            traffic forwarding rate is less than 5%).</li>
          <li pn="section-appendix.a.4-2.4" derivedCounter="d.">A false positive <bcp14>MUST NOT</bcp14> occur in the background traffic.</li>
        </ol>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.5">
        <name slugifiedName="name-measurement-10">Measurement</name>
        <t indent="0" pn="section-appendix.a.5-1">The following KPI metrics <bcp14>MUST</bcp14> be reported for this test
        scenario:</t>
        <t indent="0" pn="section-appendix.a.5-2">Mandatory KPIs:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.5-3">
          <li pn="section-appendix.a.5-3.1">
            <t indent="0" pn="section-appendix.a.5-3.1.1">Blocked CVEs: They <bcp14>MUST</bcp14> be represented in the
            following ways:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.5-3.1.2">
              <li pn="section-appendix.a.5-3.1.2.1">Number of blocked CVEs out of total CVEs</li>
              <li pn="section-appendix.a.5-3.1.2.2">Percentage of blocked CVEs</li>
            </ul>
          </li>
          <li pn="section-appendix.a.5-3.2">
            <t indent="0" pn="section-appendix.a.5-3.2.1">Unblocked CVEs: They <bcp14>MUST</bcp14> be represented in the
            following ways:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.5-3.2.2">
              <li pn="section-appendix.a.5-3.2.2.1">Number of unblocked CVEs out of total CVEs</li>
              <li pn="section-appendix.a.5-3.2.2.2">Percentage of unblocked CVEs</li>
            </ul>
          </li>
          <li pn="section-appendix.a.5-3.3">
            <t indent="0" pn="section-appendix.a.5-3.3.1">Background traffic behavior: It <bcp14>MUST</bcp14> be
            represented in one of the followings ways:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.5-3.3.2">
              <li pn="section-appendix.a.5-3.3.2.1">No impact: Considered as "no impact" if any deviation of the
              traffic forwarding rate is less than or equal to 5% (constant
              rate)</li>
              <li pn="section-appendix.a.5-3.3.2.2">Minor impact: Considered as "minor impact" if any deviation
              of the traffic forwarding rate is greater than 5% and less than or
              equal to 10% (i.e., small spikes)</li>
              <li pn="section-appendix.a.5-3.3.2.3">Heavy impact: Considered as "heavy impact" if any
              deviation of the traffic forwarding rate is greater than 10% (i.e.,
              large spikes) or reduced the background HTTP(S) throughput
              greater than 10%</li>
            </ul>
          </li>
          <li pn="section-appendix.a.5-3.4">DUT/SUT reporting accuracy: The DUT/SUT <bcp14>MUST</bcp14> report
          all detected vulnerabilities.</li>
        </ul>
        <t indent="0" pn="section-appendix.a.5-4">Optional KPIs:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.5-5">
          <li pn="section-appendix.a.5-5.1">List of unblocked CVEs</li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.6">
        <name slugifiedName="name-test-procedures-and-expected-result-2">Test Procedures and Expected Results</name>
        <t indent="0" pn="section-appendix.a.6-1">The test procedure is designed to measure the security
        effectiveness of the DUT/SUT at the sustaining period of the traffic
        load profile. The test procedure consists of two major steps. This
        test procedure <bcp14>MAY</bcp14> be repeated multiple times with different IPv4 and
        IPv6 traffic distributions.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.6.1">
          <name slugifiedName="name-step-1-background-traffic">Step 1: Background Traffic</name>
          <t indent="0" pn="section-appendix.a.6.1-1">Generate background traffic at the transmission rate defined in
          <xref format="default" target="Test_Equipment_Configuration_Parameters_CVE" sectionFormat="of" derivedContent="Appendix A.3.2"/>.</t>
          <t indent="0" pn="section-appendix.a.6.1-2">The DUT/SUT <bcp14>MUST</bcp14> reach the target objective (HTTP(S) throughput)
          in the sustain phase. The measured KPIs during the sustain phase <bcp14>MUST</bcp14>
          meet all the test results validation criteria defined in <xref target="CVE_Criteria" format="default" sectionFormat="of" derivedContent="Appendix A.4"/>.</t>
          <t indent="0" pn="section-appendix.a.6.1-3">If the KPI metrics do not meet the test results validation criteria, the test
          procedure <bcp14>MUST NOT</bcp14> be continued to Step 2.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.6.2">
          <name slugifiedName="name-step-2-cve-emulation">Step 2: CVE Emulation</name>
          <t indent="0" pn="section-appendix.a.6.2-1">While generating background traffic (in the sustain phase), send the
          CVE traffic, as defined in the parameter section (<xref target="Test_Equipment_Configuration_Parameters_CVE" format="default" sectionFormat="of" derivedContent="Appendix A.3.2"/>).</t>
          <t indent="0" pn="section-appendix.a.6.2-2">The test equipment <bcp14>MUST</bcp14> start to measure and record all specified
          KPIs. Continue the test until all CVEs are sent.</t>
          <t indent="0" pn="section-appendix.a.6.2-3">The measured KPIs <bcp14>MUST</bcp14> meet all the test results validation
          criteria defined in <xref target="CVE_Criteria" format="default" sectionFormat="of" derivedContent="Appendix A.4"/>.</t>
          <t indent="0" pn="section-appendix.a.6.2-4">In addition, the DUT/SUT should report the detected 
   vulnerabilities in the log correctly, or there <bcp14>MUST</bcp14> be reference 
   material available that will allow for verification that the correct 
   vulnerability was detected if, for example, a different naming 
   convention is used. This reference material <bcp14>MUST</bcp14> be cited in
          the report.</t>
        </section>
      </section>
    </section>
    <section anchor="DUT-Classification" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-dut-sut-classification">DUT/SUT Classification</name>
      <t indent="0" pn="section-appendix.b-1">This document aims to classify the DUT/SUT into four different
      categories based on its maximum-supported firewall throughput
      performance number defined in the vendor datasheet. This classification
      <bcp14>MAY</bcp14> help users to determine specific configuration scales (e.g., number
      of ACL entries), traffic profiles, and attack traffic profiles, scaling
      those proportionally to the DUT/SUT sizing category.</t>
      <t indent="0" pn="section-appendix.b-2">The four different categories are Extra Small (XS), Small (S), Medium
      (M), and Large (L). The <bcp14>RECOMMENDED</bcp14> throughput values for the following
      categories are:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-appendix.b-3">
        <dt pn="section-appendix.b-3.1">Extra Small (XS) -</dt>
        <dd pn="section-appendix.b-3.2">Supported throughput less than or equal to 1 Gbit/s</dd>
        <dt pn="section-appendix.b-3.3">Small (S) -</dt>
        <dd pn="section-appendix.b-3.4">Supported throughput greater than 1 Gbit/s and less than or equal
	to 5Gbit/s</dd>
        <dt pn="section-appendix.b-3.5">Medium (M) -</dt>
        <dd pn="section-appendix.b-3.6">Supported throughput greater than 5 Gbit/s and less than or equal
	to 10Gbit/s</dd>
        <dt pn="section-appendix.b-3.7">Large (L) -</dt>
        <dd pn="section-appendix.b-3.8">Supported throughput greater than 10 Gbit/s</dd>
      </dl>
    </section>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.c-1">The authors wish to acknowledge the members of NetSecOPEN for their
      participation in the creation of this document. Additionally, the
      following members need to be acknowledged:</t>
      <t indent="0" pn="section-appendix.c-2"><contact fullname="Anand Vijayan"/>, <contact fullname="Chris       Marshall"/>, <contact fullname="Jay Lindenauer"/>, <contact fullname="Michael Shannon"/>, <contact fullname="Mike Deichman"/>,
      <contact fullname="Ryan Riese"/>, and <contact fullname="Toulnay       Orkun"/>.</t>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.d">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.d-1">The following individuals contributed significantly to the creation
      of this document:</t>
      <t indent="0" pn="section-appendix.d-2"><contact fullname="Alex Samonte"/>, <contact fullname="Amritam       Putatunda"/>, <contact fullname="Aria Eslambolchizadeh"/>, <contact fullname="Chao Guo"/>, <contact fullname="Chris Brown"/>, <contact fullname="Cory Ford"/>, <contact fullname="David DeSanto"/>, <contact fullname="Jurrie Van Den Breekel"/>, <contact fullname="Michelle       Rhines"/>, <contact fullname="Mike Jack"/>, <contact fullname="Ryan       Liles"/>, <contact fullname="Samaresh Nair"/>, <contact fullname="Stephen Goudreault"/>, <contact fullname="Tim Carlin"/>, and
      <contact fullname="Tim Otto"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.e">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Balamuhunthan Balarajah" initials="B" surname="Balarajah">
        <organization showOnFrontPage="true"/>
        <address>
          <postal>
            <street/>
            <city>Berlin</city>
            <code/>
            <region/>
            <country>Germany</country>
          </postal>
          <phone/>
          <email>bm.balarajah@gmail.com</email>
        </address>
      </author>
      <author fullname="Carsten Rossenhoevel" initials="C" surname="Rossenhoevel">
        <organization showOnFrontPage="true">EANTC AG</organization>
        <address>
          <postal>
            <street>Salzufer 14</street>
            <city>Berlin</city>
            <code>10587</code>
            <region/>
            <country>Germany</country>
          </postal>
          <phone/>
          <email>cross@eantc.de</email>
        </address>
      </author>
      <author fullname="Brian Monkman" initials="B" surname="Monkman">
        <organization showOnFrontPage="true">NetSecOPEN</organization>
        <address>
          <postal>
            <street>417 Independence Court</street>
            <city>Mechanicsburg</city>
            <code>17050</code>
            <region>PA</region>
            <country>United States of America</country>
          </postal>
          <phone/>
          <email>bmonkman@netsecopen.org</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
