<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	  <!ENTITY RFC4382 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4382.xml">
	  <!ENTITY I-D.li-reg-purge SYSTEM
		   "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.li-reg-purge.xml"> 
	  ]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" ipr="trust200811" docName="draft-huang-bmwg-virtual-network-performance-03">

 <front>

  <!-- The abbreviated title is used in the page header- it is only
       necessary if the full title is longer than 39 characters -->
  <title abbrev="virtual-network-performance-benchmark-03">
  Benchmarking Methodology for Virtualization Network Performance
  </title>

  <author initials="L" role="editor" surname="Huang" fullname="Lu Huang">
    <organization>China Mobile</organization>
    <address>
      <postal>
        <street>32 Xuanwumen West Ave, Xicheng District</street>
        <city>Beijing</city>
        <code>100053</code>
        <country>China</country>
      </postal>
      <email>hlisname@yahoo.com</email>
    </address>
  </author>

  <author initials="R" role="editor" surname="Gu" fullname="Rong Gu">
    <organization >China Mobile</organization>
    <address>
      <postal>
        <street>32 Xuanwumen West Ave, Xicheng District</street>
        <city>Beijing</city>
        <code> 100053</code>
        <country>China</country>
      </postal>
      <email>gurong@chinamobile.com</email>
    </address>
  </author>

  <author initials="Bob" surname="Mandeville" fullname="Bob Mandeville">
    <organization>Iometrix</organization>
    <address>
      <postal>
        <street>3600 Fillmore Street Suite 409</street>
        <city>San Francisco, CA</city>
        <code>94123</code>
        <country>USA</country>
      </postal>
      <email>bob@iometrix.com</email>
    </address>
  </author>

  <author initials="Brooks" surname="Hickman" fullname="Brooks Hickman">
    <organization>Spirent Communications</organization>
    <address>
      <postal>
        <street>1325 Borregas Ave</street>
        <city>Sunnyvale, CA</city>
        <code>94089</code>
        <country>USA</country>
      </postal>
      <email>Brooks.Hickman@spirent.com</email>
    </address>
  </author>
  <date month="July" year="2017"></date>
  <!-- If the month and year are both specified and are the current ones,
       xml2rfc will fill in the current day for you. If only the current
       year is specified, xml2rfc will fill in the current day and month
       for you. If the year is not the current one, it is necessary to
       specify at least a month (xml2rfc assumes day="1" if not specified
       for the purpose of calculating the expiry date).  With drafts it is
       normally sufficient to specify just the year. -->

  <!-- Meta-data Declarations -->

  <area>Operations and Management Area</area>
  <workgroup>BMWG</workgroup>

  <abstract>

    <t>
<!-- TODO: needs to be extended -->
As the virtual network has been widely established in IDC, the performance 
of virtual network has become a valuable consideration to the IDC managers. 
This draft introduces a benchmarking methodology for virtualization network 
performance based on virtual switch.
    </t>

  </abstract>

 </front>

 <middle>

  <!-- BEGIN 1. Introduction -->
  <section title="Introduction">

    <t>
As the virtual network has been widely established in IDC, the performance 
of virtual network has become a valuable consideration to the IDC managers. 
This draft introduces a benchmarking methodology for virtualization network 
performance based on virtual switch as the DUT.
    </t>

  </section>
  <!-- END 1. Introduction -->

<!-- BEGIN 2. Terminology -->
  <section title="Terminology">

    <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
in this document are to be interpreted as described 
in <xref target="RFC2119" />.
    </t>
   </section>
  <!-- END 2. Terminology -->  

  <!-- BEGIN 3. Test Considerations-->
  <section title="Test Considerations">

    <t>
In a conventional test setup with Non-Virtual test ports, it is quite legitimate 
to assume that test ports provide the golden standard in measuring the performance 
metrics. If test results are sub optimal, it is automatically assumed that the 
Device-Under-Test (DUT) is at fault. For example, when testing throughput at a given 
frame size, if the test result shows less than 100% throughput, we can safely conclude 
that it's the DUT that can not deliver line rate forwarding at that frame size(s). We 
never doubt that the tester can be an issue.
    </t>

    <t>
While in a virtual test environment where both the DUT as well as the test tool itself 
are software based, it's quite a different story. Just like the DUT, tester running as software 
will have its own performance peak under various conditions. 
    </t>
    
    <t>
There are two types of vSwitch according to different installation location. One is VM based vSwitch
which is installed on a virtual machine, another is vSwitch directly installed on the host OS (similar
to hypervisor).The latter is much more popular currently.
    </t>

    <t>
Tester's calibration is essential in benchmarking testing in a virtual environment. 
Furthermore, to reduce the enormous combination of various conditions, tester must be 
calibrated with the exact same combination and parameter settings the user wants to measure 
against the DUT. A slight variation of conditions and parameter values will cause inaccurate 
measurements of the DUT.
    </t>
    
    <t>
While it is difficult to list the exact combination and parameter settings, the following 
table attempts to give the most common example how to calibrate a tester before testing a DUT (VSWITCH).
    </t>
     <t>
Sample calibration permutation:
     </t> 
 
<figure anchor="table-sample_calibration_permutation" align="center" title="Sample Calibration Permutation">
<artwork>
----------------------------------------------------------------
| Hypervisor | VM VNIC |   VM Memory   |   Frame  |            |
|    Type    |  Speed  |CPU Allocation |   Size   |  Throughput|
----------------------------------------------------------------
|   ESXi       1G/10G     512M/1Core   |    64    |            |
|                                      |   128    |            |
|                                      |   256    |            |
|                                      |   512    |            |
|                                      |  1024    |            |
|                                      |  1518    |            |
----------------------------------------------------------------    
</artwork>
</figure>
  
 <t>
 Key points are as following:
</t>
<t>
a)	The hypervisor type is of ultimate importance to the test results. VM tester(s) MUST be installed 
on the same hypervisor type as the  DUT (VSWITCH). Different hypervisor type has an influence on the 
test result.
</t>
    <t>
b)	The VNIC speed will have an impact on testing results. Testers MUST calibrate against all VNIC speeds.
    </t>
    <t>    
c)	VM allocations of CPU resources and memory have an influence on test results.
    </t>
    <t>      
d)	Frame sizes will affect the test results dramatically due to the nature of virtual machines.
    </t>
    <t>          
e)	Other possible extensions of above table: The number of VMs to be created, latency reading, one VNIC per VM 
vs. multiple VM sharing one VNIC, and uni-directional traffic vs. bi-directional traffic.
    </t>
<t>
	Besides, the compute environment including the hardware should be also recorded.
	</t>
	 
<figure anchor="table-compute_environment_hardware" align="center" title="Compute Environment">
<artwork>
          -----------------------------------------------------
          | Compute encironment componenets |        Model    |
          -----------------------------------------------------
          |              CPU                |                 |
          ----------------------------------------------------- 
          |             Memory              |                 |     
          -----------------------------------------------------
          |            Hard Disk            |                 |
          -----------------------------------------------------
          |           10G Adaptors          |                 |
          -----------------------------------------------------
          |         Blade/Motherboard       |                 |
          -----------------------------------------------------          
</artwork>
</figure>
    <t>
It's important to confirm test environment for tester's calibration as close to the environment a virtual 
DUT (VSWITCH) involved in for the benchmark test. Key points which SHOULD be noticed in test setup are listed 
as follows.  
    </t>
    <t>
1. One or more VM tester(s) need to be created for both traffic generation and analysis.
    </t>   	
    <t>   	
2. vSwitch has an influence on performance penalty due to extra resource occupation.
    </t> 
    <t> 
3. VNIC and its type is needed in the test setup to once again accommodate performance penalty when DUT (VSWITCH) 
 is created. 	    	
    </t>    
     <t>    
In summary, calibration should be done in such an environment that all possible factors which may negatively 
impact test results should be taken into consideration.
    </t>  	    
  </section>
  
  <!-- END 3. Test Considerations-->


  <!-- BEGIN 4. Key Performance Indicators -->
  <section title="Key Performance Indicators">

    <t>
We listed numbers of key performance indicators for virtual network below:
    </t>
    
    <t>
a) Throughput under various frame sizes: forwarding performance under various frame sizes is a key performance 
indicator of interest.
    </t>
    
    <t>
b) DUT consumption of CPU: when adding one or more VM(s), DUT (VSWITCH) will consume more CPU. Vendors can allocate 
appropriate CPU to reach the line rate performance.
    </t>
    
    <t>
c) DUT consumption of MEM: when adding one or more VM(s), DUT (VSWITCH) will consume more memory. Vendors can allocate 
appropriate MEM to reach the line rate performance.
    </t>
    
    <t>
d) Latency readings: Some applications are highly sensitive on latency. It's important to get the latency reading with 
respective to various conditions.
    </t>
    
    <t>
Other indicators such as VxLAN maximum supported by the virtual switch and so on can be added in the scene when VxLAN 
is needed.   	
    </t>

  </section>
  <!-- END 4. Key Performance Indicators -->


  <!-- BEGIN 5. Test Setup -->
  <section title="Test Setup">

    <t>
The test setup is classified into two traffic models: Model A and Model B.
    </t>
    <t>
In traffic model A: A physical tester connects to the server which bears the DUT (VSWITCH) and Virtual tester to verify 
the benchmark of server.
    </t>
<figure anchor="table-test_model_A" align="center" title="test model A">
          <artwork>
                        ________________________________________
                       |                                        |
-----------------      |   ----------------    ---------------- |
|Physical tester|------|---|DUT (VSWITCH) |----|Virtual tester| |
-----------------      |   ----------------    ---------------- |
                       |  Server                                |
                       |________________________________________|
       </artwork>
        </figure>
     <t>
In traffic model B: Two virtual testers are used to verify the benchmark. In this model, two testers are installed 
in one server.
    </t>     
 <figure anchor="table-test_model_B" align="center" title="test model B">
<artwork>
 ______________________________________________________________  
|                                                              |
|   ----------------    ----------------     ----------------  |
|   |Virtual tester|----|DUT (VSWITCH) |-----|Virtual tester|  |
|   ----------------    ----------------     ----------------  |
|  Server                                                      |
|______________________________________________________________|
</artwork>
        </figure> 
    <t>
In our test, the test bed is constituted by physical servers of the Dell with a pair of 10GE NIC and physical tester. 
Virtual tester which occupies 2 vCPU and 8G MEM and DUT (VSWITCH) are installed in the server. 10GE switch and 1GE 
switch are used for test traffic and management respectively.
    </t>
    <t>    
This test setup is also available in the VxLAN measurement.
    </t>
  </section>
  <!-- End 5. Test Setup -->
    <!-- BEGIN 6. Benchmarking Tests -->
    <section title="Benchmarking Tests">
    <!-- BEGIN 6.1 Throughput -->   
    <section title="Throughput">
      <t>
Unlike traditional test cases where the DUT and the tester are separated, virtual network test has been brought in 
unparalleled challenges. In virtual network test, the virtual tester and the DUT  (VSWITCH) are in one server which 
means they are physically converged, so the test and DUT (VSWITCH) are sharing the same CPU and MEM resources of one 
server. Theoretically, the virtual tester's operation may have influence on the DUT (VSWITCH)'s performance. However, 
for the specialty of virtualization, this method is the only way to test the performance of a virtual DUT.
    </t>
     <t>
Under the background of existing technology, when we test the virtual switch's throughput, the concept of traditional 
physical switch CANNOT be applicable. The traditional throughput indicates the switches' largest forwarding capability, 
for certain bytes selected and under zero-packet-lose conditions. But in virtual environments, virtual variations on 
virtual network will be much greater than that of dedicated physical devices. As the DUT and the tester cannot be separated, 
it proves that the DUT (VSWITCH) realize such network performances under certain circumstances.
    </t>
     <t>
 Therefore, we change the bytes in virtual environment to test the maximum value which we think of the indicator of 
 throughput. It's conceivable that the throughput should be tested on both the test model A and B. The tested throughput has 
 certain referential meanings to value the performance of the virtual DUT.
    </t>
    <!-- BEGIN 6.1.1 Objectives -->  
    <section title="Objectives">    
     <t>The objective of the test is to determine the throughput of the DUT (VSWITCH), which the DUT can support.
     </t>  
    </section>      	    
    <!-- END 6.1.1 Objectives -->      
    
     <!-- BEGIN 6.1.2 Configuration parameters -->  
    <section title="Configuration parameters">    
     <t>
     Network parameters should be defined as follows:
     </t>  
     <t>
a) the number of virtual tester (VMs)
     </t>  
     <t>
b)	the number of vNIC of virtual tester
     </t>  
     <t>
c)	the CPU type of the server
    </t>  
     <t>
d)	vCPU allocated for virtual tester (VMs)
    </t>  
     <t>
e)	memory allocated for virtual tester (VMs)
    </t>  
     <t>
f)	the number and rate of server NIC
     </t>  
    </section>      	    
     <!-- END 6.1.2 Configuration parameters --> 
     <!-- BEGIN 6.1.3 Test parameters -->  
    <section anchor="sec:Test_parameters" title="Test parameters">    
     
     <t>
a)	test repeated times
     </t>  
     <t>
b)	test frame length
     </t>    
    </section>      	    
     <!-- END 6.1.3 Test parameters -->        
 
     <!-- BEGIN 6.1.4 Test process -->  
    <section anchor="sec:Test_process" title="Test process">    
     
     <t>
1.	Configure the VM tester to offer traffic to the V-Switch.
     </t>  
     <t>
2.	Increase the traffic rate of tester until packet loss happens.
     </t>  
     <t>
3.	Record the max traffic rate without packet loss on VSwitch.
     </t>       
     <t>
4.	Change the frame length and repeat from step1 to step4.
     </t>         
    </section>      	    
     <!-- END 6.1.4 Test process -->   
 
      <!-- BEGIN 6.1.5 Test result format -->  
    <section anchor="sec:Test_result_format" title="Test result format">    
<figure anchor="table-sample_test_result_format" align="center"
                title="test result format">
          <artwork>
                        --------------------------
                        | Byte| Throughput (Gbps)|
                        --------------------------
                        |  64 |                  |
                        --------------------------
                        | 128 |                  |
                        --------------------------
                        | 256 |                  |
                        --------------------------
                        | 512 |                  |
                        --------------------------
                        | 1024|                  |
                        --------------------------
                        | 1518|                  |
                        --------------------------
  
       </artwork>
        </figure>     
       
    </section>      	    
     <!-- END 6.1.5 Test result format -->     
      </section>  
    <!-- END 6.1 Throughput -->    
    
    <!-- BEGIN 6.2 Frame loss rate -->   
    <section title="Frame loss rate">
      <t>
Frame loss rate is also an important indicator in evaluating the performance of virtual switch.As is defined in RFC 1242,
percentage of frames that should have been forwarded which actually fails to be forwarded due to lack of resources needs
to be tested.Both model A and model B are tested.Frame loss rate is an important indicator in evaluating the performance of 
virtual switches.
    </t>
    <!-- BEGIN 6.2.1 Objectives -->  
    <section title="Objectives">    
     <t>The objective of the test is to determine the frame loss rate under different data rates and frame sizes..
     </t>  
    </section>      	    
    <!-- END 6.2.1 Objectives -->      
    
     <!-- BEGIN 6.2.2 Configuration parameters -->  
    <section title="Configuration parameters">    
     <t>
     Network parameters should be defined as follows:
     </t>  
     <t>
a) the number of virtual tester (VMs)
     </t>  
     <t>
b)	the number of vNIC of virtual tester
     </t>  
     <t>
c)	the CPU type of the server
    </t>  
     <t>
d)	vCPU allocated for virtual tester (VMs)
    </t>  
     <t>
e)	memory allocated for virtual tester (VMs)
    </t>  
     <t>
f)	the number and rate of server NIC
     </t>  
    </section>      	    
     <!-- END 6.2.2 Configuration parameters --> 
     <!-- BEGIN 6.2.3 Test parameters -->  
    <section title="Test parameters"> 
      <t>
a)	test repeated times
     </t>  
     <t>
b)	test frame length
     </t>  
     <t>
c)  test frame rate   
	   </t>
    </section>      	    
     <!-- END 6.2.3 Test parameters -->        
 
     <!-- BEGIN 6.2.4 Test process -->  
    <section title="Test process">    
     
     <t>
1.	Configure the VM tester to offer traffic to the V-Switch with the input frame 
changing from the maximum rate to the rate with no frame loss at reducing 10% intervals according
to RFC 2544. 
     </t>  
     <t>
2.	Record the input frame count and output count on VSwitch.
     </t> 
     <t>
3.  Calculate the frame loss percentage under different frame rate.
     	</t>      
     <t>
4.	Change the frame length and repeat from step1 to step4.
     </t>         
    </section>      	    
     <!-- END 6.2.4 Test process -->   
 
      <!-- BEGIN 6.2.5 Test result format -->  
   
    <section anchor="sec:Test_result_format__frame_loss_percentage" title="Test result format">    
<figure anchor="table-sample_test_result_format_frame_loss_percentage" align="center"
                title="test result format">
          <artwork>
-----------------------------------------------------------------
|Byte|Maxmum rate |90% Maximum |80% Maximum |...|  rate with    |
|    |   (Gbps)   | rate (Gbps)| rate (Gbps)|   | no loss (Gbps)|
-----------------------------------------------------------------
|  64|            |            |            |   |               |
-----------------------------------------------------------------
| 128|            |            |            |   |               |
-----------------------------------------------------------------
| 256|            |            |            |   |               |
-----------------------------------------------------------------
| 512|            |            |            |   |               |
-----------------------------------------------------------------
|1024|            |            |            |   |               |
-----------------------------------------------------------------
|1518|            |            |            |   |               |
-----------------------------------------------------------------
  
       </artwork>
        </figure>     
       
    </section>      	    
     <!-- END 6.2.5 Test result format -->     
      </section>  
    <!-- END 6.2 Frame loss rate-->     
    
    
     
     
    <!-- BEGIN 6.3 CPU consumption -->   
    <section title="CPU consumption">
      <t>
The objective of the test is to determine the CPU load of DUT(VSWITCH). The operation of DUT (VSWITCH) can increase 
the CPU load of host server. Different V-Switches have different CPU occupation. This can be an important indicator 
in benchmarking the virtual network performance.
    </t>
    
    <!-- BEGIN 6.3.1 Objectives -->  
    <section title="Objectives">    
     <t>The objective of this test is to verify the CPU consumption caused by the DUT (VSWITCH).
     </t>  
    </section>      	    
    <!-- END 6.3.1 Objectives -->      
    
     <!-- BEGIN 6.3.2 Configuration parameters -->  
    <section title="Configuration parameters">    
     <t>
     Network parameters should be defined as follows:
     </t>  
     <t>
a) the number of virtual tester (VMs)
     </t>  
     <t>
b)	the number of vNIC of virtual tester
     </t>  
     <t>
c)	the CPU type of the server
    </t>  
     <t>
d)	vCPU allocated for virtual tester (VMs)
    </t>  
     <t>
e)	memory allocated for virtual tester (VMs)
    </t>  
     <t>
f)	the number and rate of server NIC
     </t>  
    </section>      	    
     <!-- END 6.3.2 Configuration parameters --> 
     <!-- BEGIN 6.3.3 Test parameters -->  
    <section title="Test parameters">    
     
     <t>
a)	test repeated times
     </t>  
     <t>
b)	test frame length
     </t> 
     <t>
c)	traffic rate
     </t>   
    </section>      	    
     <!-- END 6.3.3 Test parameters -->        
 
     <!-- BEGIN 6.3.4 Test process -->  
    <section title="Test process">    
     
     <t>
1.	Configure the VM tester to offer traffic to the V-Switch with certain traffic rate. The 
traffic rate could be different ratio of NIC's speed.
     </t> 
     <t>     
2.	Record vSwitch's CPU usage on the host OS if no packets loss happens. 
     </t> 
     <t>
3.	Change the traffic rate and repeat from step1 to step2.
     </t>
     <t>
4.	Change the frame length and repeat from step1 to step3.
     </t>
    </section>      	    
     <!-- END 6.3.4 Test process -->   
 
      <!-- BEGIN 6.3.5 Test result format -->  
  <section anchor="sec:Test_result_format__cpu" title="Test result format">    
<figure anchor="table-sample_test_result_cpu" align="center"
                title="test result format">
          <artwork>
      --------------------------------------------------
      | Byte| Traffic Rate(Gbps)| CPU usage of vSwitch |
      --------------------------------------------------
      |     | 50% of NIC speed  |                      |
      |     |-------------------------------------------
      |  64 |         75%       |                      |
      |     |-------------------------------------------
      |     |         90%       |                      |
      --------------------------------------------------
      |     | 50% of NIC speed  |                      |
      |     |-------------------------------------------
      | 128 |         75%       |                      |
      |     |-------------------------------------------
      |     |         90%       |                      |
      --------------------------------------------------
      ~     ~                   ~                      ~
      --------------------------------------------------
      |     | 50% of NIC speed  |                      |
      |     |-------------------------------------------
      |1500 |         75%       |                      |
      |     |-------------------------------------------
      |     |         90%       |                      |
      --------------------------------------------------
       </artwork>
       </figure>     
    </section>      	    
     <!-- END 6.3.5 Test result format-->     
      </section>  
    <!-- END 6.3  CPU consumption -->   

     <!-- BEGIN 6.4 Memory consumption -->   
    <section title="MEM consumption">
      <t>
The objective of the test is to determine the Memory load of DUT(VSWITCH). The operation of 
DUT (VSWITCH) can increase the Memory load of host server. Different V-Switches have different 
memory occupation. This can be an important indicator in benchmarking the virtual network performance.
    </t>
    
    <!-- BEGIN 6.4.1 Objectives -->  
    <section title="Objectives">    
     <t>The objective of this test is to verify the memory consumption by the DUT (VSWITCH) on the Host server.
     </t>  
    </section>      	    
    <!-- END 6.4.1 Objectives -->      
    
     <!-- BEGIN 6.4.2 Configuration parameters -->  
    <section title="Configuration parameters">    
     <t>
     Network parameters should be defined as follows:
     </t>  
     <t>
a) the number of virtual tester (VMs)
     </t>  
     <t>
b)	the number of vNIC of virtual tester
     </t>  
     <t>
c)	the CPU type of the server
    </t>  
     <t>
d)	vCPU allocated for virtual tester (VMs)
    </t>  
     <t>
e)	memory allocated for virtual tester (VMs)
    </t>  
     <t>
f)	the number and rate of server NIC
     </t>  
    </section>      	    
     <!-- END 6.4.2 Configuration parameters --> 
     <!-- BEGIN 6.4.3 Test parameters -->  
    <section title="Test parameters">    
     
     <t>
a)	test repeated times
     </t>  
     <t>
b)	test frame length
     </t>    
    </section>      	    
     <!-- END 6.4.3 Test parameters -->        
 
     <!-- BEGIN 6.4.4 Test process -->  
    <section title="Test process">    
     
     <t>
1.	Configure the VM tester to offer traffic to the V-Switch with certain traffic rate. The 
traffic rate could be different ratio of NIC's speed.
     </t> 
     <t>     
2.	Record vSwitch's MEM usage on the host OS if no packets loss happens. 
     </t> 
     <t>
3.	Change the traffic rate and repeat from step1 to step2.
     </t>
     <t>
4.	Change the frame length and repeat from step1 to step3.
     </t>
    </section>      	    
     <!-- END 6.4.4 Test process -->   
 
      <!-- BEGIN 6.4.5 Test result format -->  
 <section anchor="sec:Test_result_format__memory" title="Test result format">    
<figure anchor="table-sample_test_result_format_memory" align="center"
                title="test result format">
          <artwork>
      --------------------------------------------------
      | Byte| Traffic Rate(Gbps)| MEM usage of vSwitch |
      --------------------------------------------------
      |     | 50% of NIC speed  |                      |
      |     |-------------------------------------------
      |  64 |         75%       |                      |
      |     |-------------------------------------------
      |     |         90%       |                      |
      --------------------------------------------------
      |     | 50% of NIC speed  |                      |
      |     |-------------------------------------------
      | 128 |         75%       |                      |
      |     |-------------------------------------------
      |     |         90%       |                      |
      --------------------------------------------------
      ~     ~                   ~                      ~
      --------------------------------------------------
      |     | 50% of NIC speed  |                      |
      |     |-------------------------------------------
      |1500 |         75%       |                      |
      |     |-------------------------------------------
      |     |         90%       |                      |
      --------------------------------------------------
       </artwork>
       </figure>     
       
    </section>      	    
     <!-- END 6.4.5 Test result format -->     
      </section>  
    <!-- END 6.4  MEM consumption -->     
 
     <!-- BEGIN 6.5 Latency -->   
    <section title="Latency">
      <t>
Physical tester's time refers from its own clock or other time source, such as GPS,
 which can achieve the accuracy of 10ns. While in virtual network circumstances, the 
 virtual tester gets its reference time from the clock of Linux systems and it's hard
 to make the physical and virtual tester keep precisely synchronized. So We use the 
 traffic model B as the latency test model.  
	</t>
<figure anchor="table-test_model_time_delay" align="center" title="time delay test model">
          <artwork>
 ______________________________________________________________  
|                                                              |
|   ----------------    ----------------     ----------------  |
|   |Virtual tester|----|DUT (VSWITCH) |-----|Virtual tester|  |
|   ----------------    ----------------     ----------------  |
|  Server                                                      |
|______________________________________________________________|
                        
       </artwork>
        </figure>
<t>
	
	</t>
    
    <!-- BEGIN 6.5.1 Objectives -->  
    <section title="Objectives">    
     <t>The objective of this test is to verify the DUT (VSWITCH) for latency of the flow. This can be an important 
     	indicator in benchmarking the virtual network performance.
     </t>  
    </section>      	    
    <!-- END 6.5.1 Objectives -->      
    
     <!-- BEGIN 6.5.2 Configuration parameters -->  
    <section title="Configuration parameters">    
     <t>
     Network parameters should be defined as follows:
     </t>  
     <t>
a) the number of virtual tester (VMs)
     </t>  
     <t>
b)	the number of vNIC of virtual tester
     </t>  
     <t>
c)	the CPU type of the server
    </t>  
     <t>
d)	vCPU allocated for virtual tester (VMs)
    </t>  
     <t>
e)	memory allocated for virtual tester (VMs)
    </t>  
     <t>
f)	the number and rate of server NIC
     </t>  
    </section>      	    
     <!-- END 6.5.2 Configuration parameters --> 
     <!-- BEGIN 6.5.3 Test parameters -->  
    <section title="Test parameters">    
     
     <t>
a)	test repeated times
     </t>  
     <t>
b)	test frame length
     </t>    
    </section>      	    
     <!-- END 6.5.3 Test parameters -->        
 
     <!-- BEGIN 6.5.4 Test process -->  
    <section title="Test process">    
     
     <t>
1.	Configure the virtual tester to offer traffic to the V-Switch with the traffic value of throughput tested in 6.1.
     </t> 
     <t>     
2.	Keep the traffic for a while and then stop it, record the minimum, maximum and average latency.
</t> 
     <t>
3.	Change the frame length and repeat from step1 to step4.
     </t>         
    </section>      	    
     <!-- END 6.5.4 Test process -->   
 
      <!-- BEGIN 6.5.5 Test result format -->  
 <section anchor="sec:Test_result_format__time_delay" title="Test result format">    
<figure anchor="table-sample_test_result_format__time_delay" align="center"
                title="test result format">
          <artwork>
 +-----+-----------------+-----------------+------------------+
 | Byte|  Min Latency    |  Max Latency    |  Average Latency |
 +-----+-----------------+-----------------+------------------+
 |  64 |                 |                 |                  |
 +-----+-----------------+-----------------+------------------+
 | 128 |                 |                 |                  |
 +-----+-----------------+-----------------+------------------+
 | 256 |                 |                 |                  |
 +-----+-----------------+-----------------+------------------+
 | 512 |                 |                 |                  |
 +-----+-----------------+-----------------+------------------+
 | 1024|                 |                 |                  |
 +-----+-----------------+-----------------+------------------+
 | 1518|                 |                 |                  |
 +-----+-----------------+-----------------+------------------+
      </artwork>
       </figure>          
          	
    </section>      	    
     <!-- END 6.5.5 Test result format -->     
      </section> 
     <!-- END 6.5 Latency -->                     
  </section>
  <!-- END 6 Benchmarking Tests -->      
  <!-- BEGIN 7. Security Considerations -->
  <section anchor="sec:security_considerations" title="Security Considerations">

    <t>
      None.
    </t>

  </section>
  <!-- END 7. Security Considerations -->

  <!-- BEGIN 8. IANA Considerations -->
  <section anchor="sec:iana" title="IANA Considerations">

    <t>
      None.
    </t>

  </section>
  <!-- END 8. IANA Considerations -->

 </middle>

 <back>

  <references title="Normative References">
<?rfc include="reference.RFC.1242.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2234.xml"?>
<?rfc include="reference.RFC.2544.xml"?>
  </references>


 </back>

</rfc>
