Internet DRAFT - draft-ietf-bmwg-dsmterm

draft-ietf-bmwg-dsmterm




     Network Working Group                       Scott Poretsky   
     INTERNET-DRAFT                              Reef Point Systems  
     Expires in: December 2006                        
                                                 Jerry Perser
                                                 Veriwave
                                                    
                                                 Shobha Erramilli 
                                                 Telcordia 
                                                    
                                                 Sumit Khurana  
                                                 Telcordia 
                                                     
                                                 June 2006 
      
              Terminology for Benchmarking Network-layer 
                     Traffic Control Mechanisms 
      
                  <draft-ietf-bmwg-dsmterm-13.txt> 
      
Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, each author represents that any 
applicable patent or other IPR claims of which he or she is aware 
have been or will be disclosed, and any of which he or she becomes 
aware will be disclosed, in accordance with Section 6 of BCP 79.

Status of this Memo

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice
   Copyright (C) The Internet Society (2006).  

Abstract       
     This document describes terminology for the benchmarking of 
     devices that implement traffic control using packet classification 
     based on defined criteria.  The terminology is to be applied to 
     measurements made on the data plane to evaluate IP traffic control 
     mechanisms.  Rules for packet classification can be based on any 
     field in the IP header, such as DSCP, or field in the packet 
     payload, such as port number.

Perser, Poretsky, Khurana, Erramilli                  [Page 1] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
     Table of Contents       
        1. Introduction .............................................. 3 
        2. Existing definitions ...................................... 3 
        3. Term definitions............................................4 
        3.1 Configuration Terms 
          3.1.1 Classification.........................................4 
          3.1.2 Codepoint Set..........................................4 
          3.1.3 Forwarding Congestion..................................5 
          3.1.4 Congestion Management..................................6 
          3.1.5 Flow...................................................7 
        3.2 Measurement Terms 
          3.2.1 Forwarding Capacity....................................7 
          3.2.2 Conforming Packet......................................8 
          3.2.3 Nonconforming Packet...................................9 
          3.2.4 Forwarding Delay.......................................9 
          3.2.5 Jitter................................................11 
          3.2.6 Undifferentiated Response.............................11 
        3.3 Sequence Tracking 
          3.3.1 In-sequence Packet....................................12 
          3.3.2 Out-of-order Packet...................................12 
          3.3.3 Duplicate Packet......................................13 
          3.3.4 Stream................................................14 
          3.3.5 Test Sequence number .................................15 
        3.4 Vectors...................................................15 
          3.4.1 Intended Vector.......................................15 
          3.4.2 Offered Vector........................................16 
          3.4.3 Expected Vectors......................................16 
          3.4.4 Output Vectors........................................23
        4. IANA Considerations........................................31
        5. Security Considerations....................................31 
        6. Acknowledgments............................................31  
        7. References.................................................32 
        8. Author's Address...........................................33 
        9. Full Copyright Statement...................................34 
      
1. Introduction 
      
     New terminology is needed because most existing measurements 
     assume the absence of congestion and only a single per-hop-
     behavior.  This document introduces several new terms that will 
     allow measurements to be taken during periods of congestion. 

     Another key difference from existing terminology is the definition 
     of measurements as observed on egress as well as ingress of a 
     device/system under test.  Again, the existence of congestion 
     requires the addition of egress measurements as well as those 
     taken on ingress; without observing traffic leaving a 
     device/system it is not possible to say whether traffic-control 
     mechanisms effectively dealt with congestion. 
      
Perser, Poretsky, Khurana, Erramilli                          [Page 2] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 

     The principal measurements introduced in this document are vectors 
     for rate, delay, and jitter, all of which can be observed with or 
     without congestion of the Device Under Test (DUT)/ System Under 
     Test (SUT). This document describes only those terms relevant to 
     measuring behavior of a DUT or SUT at the Egress during periods of 
     congestion.  End-to-end and service-level measurements are beyond 
     the scope of this document. 
            
2.  Existing definitions       
     RFC 1224 "Techniques for Managing Asynchronously Generated Alerts"
     [St91] is used for 'Time with fine enough units to distinguish 
     between two events'

     RFC 1242 "Benchmarking Terminology for Network Interconnect 
     Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 
     Devices" should be consulted before attempting to make use of this 
     document. 
      
     RFC 2474 "Definition of the Differentiated Services Field (DS 
     Field) in the IPv4 and IPv6 Headers" section 2, contains 
     discussions of a number of terms relevant to network-layer traffic 
     control mechanisms and should also be consulted. 
      
     For the sake of clarity and continuity this RFC adopts the 
     template for definitions set out in Section 2 of RFC 1242.  
     Definitions are indexed and grouped together in sections for ease 
     of reference. 
      
   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 BCP 14, RFC 2119
   [Br97].  RFC 2119 defines the use of these key words to help make the
   intent of standards track documents as clear as possible.  While this
   document uses these keywords, this document is not a standards track
   document.

   2.1 Frequently Used Acronyms
      DA   Destination Address
      DS   DiffServ
      DSCP DiffServ Code Point
      DUT  Device Under Test
      IP   Internet Protocol
      PHB  Per Hop Behavior
      SA   Source Address
      SUT  System Under Test

Perser, Poretsky, Khurana, Erramilli                          [Page 3] 

INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
         
3. Term definitions       

     3.1 Configuration Terms       

     3.1.1 Classification 
      
        Definition: 
          Selection of packets according to defined rules. 
      
        Discussion: 
          Classification determines the per-hop behaviors and traffic 
          conditioning functions such as shaping and dropping that 
          are to be applied to the packet. 

          Classification of packets can be made based on the DS field 
          or IP Precedence in the packet header.  Classification can 
          be based on other IP header fields such as IP Source 
          Address (SA), Destination Address (DA), and protocol, or 
          fields in the packet payload such as port number.  
          Classification can also be based on ingress interface.
          It is possible to classify based on Multi-Field (MF) 
          criteria such as IP source and destination addresses, 
          protocol and port number.  
           
        Measurement units: n/a 
      
        See Also: None
            
     3.1.2 Codepoint Set  
     
        Definition: 
          The set of all DS Code-points or IP precedence values used 
          during the test duration. 
      
        Discussion: 
          Describes all the code-point markings associated with packets 
          that are input to the DUT/SUT.  For each entry in the 
          codepoint set, there are associated vectors describing the 
          rate of traffic, delay, loss, or jitter containing that 
          particular DSCP or IP precedence value. 
           
          The treatment that a packet belonging to a particular code-
          point gets is subject to the DUT classifying packets to map 
          to the correct PHB.  Moreover, the forwarding treatment in 
          general is also dependent on the complete set of offered 
          vectors. 
      
        Measurement Units: n/a 
      
        See Also: None
   


Perser, Poretsky, Khurana, Erramilli                          [Page 4] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
     3.1.3 Forwarding Congestion 
      
        Definition: 
          A condition in which one or more egress interfaces are 
          offered more packets than are forwarded. 
      
        Discussion: 
          This condition is a superset of the overload definition 
          [Ma98].  Overload [Ma98] deals with overloading input and 
          output interfaces beyond the maximum transmission allowed by 
          the medium.  Forwarding congestion does not assume ingress 
          interface overload as the only source of overload on output 
          interfaces. 
           
          Another difference between Forwarding Congestion and overload 
          occurs when the SUT comprises multiple elements, in that 
          Forwarding Congestion may occur at multiple points.  Consider 
          a SUT comprising multiple edge devices exchanging traffic 
          with a single core device.  Depending on traffic patterns, 
          the edge devices may induce Forwarding Congestion on multiple 
          egress interfaces on the core device. 
           
          Throughput [Br91] defines the lower boundary of Forwarding 
          Congestion.  Throughput is the maximum offered rate with no 
          Forwarding Congestion.  At offered rates above throughput, 
          the DUT/SUT is considered to be in a state of Forwarding 
          Congestion. 

          Packet Loss, not increased Forwarding Delay, is the 
          external observable metric used to indicate the condition 
          of Forwarding Congestion.  Packet Loss is a deterministic 
          indicator of Forwarding Congestion.  The condition of 
          increased Forwarding Delay without Packet Loss is an 
          indicator of Forwarding Congestion known as Incipient 
          Congestion.   Incipient Congestion is a non-deterministic 
          indicator of Forwarding Congestion [Fl93].  As stated in 
          [Ec98], RED [Br98] detects incipient congestion before the 
          buffer overflows, but the current Internet environment is 
          limited to packet loss as the mechanism for indicating 
          congestion to the end-nodes. [Ra99] implies that it is 
          impractical to build a black-box test to observe Incipient 
          Congestion.  [Ra99] instead introduces Explicit Congestion 
          Notification (ECN) as a deterministic Black-Box method for 
          observing Incipient Congestion.  [Ra99] is an Experimental 
          RFC with limited deployment, so ECN is not used for this 
          particular methodology.  For the purpose of "black-box" 
          testing a DUT/SUT, this methodology uses Packet Loss as the 
          indicator of Forwarding Congestion. 




Perser, Poretsky, Khurana, Erramilli                          [Page 5] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
          Ingress observations alone are not sufficient to cover all 
          cases in which Forwarding Congestion may occur.  A device 
          with an infinite amount of memory could buffer an infinite 
          number of packets, and eventually forward all of them.  
          However, these packets may or may not be forwarded during 
          the test duration.  Congestion Collapse [Na84] is defined 
          as the state in which buffers are full and all arriving 
          packets MUST be dropped across the network.  Even though 
          ingress interfaces accept all packets without loss, 
          Forwarding Congestion is present in this hypothetical 
          device. 
           
          The definition presented here explicitly defines 
          Forwarding Congestion as an event observable on egress 
          interfaces.  Regardless of internal architecture, any 
          device exhibiting Packet Loss on one or more egress 
          interfaces is experiencing Forwarding Congestion. 
      
        Measurement units: 
          None 
      
        See Also: 
          Gateway Congestion Control Survey [Ma91] 
            
     3.1.4 Congestion Management 
      
        Definition: 
          An implementation of one or more per-hop-behaviors to avoid 
          or minimize the condition of congestion. 
      
        Discussion: 
          Congestion management may seek either to control congestion 
          or avoid it altogether through Classification.
           
          Congestion avoidance mechanisms seek to prevent congestion 
          before it actually occurs. 
           
          Congestion control mechanisms give one or more flows (with a 
          discrete IP Precedence or DSCP value) preferential treatment 
          over other classes during periods of congestion. 
      
        Measurement units: 
           n/a 
      
        See Also: 
           Classification
   






Perser, Poretsky, Khurana, Erramilli                          [Page 6] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms       
      
     3.1.5 Flow 
       
        Definition: 
          A flow is a one or more of packets sharing a common intended 
          pair of ingress and egress interfaces. 
      
        Discussion: 
          Packets are grouped by the ingress and egress interfaces they 
          use on a given DUT/SUT. 
           
          A flow can contain multiple source IP addresses and/or 
          destination IP addresses.  All packets in a flow MUST enter 
          on the same ingress interface and exit on the same egress 
          interface, and have some common network layer content. 
           
          Microflows [Ni98] are a subset of flows.  As defined in 
          [Ni98], microflows require application-to-application 
          measurement.  In contrast, flows use lower-layer 
          classification criteria.  Since this document focuses on 
          network-layer classification criteria, we concentrate here on 
          the use of network-layer identifiers in describing a flow.  
          Flow identifiers also may reside at the data-link, transport, 
          or application layers of the OSI model.  However, identifiers 
          other than those at the network layer are out of scope for 
          this document. 
           
          A flow may contain a single code point/IP precedence value or 
          may contain multiple values destined for a single egress 
          interface.  This is determined by the test methodology. 
      
        Measurement units: 
           n/a 
      
        See Also: 
          Microflow [Ni98] 
          Streams 
           
     3.2 Measurement Terms  
      
     3.2.1 Forwarding Capacity 
      
        Definition: 
          The number of packets per second that a device can be 
          observed to successfully transmit to the correct destination 
          interface in response to a specified offered load while the 
          device drops none of the offered packets. 
           
        Discussion: 
          Forwarding Capacity measures the packet rate at the egress 
          interface(s) of the DUT/SUT.  In contrast, throughput as 
          defined in RFC 1242 measures the packet rate at the ingress 
          interface(s) of the DUT/SUT. 
           
Perser, Poretsky, Khurana, Erramilli                          [Page 7] 

INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
           
          Ingress-based measurements do not account for queuing of the 
          DUT/SUT.  Throughput rates can be higher than the Forwarding 
          Capacity because of queueing.  The difference is dependent 
          upon test duration, packet rate, and queue size.  Forwarding 
          Capacity, as an egress measurement, does take queuing into 
          account. 
           
          Understanding Forwarding Capacity is a necessary precursor to 
          any measurement involving Traffic Control Mechanisms.  The 
          accompanying methodology document MUST take into 
          consideration Forwarding Capacity when determining the 
          expected forwarding vectors.  When the sum of the expected 
          forwarding vectors on an interface exceeds the Forwarding 
          Capacity, the Forwarding Capacity will govern the forwarding 
          rate. 
           
          This measurement differs from forwarding rate at maximum 
          offered load (FRMOL) [Ma98] in that Forwarding Capacity 
          requires zero loss. 
           
        Measurement units: 
           N-octet packets per second 
      
        See Also: 
          Throughput [Br91] 
          Forwarding Rate at Maximum Offered Load [Ma98] 
      
      
     3.2.2 Conforming Packet 
      
        Definition: 
          Packets which lie within specific rate, delay, or jitter 
          bounds. 
      
        Discussion: 
          A DUT/SUT may be configured to allow a given traffic class to 
          consume a given amount of bandwidth, or to fall within 
          predefined delay or jitter boundaries.  All packets that lie 
          within specified bounds are then said to be conforming, 
          whereas those outside the bounds are nonconforming. 
      
        Measurement units: 
           n/a 
      
        See Also: 
          Expected Vector 
          Forwarding Vector 
          Offered Vector 
          Nonconforming 
                
Perser, Poretsky, Khurana, Erramilli                          [Page 8] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
           
     3.2.3 Nonconforming Packet 
      
        Definition: 
          Packets that do not lie within specific rate, delay, or 
          jitter bounds. 
      
        Discussion: 
          A DUT/SUT may be configured to allow a given traffic class to 
          consume a given amount of bandwidth, or to fall within 
          predefined delay or jitter boundaries.  All packets that do 
          not lie within these bounds are then said to be 
          nonconforming. 
      
        Measurement units: 
           n/a 
      
        See Also: 
          Expected Vector 
          Forwarding Vector 
          Offered Vector 
          Conforming 
      
     3.2.4 Forwarding Delay 
      
        Definition: 
          The time interval starting when the last bit of the input IP 
          packet is offered to the input port of the DUT/SUT and ending 
          when the last bit of the output IP packet is received from 
          the output port of the DUT/SUT. 
           
        Discussion: 
          The delay time interval MUST be externally observed.  The 
          delay measurement MUST NOT include delays added by test bed 
          components other than the DUT/SUT, such as propagation time 
          introduced by cabling or non-zero delay added by the test 
          instrument. Forwarding Delay differs from latency [Br91] 
          and one-way delay [Al99] in several key regards: 
           
          1. Latency [Br91] assumes knowledge of whether the DUT/SUT 
          uses "store and forward" or "bit forwarding" technology.  
          Forwarding Delay is the same metric, measured the same way, 
          regardless of the architecture of the DUT/SUT. 

          2. Forwarding Delay is a last-in, last-out (LILO) 
          measurement, unlike the last-in, first-out method [Br91] or 
          the first-in, last-out method [Al99]. 
           
          The LILO method most closely simulates the way a network-
          layer device actually processes an IP datagram.  IP datagrams 
          are not passed up and down the stack unless they are 
          complete, and processing begins only once the last bit of the 
          IP datagram has been received. 
   
Perser, Poretsky, Khurana, Erramilli                          [Page 9] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
              
          Further, the LILO method has an additive property, where the 
          sum of the parts MUST equal the whole.  This is a key 
          difference from [Br91] and [Al99].  For example, the delay 
          added by two DUTs MUST equal the sum of the delay of the 
          DUTs.  This may or may not be the case with [Br91] and 
          [Al99]. 
           
          3. Forwarding Delay measures the IP datagram only, unlike 
          [Br91], which also includes link layer overhead. 
           
          A metric focused exclusively on the Internet protocol 
          relieves the tester from specifying the start/end for every 
          link layer protocol that IP runs on.  This avoids the need to 
          determine whether the start/stop delimiters are included.  It 
          also allows the use of heterogeneous link layer protocols in 
          a test. 
           
          4. Forwarding Delay can be measured at any offered load, 
          whereas the latency methodology [Br99] recommends measurement 
          at, and only at, the throughput level.  Comparing the 
          Forwarding Delay below the throughput to Forwarding Delay 
          above the Forwarding Capacity will give insight to the 
          traffic control mechanisms. 
           
          For example, non-congested delay may be measured with an 
          offered load that does not exceed the Forwarding Capacity, 
          while congested delay may involve an offered load that 
          exceeds Forwarding Capacity. 
           
          Note: Forwarding Delay SHOULD NOT be used as an absolute 
          indicator of DUT/SUT Forwarding Congestion.  While Forwarding 
          Delay may rise when offered load nears or exceeds Forwarding 
          Capacity, there is no universal point at which Forwarding 
          Delay can be said to indicate the presence or absence of 
          Forwarding Congestion. 
      
        Measurement units: 
           milliseconds 
     
        See Also: 
          Latency [Br91] 
          Latency [Al99] 
          One-way Delay [Br99] 
            
Perser, Poretsky, Khurana, Erramilli                         [Page 10] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 

     3.2.5 Jitter 
      
        Definition: 
          The absolute value of the difference between the arrival 
          delay of two consecutive received packets belonging to the 
          same stream. 
      
        Discussion: 
          The Forwarding Delay fluctuation between two consecutive 
          received packets in a stream is reported as the Jitter.  
          Jitter can be expressed as |D(i) - D(i-1)| where D equals 
          the Forwarding Delay and i is the order the packets were 
          received. 
           
          Under loss, jitter can be measured between non-consecutive 
          test sequence numbers.  When IP Traffic Control Mechanisms 
          are dropping packets, fluctuating Forwarding Delay may be 
          observed.  Jitter MUST be able to benchmark the delay 
          variation independent of packet loss. 
           
          Jitter is related to the IPDV [De02] (IP Delay Variation) by 
          taking the absolute value of the ipdv.  The two metrics will 
          produce different mean values.  Mean Jitter will produce a 
          positive value, where the mean ipdv is typically zero.  Also,
          IPDV is undefined when one packet from a pair is lost. 
           
        Measurement units: 
          milliseconds 
      
        See Also: 
          Forwarding Delay 
          Jitter variation [Ja99] 
          ipdv [De02] 
          interarrival jitter [Sc96] 
      
     3.2.6 Undifferentiated Response 
      
        Definition: 
          The vector(s) obtained when mechanisms used to support
          diff-serv or IP precedence are disabled. 
      
        Discussion: 
          Enabling diff-serv or IP precedence mechanisms may impose 
          additional processing overhead for packets.  This overhead 
          may degrade performance even when traffic belonging to only 
          one class, the best-effort class, is offered to the device. 
          Measurements with "undifferentiated response" SHOULD be made 
          to establish a baseline. 

Perser, Poretsky, Khurana, Erramilli                         [Page 11] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
           
          The vector(s) obtained with DSCP or IP precedence enabled can 
          be compared to the undifferentiated response to determine the 
          effect of differentiating traffic. 
      
        Measurement units: 
          n/a 
            
     3.3 Sequence Tracking  
      
     3.3.1 In-sequence Packet 
      
        Definition: 
          A received packet with the expected Test Sequence number. 
      
        Discussion: 
          In-sequence is done on a stream level.  As packets are 
          received on a stream, each packets Test Sequence number is 
          compared with the previous packet.  Only packets that match 
          the expected Test Sequence number are considered in-sequence. 
           
          Packets that do not match the expected Test Sequence number 
          are counted as "not in-sequence" or out-of-sequence.  Every 
          packet that is received is either in-sequence or out-of-
          sequence.  Subtracting the in-sequence from the received 
          packets (for that stream), the tester can derive the 
          out-of-sequence count. 
           
          Two types of events will prevent the in-sequence from 
          incrementing: packet loss and reordered packets. 
      
        Measurement units: 
          Packet count 
      
        See Also: 
          Stream 
          Test Sequence number 
      
      
     3.3.2 Out-of-order Packet 
      
        Definition: 
          A received packet with a sequence number less than 
          the sequence number of a previously arriving packet. 
      
      
      
      
   

Perser, Poretsky, Khurana, Erramilli                         [Page 12] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
        Discussion: 
          As a stream of packets enters a DUT/SUT, they include a 
          Stream Test Sequence number indicating the order the packets 
          were sent to the DUT/SUT.  On exiting the DUT/SUT, these 
          packets may arrive in a different order.  Each packet that 
          was re-ordered is counted as an Out-of-order Packet. 
           
          Certain streaming protocol (such as TCP) require the packets 
          to be in a certain order.  Packets outside this are dropped 
          by the streaming protocols even though there were properly 
          received by the IP layer.  The type of reordering tolerated 
          by a streaming protocol varies from protocol to protocol, and 
          also by implementation. 
                      
          Packet loss does not affect the Out-of-order Packet count.  
          Only packets that were not received in the order that they 
          were transmitted. 
      
        Measurement units: 
          packets 
      
        See Also: 
          Stream 
          Test Sequence number 
          Packet Reordering Metric for IPPM [Mo03] 
            
     3.3.3 Duplicate Packet 
      
        Definition: 
          A received packet with a Test Sequence number matching a 
          previously received packet. 
      
        Discussion: 
          A Duplicate Packet is a packet that the DUT/SUT has 
          successfully transmitted out an egress interface more than 
          once.  The egress interface has previously forwarded this 
          packet. 
           
          A Duplicate Packet SHOULD be a bit for bit copy of an already 
          transmitted packet (including Test Sequence number).  If the 
          Duplicate Packet traversed different paths through the 
          DUT/SUT, some fields (such as TTL or checksum) may have 
          changed. 
           
          A multicast packet is not a Duplicate Packet by definition.  
          For a given IP multicast group, a DUT/SUT SHOULD forward a 
          packet once on a given egress interface provided the path to 
          one or more multicast receivers is through that interface.  
          Several egress interfaces will transmit the same packet, but 
          only once per interface.            
           
Perser, Poretsky, Khurana, Erramilli                         [Page 13] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   

           
          To detect a Duplicate Packet, each offered packet to the 
          DUT/SUT MUST contain a unique packet-by-packet identifier. 
      
        Measurement units: 
          Packet count 
      
        See Also: 
          Stream 
          Test Sequence number 
      
      
     3.3.4 Stream 
      
        Definition: 
          A group of packets tracked as a single entity by the traffic 
          receiver.  A stream MUST share common content such as type 
          (IP, UDP), IP SA/DA, packet size, or payload. 
      
        Discussion: 
          Streams are tracked by test sequence number or "unique 
          signature field" [Ma00].  Streams define how individual 
          packets statistic are grouped together to form an 
          intelligible summary. 
           
          Common stream groupings would be by egress interface, 
          destination address, source address, DSCP, or IP precedence.  
          A stream using test sequence numbers can track the ordering 
          of packets as they traverse the DUT/SUT. 
           
          Streams are not restricted to a pair of source and 
          destination interfaces as long as all packets are tracked as 
          a single entity.  A multicast stream can be forwarded to 
          multiple destination interfaces. 
      
        Measurement units: 
           n/a 
      
        See Also: 
          Flow 
          Microflow [Ni98] 
          Test sequence number 
      
      
      
      
Perser, Poretsky, Khurana, Erramilli                         [Page 14] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
     3.3.5 Test Sequence Number    
        Definition: 
          A field in the IP payload portion of the packet that is used 
          to verify the order of the packets on the egress of the 
          DUT/SUT. 
      
        Discussion: 
          The traffic generator sets the test sequence number value and 
          the traffic receiver checks the value upon receipt of the 
          packet.  The traffic generator changes the value on each 
          packet transmitted based on an algorithm agreed to by the 
          traffic receiver. 
           
          The traffic receiver keeps track of the sequence numbers on a 
          per stream basis.  In addition to number of received packets, 
          the traffic receiver may also report the number of 
          in-sequence packets, number of out-of-sequence packets, 
          number of duplicate packets, and number of reordered packets.    
          The RECOMMENDED algorithm to use to change the sequence 
          number on sequential packets is an incrementing value. 
      
        Measurement units: 
           n/a 
      
        See Also: 
          Stream 
      
     3.4 Vectors 
          A vector is a group of packets all matching a specific 
          classification criteria, such as DSCP.  Vectors are 
          identified by the classification criteria and benchmarking 
          metrics such as a Forwarding Capacity, Forwarding Delay, 
          or Jitter.    
      
     3.4.1 Intended Vector 
        Definition: 
          A description of the configuration on an external source
          for the attempted rate of a stream transmitted to a DUT/SUT
          matching specific classification rules. 
          
        Discussion: 
          The Intended Vector of a stream influences the benchmark 
          measurements.  The Intended Vector is described by the 
          classification criteria and attempted rate.
      
        Measurement Units: 
          N-bytes packets per second 
      
        See Also: 
          Stream
          Offered Vector 
          Forwarding Vector 
      
Perser, Poretsky, Khurana, Erramilli                         [Page 15] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
     3.4.2 Offered Vector 
      
        Definition: 
          A description for the attempted rate of a stream offered to 
          a DUT/SUT matching specific classification rules. 
      
        Discussion: 
          The Offered Vector of a stream influences the benchmark 
          measurements.  The Offered Vector is described by the 
          classification criteria and offered rate.
      
        Measurement Units: 
          N-bytes packets per second 
      
        See Also: 
          Stream
          Intended Vector 
          Forwarding Vector 
      
     3.4.3 Expected Vectors       
     3.4.3.1 Expected Forwarding Vector 
      
        Definition: 
          A description of the expected output rate of packets 
          matching a specific classification, such as DSCP.  
      
       Discussion: 
          The value of the Expected Minimum Delay Vector is dependent 
          on the set of offered vectors and Classification 
          configuration on the DUT/SUT.  The DUT is configured in a 
          certain way in order that classification occurs when a 
          traffic mix consisting of multiple streams is applied.  

          This term captures the expected forwarding behavior from the 
          DUT receiving multiple Offered Vectors.  The actual algorithm 
          or mechanism the DUT uses to achieve service differentiation 
          is implementation specific and not important when describing 
          the Expected Forwarding Vector. 
           
        Measurement units: 
          N-octet packets per second 
      
        See Also: 
          Classification
          Stream
          Intended Vector 
          Offered Vector 
      
Perser, Poretsky, Khurana, Erramilli                         [Page 16] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
     3.4.3.2 Expected Loss Vector 
      
        Definition: 
          A description of the percentage of packets, having a 
          specific classification that SHOULD NOT be forwarded.  
      
        Discussion: 
          The value of the Expected Minimum Delay Vector is dependent 
          on the set of offered vectors and Classification 
          configuration on the DUT/SUT.  The DUT is configured in a 
          certain way in order that classification occurs when a 
          traffic mix consisting of multiple streams is applied.  

          This term captures the expected forwarding behavior from the 
          DUT receiving multiple Offered Vectors.  The actual algorithm 
          or mechanism the DUT uses to achieve service differentiation 
          is implementation specific and not important when describing 
          the Expected Loss Vector. 
      
        Measurement Units: 
          Percentage of intended packets that is expected to be 
          dropped. 
      
        See Also: 
          Classification
          Stream
          Intended Vector 
          Offered Vector 
          One-way Packet Loss Metric [Ka99]      
      
     3.4.3.3 Expected Sequence Vector 
      
        Definition: 
          A description of the expected in-sequence packets matching
          a specific classification, such as DSCP.  
      
        Discussion: 
          The value of the Expected Minimum Delay Vector is dependent 
          on the set of offered vectors and Classification 
          configuration on the DUT/SUT.  The DUT is configured in a 
          certain way in order that classification occurs when a 
          traffic mix consisting of multiple streams is applied.  

          This term captures the expected forwarding behavior from the 
          DUT receiving multiple Offered Vectors.  The actual algorithm 
          or mechanism the DUT uses to achieve service differentiation 
          is implementation specific and not important when describing 
          the Expected Sequence Vector. 
           
Perser, Poretsky, Khurana, Erramilli                         [Page 17] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 

        Measurement Units: 
          N-octet packets per second 
           
        See Also: 
          Classification
          Stream
          In-Sequence Packet
          Intended Vector 
          Offered Vector 
      

     3.4.3.4 Expected Delay Vector 
      
        Definition: 
          A description of the expected instantaneous Forwarding 
          Delay for packets matching a specific classification, such 
          as DSCP.  

        Discussion: 
          The value of the Expected Minimum Delay Vector is dependent 
          on the set of offered vectors and Classification 
          configuration on the DUT/SUT.  The DUT is configured in a 
          certain way in order that classification occurs when a 
          traffic mix consisting of multiple streams is applied.  

          This term captures the expected forwarding behavior from the 
          DUT receiving multiple Offered Vectors.  The actual algorithm 
          or mechanism the DUT uses to achieve service differentiation 
          is implementation specific and not important when describing 
          the Expected Delay Vector. 
           
        Measurement units: 
          milliseconds
      
        See Also: 
          Classification
          Stream
          Forwarding Delay 
          Intended Vector 
          Offered Vector 
      
     3.4.3.5 Expected Average Delay Vector 
      
        Definition: 
          A description of the expected average Forwarding Delay 
          for packets matching a specific classification, such as 
          DSCP.  

Perser, Poretsky, Khurana, Erramilli                         [Page 18] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
      
        Discussion: 
          The value of the Expected Minimum Delay Vector is dependent 
          on the set of offered vectors and Classification 
          configuration on the DUT/SUT.  The DUT is configured in a 
          certain way in order that classification occurs when a 
          traffic mix consisting of multiple streams is applied.  

          This term captures the expected forwarding behavior from the 
          DUT receiving multiple Offered Vectors.  The actual algorithm 
          or mechanism the DUT uses to achieve service differentiation 
          is implementation specific and not important when describing 
          the Expected Average Delay Vector. 
           
        Measurement units: 
          milliseconds
      
        See Also: 
          Classification
          Stream
          Forwarding Delay 
          Intended Vector 
          Offered Vector
          Expected Delay Vector 
      
     3.4.3.6 Expected Maximum Delay Vector 
      
        Definition: 
          A description of the expected maximum Forwarding Delay 
          for packets matching a specific classification, such as 
          DSCP.  

        Discussion: 
          The value of the Expected Minimum Delay Vector is dependent 
          on the set of offered vectors and Classification 
          configuration on the DUT/SUT.  The DUT is configured in a 
          certain way in order that classification occurs when a 
          traffic mix consisting of multiple streams is applied.  

          This term captures the expected forwarding behavior from the 
          DUT receiving multiple Offered Vectors.  The actual algorithm 
          or mechanism the DUT uses to achieve service differentiation 
          is implementation specific and not important when describing 
          the Expected Maximum Delay Vector. 
           
        Measurement units: 
          milliseconds
      
Perser, Poretsky, Khurana, Erramilli                         [Page 19] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
              
        See Also: 
          Classification
          Stream
          Forwarding Delay 
          Intended Vector 
          Offered Vector
          Expected Delay Vector 
     
     3.4.3.7 Expected Minimum Delay Vector 
      
        Definition: 
          A description of the expected minimum Forwarding Delay 
          for packets matching a specific classification, such as 
          DSCP.  

        Discussion: 
          The value of the Expected Minimum Delay Vector is dependent 
          on the set of offered vectors and Classification 
          configuration on the DUT/SUT.  The DUT is configured in a 
          certain way in order that classification occurs when a 
          traffic mix consisting of multiple streams is applied.  

          This term captures the expected forwarding behavior from the 
          DUT receiving multiple Offered Vectors.  The actual algorithm 
          or mechanism the DUT uses to achieve service differentiation 
          is implementation specific and not important when describing 
          the Expected Minimum Delay Vector. 
           
        Measurement units: 
          milliseconds
      
        See Also: 
          Classification
          Stream
          Forwarding Delay 
          Intended Vector 
          Offered Vector
          Expected Delay Vector       
   
     3.4.3.8 Expected Instantaneous Jitter Vector 
      
        Definition: 
          A description of the expected instantaneous jitter between two 
          consecutive packets arrival times matching a specific 
          classification, such as DSCP. 
      
        Discussion: 
          Instantaneous Jitter is the absolute value of the difference 
          between the Forwarding Delay measurement of two packets 
          belonging to the same stream. 
           
Perser, Poretsky, Khurana, Erramilli                         [Page 20] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms            

          The Forwarding Delay fluctuation between two consecutive 
          packets in a stream is reported as the "Instantaneous 
          Jitter".  Instantaneous Jitter can be expressed as 
          |D(i) - D(i-1)| where D equals the Forwarding Delay and i is 
          the test sequence number.  Packets lost are not counted in 
          the measurement. 
           
          Forwarding Vector may contain several Jitter Vectors.  For n 
          packets received in a Forwarding Vector, there is a total of 
          (n-1) Instantaneous Jitter Vectors. 

        Measurement units: 
          milliseconds
   
        See Also: 
          Classification
          Stream
          Jitter 
          Intended Vector 
          Offered Vector
            
     3.4.3.9 Expected Average Jitter Vector 
      
        Definition: 
          A description of the expected average jitter for packets
          arriving in a stream matching a specific classification, such 
          as DSCP. 
      
        Discussion: 
          Average Jitter Vector is the average of all the Instantaneous 
          Jitter Vectors measured during the test duration for the same 
          stream. 

          The value of the Expected Average Jitter Vector is dependent 
          on the set of offered vectors and Classification 
          configuration on the DUT/SUT.  The DUT is configured in a 
          certain way in order that classification occurs when a 
          traffic mix consisting of multiple streams is applied.  

          This term captures the expected forwarding behavior from the 
          DUT receiving multiple Offered Vectors.  The actual algorithm 
          or mechanism the DUT uses to achieve service differentiation 
          is implementation specific and not important when describing 
          the Expected Average Jitter Vector. 

        Measurement units: 
          milliseconds
      
Perser, Poretsky, Khurana, Erramilli                         [Page 21] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 

        See Also: 
          Classification
          Stream
          Jitter 
          Intended Vector 
          Offered Vector 
          Expected Instantaneous Jitter Vector       
      
     3.4.3.10 Expected Peak-to-peak Jitter Vector 
      
        Definition: 
          A description of the expected maximum variation in the 
          Forwarding Delay of packet arrival times for packets
          arriving in a stream matching a specific classification, 
          such as DSCP. 
      
        Discussion: 
          Peak-to-peak Jitter Vector is the maximum Forwarding Delay 
          minus the minimum Forwarding Delay of the packets (in a 
          vector) forwarded by the DUT/SUT. 
           
          Peak-to-peak Jitter is not derived from the Instantaneous 
          Jitter Vector. Peak-to-peak Jitter is based upon all the 
          packets during the test duration, not just two consecutive 
          packets.

          The value of the Expected Peak-to-peak Jitter Vector is 
          dependent on the set of offered vectors and Classification 
          configuration on the DUT/SUT.  The DUT is configured in a 
          certain way in order that classification occurs when a 
          traffic mix consisting of multiple streams is applied.  
   
          This term captures the expected forwarding behavior from the 
          DUT receiving multiple Offered Vectors.  The actual algorithm 
          or mechanism the DUT uses to achieve service differentiation 
          is implementation specific and not important when describing 
          the Expected Peak-to-peak Jitter Vector. 
 
        Measurement units: 
          milliseconds 
      
        See Also: 
          Classification
          Stream
          Jitter 
          Intended Vector 
          Offered Vector 
          Expected Instantaneous Jitter Vector 
          Expected Average Jitter Vector 
      
Perser, Poretsky, Khurana, Erramilli                         [Page 22] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
      
     3.4.4 Output Vectors        
     3.4.4.1 Forwarding Vector 
        Definition: 
          The number of packets per second for a stream matching a 
          specific classification, such as DSCP, that a DUT/SUT 
          is measured to successfully forward to the correct 
          destination interface in response to an offered vector. 
      
        Discussion: 
          Forwarding Vector is expressed as a combination of values:  
          the classification rules AND the measured packets per 
          second for the stream matching the classification rules.      
          Forwarding Vector is a per-hop measurement.  The DUT/SUT 
          MAY remark the specific DSCP (or IP precedence) value for 
          a multi-hop measurement.  The stream remains the same.
           
        Measurement units: 
          N-octet packets per second 
      
        See Also: 
          Classification
          Stream
          Forwarding Capacity
          Intended Vector 
          Offered Vector 
          Expected Vector
      
     3.4.4.2 Loss Vector       
        Definition: 
          The percentage of packets per second for a stream 
          matching a specific classification, such as DSCP, that 
          a DUT/SUT is measured to not transmit to the correct 
          destination interface in response to an offered vector.   
      
        Discussion: 
          Loss Vector is expressed as a combination of values:  
          the classification rules AND the measured percentage 
          value of packet loss.  Loss Vector is a per-hop 
          measurement.  The DUT/SUT MAY remark the specific DSCP 
          or IP precedence value for a multi-hop measurement.  
          The stream remains the same.
           
        Measurement Units: 
          Percentage of packets 
      
        See Also: 
          Classification
          Stream
          Intended Vector 
          Offered Vector 
          Expected Vector 
          One-way Packet Loss Metric [Ka99] 
      
Perser, Poretsky, Khurana, Erramilli                         [Page 23] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
         
     3.4.4.3 Sequence Vector      
        Definition: 
          The number of packets per second for all packets in a 
          stream matching a specific classification, such as DSCP, 
          that a DUT/SUT is measured to transmit in sequence to the 
          correct destination interface in response to an offered 
          vector. 
      
        Discussion: 
          Sequence Vector is expressed as a combination of values:  
          the classification rules AND the number of packets per 
          second that are in-sequence. 
           
          Sequence Vector is a per-hop measurement.  The DUT/SUT 
          MAY remark the specific DSCP or IP precedence value for 
          a multi-hop measurement.  The stream remains the same.
      
        Measurement Units: 
          N-octet packets per second 
  
        See Also: 
          Classification
          Stream
          In-sequence Packet 
          Intended Vector 
          Offered Vector 
          Expected Vector
               
     3.4.4.4 Instantaneous Delay Vector     
        Definition: 
          The instantaneous Forwarding Delay for a packet in a 
          stream matching a specific classification, such as DSCP, 
          that a DUT/SUT is measured to successfully transmit to the 
          correct destination interface in response to an offered 
          vector. 
      
        Discussion: 
          Instantaneous Delay Vector is expressed as a combination 
          of values:  the classification rules AND Forwarding Delay.  
          For every packet received in a Forwarding Vector, there 
          is a corresponding Instantaneous Delay Vector. 
                      
          Instantaneous Delay Vector is a per-hop measurement.  The 
          DUT/SUT MAY remark the specific DSCP or IP precedence value 
          for a multi-hop measurement.  The stream remains the same.

          Instantaneous Delay Vector can be obtained at any offered 
          load.  It is RECOMMENDED to obtain this vector at or below 
          the Forwarding Capacity in the absence of Forwarding 
          Congestion.  For congested Forwarding Delay, run the 
          offered load above the Forwarding Capacity. 
                       
Perser, Poretsky, Khurana, Erramilli                         [Page 24] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 

        Measurement Units: 
          milliseconds
      
        See Also: 
          Classification
          Stream
          Forwarding Capacity
          Forwarding Delay 
          Intended Vector 
          Offered Vector 
          Expected Delay Vector
                 
     3.4.4.5 Average Delay Vector 
      
        Definition: 
          The average Forwarding Delay for packets in a stream 
          matching a specific classification, such as DSCP, that 
          a DUT/SUT is measured to successfully transmit to the 
          correct destination interface in response to an offered 
          vector. 
      
        Discussion: 
          Average Delay Vector is expressed as combination of values:  
          the classification rules AND average Forwarding Delay.  
                      
          The average Forwarding Delay is computed by averaging all 
          the Instantaneous Delay Vectors for a given stream. 
           
          Average Delay Vector is a per-hop measurement.  The DUT/SUT 
          MAY remark the specific DSCP or IP precedence value for a 
          multi-hop measurement.  The stream remains the same.
           
          Average Delay Vector can be obtained at any offered load.  
          Recommend at or below the Forwarding Capacity in the 
          absence of congestion.  For congested Forwarding Delay, run 
          the offered load above the Forwarding Capacity. 
           
        Measurement Units: 
          milliseconds
      
        See Also: 
          Classification
          Stream
          Forwarding Capacity
          Forwarding Delay 
          Intended Vector 
          Offered Vector 
          Expected Delay Vector
          Instantaneous Delay Vector       

Perser, Poretsky, Khurana, Erramilli                         [Page 25] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
     3.4.4.6 Maximum Delay Vector 
        Definition: 
          The maximum Forwarding Delay for packets in a stream 
          matching a specific classification, such as DSCP, that 
          a DUT/SUT is measured to successfully transmit to the 
          correct destination interface in response to an offered 
          vector. 
      
        Discussion: 
          Maximum Delay Vector is expressed as combination of values:  
          the classification rules AND maximum Forwarding Delay.  
                      
          The maximum Forwarding Delay is computed by selecting the 
          highest value from the Instantaneous Delay Vectors for a 
          given stream. 
           
          Maximum Delay Vector is a per-hop measurement.  The DUT/SUT 
          MAY remark the specific DSCP or IP precedence value for a 
          multi-hop measurement.  The stream remains the same.
           
          Maximum Delay Vector can be obtained at any offered load.  
          Recommend at or below the Forwarding Capacity in the 
          absence of congestion.  For congested Forwarding Delay, run 
          the offered load above the Forwarding Capacity. 
           
        Measurement Units: 
          milliseconds
      
        See Also: 
          Classification
          Stream
          Forwarding Capacity
          Forwarding Delay 
          Intended Vector 
          Offered Vector 
          Expected Delay Vector
          Instantaneous Delay Vector 
   
     3.4.4.7 Minimum Delay Vector 
        Definition: 
          The minimum Forwarding Delay for packets in a stream 
          matching a specific classification, such as DSCP, that 
          a DUT/SUT is measured to successfully transmit to the 
          correct destination interface in response to an offered 
          vector. 
      
        Discussion: 
          Minimum Delay Vector is expressed as a combination of 
          values:  the classification rules AND maximum Forwarding 
          Delay.  The minimum Forwarding Delay is computed by 
          selecting the highest value from the Instantaneous Delay 
          Vectors for a given stream. 
           
Perser, Poretsky, Khurana, Erramilli                         [Page 26] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 

          Minimum Delay Vector is a per-hop measurement.  The DUT/SUT 
          MAY remark the specific DSCP or IP precedence value for a 
          multi-hop measurement.  The stream remains the same.
           
          Minimum Delay Vector can be obtained at any offered load.  
          Recommend at or below the Forwarding Capacity in the 
          absence of congestion.  For congested Forwarding Delay, run 
          the offered load above the Forwarding Capacity. 
           
        Measurement Units: 
          milliseconds
      
        See Also: 
          Classification
          Stream
          Forwarding Capacity
          Forwarding Delay 
          Intended Vector 
          Offered Vector 
          Expected Delay Vector
     
     3.4.4.8 Instantaneous Jitter Vector 
        Definition: 
          The jitter for two consecutive packets in a 
          stream matching a specific classification, such as DSCP, 
          that a DUT/SUT is measured to successfully transmit to the 
          correct destination interface in response to an offered 
          vector. 
   
        Discussion: 
          Instantaneous Jitter is the absolute value of the difference 
          between the Forwarding Delay measurement of two packets 
          belonging to the same stream. 
           
          Jitter vector is expressed as pair of numbers.  Both the 
          specific DSCP (or IP precedence) value AND jitter value 
          combine to make a vector. 
           
          The Forwarding Delay fluctuation between two consecutive 
          packets in a stream is reported as the "Instantaneous Jitter".  
          Instantaneous Jitter Vector can be expressed as 
          |D(i) - D(i-1)| where D equals the Forwarding Delay and i is 
          the test sequence number.  Packets lost are not counted in 
          the measurement. 

          Instantaneous Jitter Vector is a per-hop measurement.  The 
          DUT/SUT MAY remark the specific DSCP or IP precedence value 
          for a multi-hop measurement.  The stream remains the same.

          There may be several Instantaneous Jitter Vectors for a 
          single stream.  For n packets measured, there may be (n-1) 
          Instantaneous Jitter Vectors. 

Perser, Poretsky, Khurana, Erramilli                         [Page 27] 

INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
      
        Measurement units: 
          milliseconds
      
        See Also: 
          Classification 
          Stream 
          Forwarding Delay 
          Jitter 
          Forwarding Vector 
          Expected Vectors 

     3.4.4.9 Average Jitter Vector 
      
        Definition: 
          The average jitter for packets in a stream matching a 
          specific classification, such as DSCP, that a DUT/SUT is 
          measured to successfully transmit to the correct 
          destination interface in response to an offered vector. 
      
        Discussion: 
          Average jitter is calculated by the average of all the 
          Instantaneous Jitter Vectors of the same stream measured 
          during the test duration. Average Jitter Vector is 
          expressed as a combination of values:  the 
          classification rules AND average Jitter.
           
          Average Jitter vector is a per-hop measurement.  The 
          DUT/SUT MAY remark the specific DSCP or IP precedence value 
          for a multi-hop measurement.  The stream remains the same.
           
        Measurement units: 
          milliseconds 
      
        See Also: 
          Classification 
          Stream 
          Jitter 
          Forwarding Vector 
          Expected Vector 
          Instantaneous Jitter Vector 
 
     3.4.4.10 Peak-to-peak Jitter Vector 
      
        Definition: 
          The maximum possible variation in the Forwarding Delay for 
          packets in a stream matching a specific classification, 
          such as DSCP, that a DUT/SUT is measured to successfully 
          transmit to the correct destination interface in response 
          to an offered vector. 
      
Perser, Poretsky, Khurana, Erramilli                         [Page 28] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 

        Discussion: 
          Peak-to-peak Jitter Vector is calculated by subtracting 
          the maximum Forwarding Delay from the minimum Forwarding 
          Delay of the packets forwarded by the DUT/SUT. Jitter 
          vector is expressed as a combination of values:  the 
          classification rules AND peak-to-peak Jitter.
           
          Peak-to-peak Jitter is not derived from the Instantaneous 
          Jitter Vector.  Peak-to-peak Jitter is based upon all the 
          packets during the test duration, not just two consecutive 
          packets. 
           
        Measurement units: 
          milliseconds
      
        See Also: 
          Jitter 
          Forwarding Vector 
          Stream 
          Expected Vectors 
          Instantaneous Jitter Vector 
          Average Jitter Vector 
   
4. IANA Considerations

   This document requires no IANA considerations.

5. Security Considerations 
           
          Documents of this type do not directly affect the security of 
          the Internet or of corporate networks as long as benchmarking 
          is not performed on devices or systems connected to 
          production networks. 
           
          Packets with unintended and/or unauthorized DSCP or IP 
          precedence values may present security issues.  Determining 
          the security consequences of such packets is out of scope for 
          this document. 
      
6. Acknowledgments 
   
          The authors gratefully acknowledge the contributions of the 
          IETF's benchmarking working group members in reviewing this 
          document.  The authors would like to express our thanks to 
          David Newman for his consistent and valuable assistance 
          throughout the development of this document.  The authors
          would also like to thank Al Morton (acmorton@att.com) and 
          Kevin Dubray (kdubray@juniper.net) for their ideas and 
          support. 

Perser, Poretsky, Khurana, Erramilli                         [Page 29] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 

7. References
7.1 Normative References   
       [Br91] Bradner, S., "Benchmarking Terminology for Network 
              Interconnection Devices", RFC 1242, July 1991. 
      
       [Br97] Bradner, S., "Key words for use in RFCs to Indicate 
              Requirement Levels", RFC 2119, March 1997 
      
       [Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
              Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
              Minshall, G., Partridge, C., Peterson, L., Ramakrishnan,
              K., Shenker, S., Wroclawski, J. and L. Zhang,
              "Recommendations on Queue Management and Congestion
              Avoidance in the Internet", RFC 2309, April 1998.

       [Ma98] Mandeville, R., "Benchmarking Terminology for LAN  
              Switching Devices", RFC 2285, July 1998. 
      
       [Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 
              of the Differentiated Services Field (DS Field) in the 
              IPv4 and IPv6 Headers", RFC 2474, December 1998. 
      
       [St91] Steinberg, L., "Techniques for Managing Asynchronously 
              Generated Alerts", RC 1224, May 1991.
   
7.2 Informative References       
       [Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay 
              Metric for IPPM", RFC 2679, September 1999 
      
       [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 
              Weiss, W., "An Architecture for Differentiated Services",  
              RFC 2475, December 1998. 
      
       [Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for 
              Network Interconnect Devices", RFC 2544, March 1999 
      
       [De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation 
              Metric for IPPM", RFC 3393, November 2002 
      
       [Ec98] http://www3.ietf.org/proceedings/98mar/
              98mar-edited-135.htm

       [Fl93] Floyd, S., and Jacobson, V., "Random Early Detection
              gateways for Congestion Avoidance", IEEE/ACM
              Transactions on Networking, V.1 N.4, August 1993, p.
              397-413.  URL "ftp://ftp.ee.lbl.gov/papers/early.pdf".

       [Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited 
              Forwarding PHB", RFC 2598, June 1999 
      
       [Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 
              Packet Loss Metric for IPPM", RFC 2680, September 1999 
      
Perser, Poretsky, Khurana, Erramilli                         [Page 30] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms

       [Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control 
              Survey", RFC 1254, August 1991 
      
       [Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for 
              LAN Switching Devices", RFC 2889, August 2000 

       [Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 
              S., Perser, J., "Packet Reordering Metric for IPPM", 
              Work in Progress 
      
       [Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", 
              RFC 896, January 1984. 
      
       [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add 
              Explicit Congestion Notification (ECN) to IP", RFC 2481, 
              January 1999. 
      
       [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 
              "RTP: A Transport Protocol for Real-Time Applications", 
              RFC 1889, January 1996  

8. Authors' Addresses 
           
          Jerry Perser 
          Veriwave
          USA   
          EMail: jperser@veriwave.com 
            
          Scott Poretsky 
          Reef Point Systems 
          8 New England Executive Park 
          Burlington, MA 01803 
          USA 
          Phone: + 1 508 439 9008 
          EMail: sporetsky@reefpoint.com 
           
          Shobha Erramilli 
          Telcordia Technologies
          331 Newman Springs Road
          Red Bank, New Jersey 07701
          USA
          Email: shobha@research.telcordia.com
           
          Sumit Khurana 
          Telcordia Technologies 
          445 South Street 
          Morristown, NJ 07960 
          USA  
          Phone: + 1 973 829 3170 
          EMail: sumit@research.telcordia.com 

Perser, Poretsky, Khurana, Erramilli                         [Page 31] 
   
INTERNET-DRAFT       Terminology for Benchmarking         June 2006 
                 Network-layer Traffic Control Mechanisms 
   
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement
   Funding for the RFC Editor function is currently provided by the
   Internet Society.






Perser, Poretsky, Khurana, Erramilli                         [Page 32]