<pre>Network Working Group                                        S. Poretsky
Request for Comments: 4689                            Reef Point Systems
Category: Informational                                        J. Perser
                                                                Veriwave
                                                            S. Erramilli
                                                               Telcordia
                                                              S. Khurana
                                                                Motorola
                                                            October 2006


 <span class="h1">Terminology for Benchmarking Network-layer Traffic Control Mechanisms</span>

Status of This Memo

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

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 the Differentiated Services Code Point (DSCP), or any
   field in the packet payload, such as port number.



















<span class="grey">Poretsky, et al.             Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
   <a href="#section-2">2</a>. Existing Definitions ............................................<a href="#page-3">3</a>
   <a href="#section-3">3</a>. Term Definitions ................................................<a href="#page-4">4</a>
      <a href="#section-3.1">3.1</a>. Configuration Terms ........................................<a href="#page-4">4</a>
           <a href="#section-3.1.1">3.1.1</a>. Classification ......................................<a href="#page-4">4</a>
           <a href="#section-3.1.2">3.1.2</a>. Codepoint Set .......................................<a href="#page-4">4</a>
           <a href="#section-3.1.3">3.1.3</a>. Forwarding Congestion ...............................<a href="#page-5">5</a>
           <a href="#section-3.1.4">3.1.4</a>. Congestion Management ...............................<a href="#page-6">6</a>
           <a href="#section-3.1.5">3.1.5</a>. Flow ................................................<a href="#page-7">7</a>
      <a href="#section-3.2">3.2</a>. Measurement Terms ..........................................<a href="#page-7">7</a>
           <a href="#section-3.2.1">3.2.1</a>. Forwarding Capacity .................................<a href="#page-7">7</a>
           <a href="#section-3.2.2">3.2.2</a>. Conforming Packet ...................................<a href="#page-8">8</a>
           <a href="#section-3.2.3">3.2.3</a>. Nonconforming Packet ................................<a href="#page-9">9</a>
           <a href="#section-3.2.4">3.2.4</a>. Forwarding Delay ....................................<a href="#page-9">9</a>
           <a href="#section-3.2.5">3.2.5</a>. Jitter .............................................<a href="#page-11">11</a>
           <a href="#section-3.2.6">3.2.6</a>. Undifferentiated Response ..........................<a href="#page-11">11</a>
      <a href="#section-3.3">3.3</a>. Sequence Tracking .........................................<a href="#page-12">12</a>
           <a href="#section-3.3.1">3.3.1</a>. Test Sequence Number ...............................<a href="#page-12">12</a>
           <a href="#section-3.3.2">3.3.2</a>. Stream .............................................<a href="#page-12">12</a>
           <a href="#section-3.3.3">3.3.3</a>. In-Sequence Packet .................................<a href="#page-13">13</a>
           <a href="#section-3.3.4">3.3.4</a>. Out-of-Order Packet ................................<a href="#page-14">14</a>
           <a href="#section-3.3.5">3.3.5</a>. Duplicate Packet ...................................<a href="#page-14">14</a>
      <a href="#section-3.4">3.4</a>. Vectors ...................................................<a href="#page-15">15</a>
           <a href="#section-3.4.1">3.4.1</a>. Intended Vector ....................................<a href="#page-15">15</a>
           <a href="#section-3.4.2">3.4.2</a>. Offered Vector .....................................<a href="#page-16">16</a>
           <a href="#section-3.4.3">3.4.3</a>. Expected Vectors ...................................<a href="#page-16">16</a>
           <a href="#section-3.4.4">3.4.4</a>. Output Vectors .....................................<a href="#page-23">23</a>
   <a href="#section-4">4</a>. Security Considerations ........................................<a href="#page-30">30</a>
   <a href="#section-5">5</a>. Acknowledgements ...............................................<a href="#page-30">30</a>
   <a href="#section-6">6</a>. References .....................................................<a href="#page-31">31</a>
      <a href="#section-6.1">6.1</a>. Normative References ......................................<a href="#page-31">31</a>
      <a href="#section-6.2">6.2</a>. Informative References ....................................<a href="#page-31">31</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   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 and ingress of a device/system
   under test.  Again, the existence of congestion requires the addition
   of egress measurements, as well as of 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.



<span class="grey">Poretsky, et al.             Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   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.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Existing Definitions</span>

   <a href="./rfc1224">RFC 1224</a>, "Techniques for Managing Asynchronously Generated Alerts"
   [<a href="#ref-St91" title="&quot;Techniques for managing asynchronously generated alerts&quot;">St91</a>], is used for 'Time with fine enough units to distinguish
   between two events'.

   <a href="./rfc1242">RFC 1242</a>, "Benchmarking Terminology for Network Interconnect
   Devices", and <a href="./rfc2285">RFC 2285</a>, "Benchmarking Terminology for LAN Switching
   Devices", should be consulted before attempting to make use of this
   document.

   <a href="./rfc2474">RFC 2474</a>, "Definition of the Differentiated Services Field (DS Field)
   in the IPv4 and IPv6 Headers", <a href="#section-2">section 2</a>, 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 <a href="./rfc1242#section-2">Section&nbsp;2 of RFC 1242</a>.  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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>
   [<a href="#ref-Br97" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">Br97</a>].  <a href="./rfc2119">RFC 2119</a> 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.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Frequently Used Acronyms</span>

   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





<span class="grey">Poretsky, et al.             Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Term Definitions</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Configuration Terms</span>

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  Classification</span>

   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 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 on fields in the packet
      payload, such as port number.  Classification can also be based on
      ingress interface.  It is possible to base classification on
      Multi-Field (MF) criteria such as IP source and destination
      addresses, protocol, and port number.  For further discussion of
      packet classification and its network applications, see [<a href="#ref-Bl98" title="&quot;An Architecture for Differentiated Service&quot;">Bl98</a>].

   Measurement units:
      n/a

   See Also:
      None

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  Codepoint Set</span>

   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.




<span class="grey">Poretsky, et al.             Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   Measurement Units:
      n/a

   See Also:
      None

<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>.  Forwarding Congestion</span>

   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 [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>].
      Overload [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>] 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 an
      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 [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>] 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 [<a href="#ref-Fl93" title="&quot;Random Early Detection gateways for Congestion Avoidance&quot;">Fl93</a>].  As
      stated in [<a href="#ref-Ec98">Ec98</a>], RED [<a href="#ref-Br98" title="&quot;Recommendations on Queue Management and Congestion Avoidance in the Internet&quot;">Br98</a>] 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.  [<a href="#ref-Ra99" title="&quot;The Addition of Explicit Congestion Notification (ECN) to IP&quot;">Ra99</a>] implies that it is impractical to build
      a black-box test to observe Incipient Congestion.  [<a href="#ref-Ra99" title="&quot;The Addition of Explicit Congestion Notification (ECN) to IP&quot;">Ra99</a>] instead
      introduces Explicit Congestion Notification (ECN) as a
      deterministic Black-Box method for observing Incipient Congestion.
      [<a href="#ref-Ra99" title="&quot;The Addition of Explicit Congestion Notification (ECN) to IP&quot;">Ra99</a>] is an Experimental RFC with limited deployment, so ECN is
      not used for this particular methodology.  For the purpose of



<span class="grey">Poretsky, et al.             Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


      "black-box" testing a DUT/SUT, this methodology uses Packet Loss
      as the indicator of Forwarding Congestion.

      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 [<a href="#ref-Na84" title="&quot;Congestion control in IP/TCP internetworks&quot;">Na84</a>] 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 [<a href="#ref-Ma91" title="&quot;Gateway Congestion Control Survey&quot;">Ma91</a>]

<span class="h4"><a class="selflink" id="section-3.1.4" href="#section-3.1.4">3.1.4</a>.  Congestion Management</span>

   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



<span class="grey">Poretsky, et al.             Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


<span class="h4"><a class="selflink" id="section-3.1.5" href="#section-3.1.5">3.1.5</a>.  Flow</span>

   Definition:
      A flow is one or more 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 [<a href="#ref-Ni98" title="&quot;Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers&quot;">Ni98</a>] are a subset of flows.  As defined in [<a href="#ref-Ni98" title="&quot;Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers&quot;">Ni98</a>],
      microflows require application-to-application measurement.  In
      contrast, flows use lower-layer classification criteria.  Since
      this document focuses on network-layer classification criteria, it
      concentrates 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 [<a href="#ref-Ni98" title="&quot;Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers&quot;">Ni98</a>]
      Streams

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Measurement Terms</span>

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Forwarding Capacity</span>

   Definition:
      The number of packets per second that a device can be observed to
      transmit successfully to the correct egress interface in response
      to a specified offered load while the device drops none of the
      offered packets.






<span class="grey">Poretsky, et al.             Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   Discussion:
      Forwarding Capacity measures the packet rate at the egress
      interface(s) of the DUT/SUT.  In contrast, throughput (as defined
      in <a href="./rfc1242">RFC 1242</a>) measures the packet rate at the ingress interface(s)
      of the DUT/SUT.

      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) [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>] in that the Forwarding Capacity requires zero
      loss.

   Measurement units:
      N-octet packets per second

   See Also:
      Throughput [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>]
      Forwarding Rate at Maximum Offered Load [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>]

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Conforming Packet</span>

   Definition:
      Packets that 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






<span class="grey">Poretsky, et al.             Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   See Also:
      Expected Vector
      Forwarding Vector
      Offered Vector
      Nonconforming

<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>.  Nonconforming Packet</span>

   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

<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>.  Forwarding Delay</span>

   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 [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>] and one-way delay
      [<a href="#ref-Al99" title="&quot;A One-way Delay Metric for IPPM&quot;">Al99</a>] in several key regards:

      1. Latency [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>] 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.




<span class="grey">Poretsky, et al.             Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


      2. Forwarding Delay is a last-in, last-out (LILO) measurement,
         unlike the last-in, first-out method [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>] or the first-in,
         last-out method [<a href="#ref-Al99" title="&quot;A One-way Delay Metric for IPPM&quot;">Al99</a>].

         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.

         Further, the LILO method has an additive property, where the
         sum of the parts MUST equal the whole.  This is a key
         difference from [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>] and [<a href="#ref-Al99" title="&quot;A One-way Delay Metric for IPPM&quot;">Al99</a>].  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 [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>] and [<a href="#ref-Al99" title="&quot;A One-way Delay Metric for IPPM&quot;">Al99</a>].

      3. Forwarding Delay measures the IP datagram only, unlike [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>],
         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 [<a href="#ref-Br99" title="&quot;Benchmarking Methodology for Network Interconnect Devices&quot;">Br99</a>] 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
         the 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 the
         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






<span class="grey">Poretsky, et al.             Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   See Also:
      Latency [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>]
      Latency [<a href="#ref-Al99" title="&quot;A One-way Delay Metric for IPPM&quot;">Al99</a>]
      One-way Delay [<a href="#ref-Br99" title="&quot;Benchmarking Methodology for Network Interconnect Devices&quot;">Br99</a>]

<span class="h4"><a class="selflink" id="section-3.2.5" href="#section-3.2.5">3.2.5</a>.  Jitter</span>

   Definition:
      The absolute value of the difference between the Forwarding 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 independently of
      packet loss.

      Jitter is related to the IPDV [<a href="#ref-De02" title="&quot;IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)&quot;">De02</a>] (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 [<a href="#ref-Ja99" title="&quot;An Expedited Forwarding PHB (Per-Hop Behavior)&quot;">Ja99</a>]
      ipdv [<a href="#ref-De02" title="&quot;IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)&quot;">De02</a>]
      interarrival jitter [<a href="#ref-Sc96" title="&quot;RTP: A Transport Protocol for Real-Time Applications&quot;">Sc96</a>]

<span class="h4"><a class="selflink" id="section-3.2.6" href="#section-3.2.6">3.2.6</a>.  Undifferentiated Response</span>

   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,



<span class="grey">Poretsky, et al.             Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


      the best-effort class, is offered to the device.  Measurements
      with "undifferentiated response" SHOULD be made to establish a
      baseline.

      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

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Sequence Tracking</span>

<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>.  Test Sequence Number</span>

   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.  Upon
      receipt of the packet,  the traffic receiver checks the value.
      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 the number of received packets,
      the traffic receiver may also report the number of in-sequence
      packets, the number of out-of-sequence packets, the number of
      duplicate packets, and the number of reordered packets.  The
      RECOMMENDED algorithm to change the sequence number on sequential
      packets is an incrementing value.

   Measurement units:
      n/a

   See Also:
      Stream

<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>.  Stream</span>

   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.






<span class="grey">Poretsky, et al.             Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   Discussion:
      Streams are tracked by test sequence number or "unique signature
      field" [<a href="#ref-Ma00" title="&quot;Benchmarking Methodology for LAN Switching Devices&quot;">Ma00</a>].  Streams define how individual packet statistics
      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 [<a href="#ref-Ni98" title="&quot;Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers&quot;">Ni98</a>]
      Test sequence number

<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>.  In-Sequence Packet</span>

   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 packet's 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






<span class="grey">Poretsky, et al.             Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   See Also:
      Stream
      Test Sequence number

<span class="h4"><a class="selflink" id="section-3.3.4" href="#section-3.3.4">3.3.4</a>.  Out-of-Order Packet</span>

   Definition:
      A received packet with a sequence number less than the sequence
      number of any previously arriving packet.

   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 reordered is counted as
      an Out-of-Order Packet.

      Certain streaming protocols (such as TCP) require the packets to
      be in a certain order.  Packets outside this are dropped by the
      streaming protocols even though they 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.  The
      Out-of-Order Packet count is impacted only by 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 [<a href="#ref-Mo03" title="&quot;Packet Reordering Metric for IPPM&quot;">Mo03</a>]

<span class="h4"><a class="selflink" id="section-3.3.5" href="#section-3.3.5">3.3.5</a>.  Duplicate Packet</span>

   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.





<span class="grey">Poretsky, et al.             Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


      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.

      To detect a Duplicate Packet, each packet offered to the DUT/SUT
      MUST contain a unique packet-by-packet identifier.

   Measurement units:
      Packet count

   See Also:
      Stream
      Test Sequence number

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Vectors</span>

   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.

<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>.  Intended Vector</span>

   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







<span class="grey">Poretsky, et al.             Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   See Also:
      Stream
      Offered Vector
      Forwarding Vector

<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>.  Offered Vector</span>

   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

<span class="h4"><a class="selflink" id="section-3.4.3" href="#section-3.4.3">3.4.3</a>.  Expected Vectors</span>

<span class="h5"><a class="selflink" id="section-3.4.3.1" href="#section-3.4.3.1">3.4.3.1</a>.  Expected Forwarding Vector</span>

   Definition:
      A description of the expected output rate of packets matching a
      specific classification, such as DSCP.

   Discussion:
      The value of the Expected Forwarding Vector is dependent on the
      set of offered vectors and Classification configuration on the
      DUT/SUT.  The DUT is configured in a certain way so 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 is not important when describing the
      Expected Forwarding Vector.

   Measurement units:
      N-octet packets per second




<span class="grey">Poretsky, et al.             Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   See Also:
      Classification
      Stream
      Intended Vector
      Offered Vector

<span class="h5"><a class="selflink" id="section-3.4.3.2" href="#section-3.4.3.2">3.4.3.2</a>.  Expected Loss Vector</span>

   Definition:
      A description of the percentage of packets having a specific
      classification that should not be forwarded.

   Discussion:
      The value of the Expected Loss Vector is dependent on the set of
      offered vectors and Classification configuration on the DUT/SUT.
      The DUT is configured in a certain way so 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 is not important when describing the
      Expected Loss Vector.

   Measurement Units:
      Percentage of intended packets expected to be dropped.

   See Also:
      Classification
      Stream
      Intended Vector
      Offered Vector
      One-way Packet Loss Metric [<a href="#ref-Ka99" title="&quot;A One-way Packet Loss Metric for IPPM&quot;">Ka99</a>]

<span class="h5"><a class="selflink" id="section-3.4.3.3" href="#section-3.4.3.3">3.4.3.3</a>.  Expected Sequence Vector</span>

   Definition:
      A description of the expected in-sequence packets matching a
      specific classification, such as DSCP.

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




<span class="grey">Poretsky, et al.             Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


      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 is not important when describing the
      Expected Sequence Vector.

   Measurement Units:
      N-octet packets per second

   See Also:
      Classification
      Stream
      In-Sequence Packet
      Intended Vector
      Offered Vector

<span class="h5"><a class="selflink" id="section-3.4.3.4" href="#section-3.4.3.4">3.4.3.4</a>.  Expected Delay Vector</span>

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

   Discussion:
      The value of the Expected 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 so 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 is not important when describing the
      Expected Delay Vector.

   Measurement units:
      milliseconds

   See Also:
      Classification
      Stream
      Forwarding Delay
      Intended Vector
      Offered Vector







<span class="grey">Poretsky, et al.             Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


<span class="h5"><a class="selflink" id="section-3.4.3.5" href="#section-3.4.3.5">3.4.3.5</a>.  Expected Average Delay Vector</span>

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

   Discussion:
      The value of the Expected Average 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 so 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 is 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

<span class="h5"><a class="selflink" id="section-3.4.3.6" href="#section-3.4.3.6">3.4.3.6</a>.  Expected Maximum Delay Vector</span>

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

   Discussion:
      The value of the Expected Maximum 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 so 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 is not important when describing the
      Expected Maximum Delay Vector.



<span class="grey">Poretsky, et al.             Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   Measurement units:
      milliseconds

   See Also:
      Classification
      Stream
      Forwarding Delay
      Intended Vector
      Offered Vector
      Expected Delay Vector

<span class="h5"><a class="selflink" id="section-3.4.3.7" href="#section-3.4.3.7">3.4.3.7</a>.  Expected Minimum Delay Vector</span>

   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 so 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 is 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

<span class="h5"><a class="selflink" id="section-3.4.3.8" href="#section-3.4.3.8">3.4.3.8</a>.  Expected Instantaneous Jitter Vector</span>

   Definition:
      A description of the expected Instantaneous Jitter between two
      consecutive packets arrival times matching a specific
      classification, such as DSCP.




<span class="grey">Poretsky, et al.             Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   Discussion:
      Instantaneous Jitter is the absolute value of the difference
      between the Forwarding Delay measurement of two packets belonging
      to the same stream.

      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.

      The 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

<span class="h5"><a class="selflink" id="section-3.4.3.9" href="#section-3.4.3.9">3.4.3.9</a>.  Expected Average Jitter Vector</span>

   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 so 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 is not important when describing the
      Expected Average Jitter Vector.




<span class="grey">Poretsky, et al.             Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   Measurement units:
      milliseconds

   See Also:
      Classification
      Stream
      Jitter
      Intended Vector
      Offered Vector
      Expected Instantaneous Jitter Vector

<span class="h5"><a class="selflink" id="section-3.4.3.10" href="#section-3.4.3.10">3.4.3.10</a>.  Expected Peak-to-peak Jitter Vector</span>

   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 so 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 is not important when describing the
      Expected Peak-to-peak Jitter Vector.

   Measurement units:
      milliseconds










<span class="grey">Poretsky, et al.             Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   See Also:
      Classification
      Stream
      Jitter
      Intended Vector
      Offered Vector
      Expected Instantaneous Jitter Vector
      Expected Average Jitter Vector

<span class="h4"><a class="selflink" id="section-3.4.4" href="#section-3.4.4">3.4.4</a>.  Output Vectors</span>

<span class="h5"><a class="selflink" id="section-3.4.4.1" href="#section-3.4.4.1">3.4.4.1</a>.  Forwarding Vector</span>

   Definition:
      The number of packets per second for a stream matching a specific
      classification, such as DSCP, that a DUT/SUT is measured to
      forward to the correct destination interface successfully 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

<span class="h5"><a class="selflink" id="section-3.4.4.2" href="#section-3.4.4.2">3.4.4.2</a>.  Loss Vector</span>

   Definition:
      The percentage of packets per second for a stream matching a
      specific classification, such as DSCP, that a DUT/SUT is measured
      not to transmit to the correct destination interface in response
      to an offered vector.






<span class="grey">Poretsky, et al.             Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   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 [<a href="#ref-Ka99" title="&quot;A One-way Packet Loss Metric for IPPM&quot;">Ka99</a>]

<span class="h5"><a class="selflink" id="section-3.4.4.3" href="#section-3.4.4.3">3.4.4.3</a>.  Sequence Vector</span>

   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






<span class="grey">Poretsky, et al.             Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


<span class="h5"><a class="selflink" id="section-3.4.4.4" href="#section-3.4.4.4">3.4.4.4</a>.  Instantaneous Delay Vector</span>

   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 transmit to the correct destination interface
      successfully 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 that this vector be obtained at or below the
      Forwarding Capacity in the absence of Forwarding 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

<span class="h5"><a class="selflink" id="section-3.4.4.5" href="#section-3.4.4.5">3.4.4.5</a>.  Average Delay Vector</span>

   Definition:
      The average Forwarding Delay for packets in a stream matching a
      specific classification, such as DSCP, that a DUT/SUT is measured
      to transmit to the correct destination interface successfully in
      response to an offered vector.








<span class="grey">Poretsky, et al.             Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   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.  It is
      recommended that the offered load be 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

<span class="h5"><a class="selflink" id="section-3.4.4.6" href="#section-3.4.4.6">3.4.4.6</a>.  Maximum Delay Vector</span>

   Definition:
      The maximum Forwarding Delay for packets in a stream matching a
      specific classification, such as DSCP, that a DUT/SUT is measured
      to transmit to the correct destination interface successfully 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.




<span class="grey">Poretsky, et al.             Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


      Maximum Delay Vector can be obtained at any offered load.  It is
      recommended that the offered load be 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

<span class="h5"><a class="selflink" id="section-3.4.4.7" href="#section-3.4.4.7">3.4.4.7</a>.  Minimum Delay Vector</span>

   Definition:
      The minimum Forwarding Delay for packets in a stream matching a
      specific classification, such as DSCP, that a DUT/SUT is measured
      to transmit to the correct destination interface successfully in
      response to an offered vector.

   Discussion:
      Minimum Delay Vector is expressed as a combination of values: the
      classification rules AND minimum Forwarding Delay.  The minimum
      Forwarding Delay is computed by selecting the lowest value from
      the Instantaneous Delay Vectors for a given stream.

      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.  It is
      recommended that the offered load be 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








<span class="grey">Poretsky, et al.             Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   See Also:
      Classification
      Stream
      Forwarding Capacity
      Forwarding Delay
      Intended Vector
      Offered Vector
      Expected Delay Vector

<span class="h5"><a class="selflink" id="section-3.4.4.8" href="#section-3.4.4.8">3.4.4.8</a>.  Instantaneous Jitter Vector</span>

   Definition:
      The jitter for two consecutive packets in a stream matching a
      specific classification, such as DSCP, that a DUT/SUT is measured
      to transmit to the correct destination interface successfully 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.

      The Instantaneous Jitter vector is expressed as a 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.

      The 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.

   Measurement units:
      milliseconds









<span class="grey">Poretsky, et al.             Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   See Also:
      Classification
      Stream
      Forwarding Delay
      Jitter
      Forwarding Vector
      Expected Vectors

<span class="h5"><a class="selflink" id="section-3.4.4.9" href="#section-3.4.4.9">3.4.4.9</a>.  Average Jitter Vector</span>

   Definition:
      The average jitter for packets in a stream matching a specific
      classification, such as DSCP, that a DUT/SUT is measured to
      transmit to the correct destination interface successfully 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

<span class="h5"><a class="selflink" id="section-3.4.4.10" href="#section-3.4.4.10">3.4.4.10</a>.  Peak-to-peak Jitter Vector</span>

   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 transmit to the correct destination
      interface successfully in response to an offered vector.






<span class="grey">Poretsky, et al.             Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   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

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Security Considerations</span>

   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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Acknowledgements</span>

   The authors gratefully acknowledge the contributions of the IETF's
   Benchmarking Methodology 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 and Kevin Dubray for their ideas and support.











<span class="grey">Poretsky, et al.             Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  References</span>

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Normative References</span>

   [<a id="ref-Br91">Br91</a>] Bradner, S., "Benchmarking terminology for network
          interconnection devices", <a href="./rfc1242">RFC 1242</a>, July 1991.

   [<a id="ref-Br97">Br97</a>] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-Br98">Br98</a>] 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", <a href="./rfc2309">RFC 2309</a>, April 1998.

   [<a id="ref-Ma98">Ma98</a>] Mandeville, R., "Benchmarking Terminology for LAN Switching
          Devices", <a href="./rfc2285">RFC 2285</a>, February 1998.

   [<a id="ref-Ni98">Ni98</a>] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition
          of the Differentiated Services Field (DS Field) in the IPv4
          and IPv6 Headers", <a href="./rfc2474">RFC 2474</a>, December 1998.

   [<a id="ref-St91">St91</a>] Steinberg, L., "Techniques for managing asynchronously
          generated alerts", <a href="./rfc1224">RFC 1224</a>, May 1991.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Informative References</span>

   [<a id="ref-Al99">Al99</a>] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay
          Metric for IPPM", <a href="./rfc2679">RFC 2679</a>, September 1999.

   [<a id="ref-Bl98">Bl98</a>] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and
          W. Weiss, "An Architecture for Differentiated Service", <a href="./rfc2475">RFC</a>
          <a href="./rfc2475">2475</a>, December 1998.

   [<a id="ref-Br99">Br99</a>] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
          Network Interconnect Devices", <a href="./rfc2544">RFC 2544</a>, March 1999.

   [<a id="ref-De02">De02</a>] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
          Metric for IP Performance Metrics (IPPM)", <a href="./rfc3393">RFC 3393</a>, November
          2002.

   [<a id="ref-Ec98">Ec98</a>] <a href="http://www3.ietf.org/proceedings/98mar/98mar-edited-135.htm">http://www3.ietf.org/proceedings/98mar/98mar-edited-135.htm</a>

   [<a id="ref-Fl93">Fl93</a>] 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
          "<a href="ftp://ftp.ee.lbl.gov/papers/early.pdf">ftp://ftp.ee.lbl.gov/papers/early.pdf</a>".



<span class="grey">Poretsky, et al.             Informational                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


   [<a id="ref-Ja99">Ja99</a>] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec,
          J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis,
          "An Expedited Forwarding PHB (Per-Hop Behavior)", <a href="./rfc3246">RFC 3246</a>,
          March 2002.

   [<a id="ref-Ka99">Ka99</a>] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet
          Loss Metric for IPPM", <a href="./rfc2680">RFC 2680</a>, September 1999.

   [<a id="ref-Ma91">Ma91</a>] Mankin, A. and K. Ramakrishnan, "Gateway Congestion Control
          Survey", <a href="./rfc1254">RFC 1254</a>, August 1991.

   [<a id="ref-Ma00">Ma00</a>] Mandeville, R. and J. Perser, "Benchmarking Methodology for
          LAN Switching Devices", <a href="./rfc2889">RFC 2889</a>, August 2000.

   [<a id="ref-Mo03">Mo03</a>] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.,
          Perser, J., "Packet Reordering Metric for IPPM", Work in
          Progress.

   [<a id="ref-Na84">Na84</a>] Nagle, J., "Congestion control in IP/TCP internetworks", <a href="./rfc896">RFC</a>
          <a href="./rfc896">896</a>, January 1984.

   [<a id="ref-Ra99">Ra99</a>] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
          Explicit Congestion Notification (ECN) to IP", <a href="./rfc3168">RFC 3168</a>,
          September 2001.

   [<a id="ref-Sc96">Sc96</a>] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
          "RTP: A Transport Protocol for Real-Time Applications", STD
          64, <a href="./rfc3550">RFC 3550</a>, July 2003.























<span class="grey">Poretsky, et al.             Informational                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


Authors' Addresses

   Jerry Perser
   Veriwave
   8770 SW Nimbus Ave.
   Suite B
   Beaverton, OR 97008   USA
   USA

   Phone: + 1 818 338 4112
   EMail: jerry@perser.org


   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
   Motorola
   7700 West Parmer Ln.
   Austin, TX 78729
   USA

   Phone: +1 512 996 6604
   Email: skhurana@motorola.com











<span class="grey">Poretsky, et al.             Informational                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc4689">RFC 4689</a>       Terminology for Traffic Control Mechanisms   October 2006</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   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
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   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 provided by the IETF
   Administrative Support Activity (IASA).







Poretsky, et al.             Informational                     [Page 34]
</pre>