Network Working Group                           Jerry Perser
     INTERNET-DRAFT                                  Spirent
     Expires in: December 2001 May 2002                            David Newman
                                                     Network Test
                                                     Sumit Khurana
                                                     Telcordia
                                                     Shobha Erramilli
                                                   Telcordia
                                                     QNetworx
                                                     Scott Poretsky
                                                     Avici Systems
                                                   June
                                                     November 2001

                 Terminology for Benchmarking Network-layer
                         Traffic Control Mechanisms

                       <draft-ietf-bmwg-dsmterm-01.txt>

                      <draft-ietf-bmwg-dsmterm-02.txt>

     Status of this Memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     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.

     Table of Contents

        1. Introduction ...............................................  .............................................. 2
        2. Existing definitions .......................................  ...................................... 3
        3. Term definitions.............................................3 definitions ............................................3
        3.1 Channel Capacity..........................................3
       3.2 Classification............................................4
       3.3 Configuration Terms
          3.1.1 Classification .........................................3
          3.1.2 Codepoint Set.............................................4
       3.4 Conforming................................................5
       3.5 Congestion................................................5
       3.6 Set ..........................................4
          3.1.3 Congestion Management.....................................6
       3.7 Delay.....................................................7
       3.8 Expected Vector...........................................7 .............................................4
          3.1.4 Congestion Management ..................................5
        3.2 Vectors ....................................................6
          3.2.1 Intended Vector ........................................6
                 Network-layer Traffic Control Mechanisms

       3.9 Flow......................................................8
       3.10

          3.2.2 Offered Vector .........................................6
          3.2.3 Expected Vectors
          3.2.3.1 Expected Forwarding Vector .......................................9
       3.11 Jitter...................................................9
       3.12 Nonconforming...........................................10
       3.13 Offered Vector..........................................11
       3.14 Stream..................................................11
       3.15 Tail dropping...........................................12
       3.16 ...........................7
          3.2.3.2 Expected Loss Vector .................................8
          3.2.3.3 Expected Sequence Vector .............................8
          3.2.3.4 Expected Delay Vector ................................9
          3.2.3.5 Expected Jitter Vector ..............................10
          3.2.4 Output Vectors
          3.2.4.1 Forwarding Vector ...................................11
          3.2.4.2 Loss Vector .........................................11
          3.2.4.3 Sequence Vector .....................................12
          3.2.4.4 Delay Vector ........................................13
          3.2.4.5 Jitter Vector .......................................14
        3.3 Measurement Terms
          3.3.1 Channel Capacity ......................................15
          3.3.2 Conforming ............................................15
          3.3.3 Nonconforming .........................................16
          3.3.4 Delay .................................................16
          3.3.5 Flow ..................................................17
          3.3.6 Stream ................................................18
          3.3.7 Test Sequence number....................................12
       3.17 Unburdened Response.....................................13 number ..................................19
          3.3.8 Undifferentiated Response .............................19
        4. Security Considerations.....................................13 Considerations ....................................20
        5. References..................................................14 References .................................................20
        6. Author's Address............................................14 Address ...........................................21
        7. Full Copyright Statement....................................15 Statement ...................................22

     1. Introduction

   Driven by Internet economics, service providers and enterprises
   alike have shown strong interest in adding traffic-control
   capabilities to network devices. These capabilities would enable
   network operators to define and deliver minimum or maximum levels of
   bandwidth, delay, and jitter for multiple classes of traffic.
   Perhaps more importantly, network operators would be able to set
   pricing according to the level of service delivered.

   Networking device manufacturers have responded with a wide variety
   of approaches for controlling network traffic.  While there are
   numerous ˘policy management÷ and ˘quality of service÷ frameworks,
   many of them rely on one of two network-layer mechanisms for the
   actual control of forwarding rate, delay, and jitter. These two
   mechanisms are the IP precedence setting in the IP header and the
   diff-serv code point (DSCP) defined in [3].

     This document describes terminology for the various terms to be used in benchmarking of
     devices that implement traffic control based on IP precedence or
   DSCP
     diff-serv code point criteria. This document

     New terminology is narrowly focused, in that it
   describes only terms for measuring behavior of a device or a group
   of devices using one of these two mechanisms. End-to-end and
   service-level needed because most existing measurements are beyond
     assume the scope absence of this document. 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. New
   terminology is needed because most existing benchmarking terms
   assume the absence of congestion. For example, throughput is one of
   the most widely used measurements ű- yet RFC 1242 defines throughput
   as a rate in the absence of loss. As a result, throughput is not a
   meaningful measurement where congestion exists.

     Another key difference from existing benchmarking 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
               Network-layer Traffic Control Mechanisms on ingress; without observing traffic leaving a device
     device/system it is not possible to say whether traffic-control
     mechanisms effectively dealt with congestion.

     The principal measurements introduced in this document are rate
   vectors, vectors
     for rate, delay, and jitter, all of which can be observed with or
     without congestion of the DUT/SUT.

   2.  Existing definitions

   RFC 1242

                 Network-layer Traffic Control Mechanisms

     This document describes only those terms relevant to measuring
     behavior of a device or a group of devices using one of these two
     mechanisms. End-to-end and service-level measurements are beyond
     the scope of this document.

     2.  Existing definitions

     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
     RFC 2119.

     3. Term definitions

     3.1 Channel Capacity

      Definition:
        The maximum forwarding rate of a link or set of aggregated
        links at which none of the offered packets are dropped by the
        DUT/SUT.

      Discussion:
        Channel capacity measures the data rate at the egress
        interface(s) of the DUT/SUT. In contrast, throughput as defined
        in RFC 1242 measures the data rate is based on the ingress
        interface(s) of the DUT/SUT.

        Ingress-based measurements do not account for congestion of the
        DUT/SUT. Channel capacity, as an egress measurement, does take
        congestion into account.

        Understanding channel capacity is a necessary precursor to any
        measurement involving congestion.  Throughput numbers can be
        higher than channel capacity because of queueing.

               Network-layer Traffic Control Mechanisms

      Measurement units:

         N-octet packets per second

      Issues:

      See Also:
        Throughput [1]

   3.2 Configuration Terms

     3.1.1 Classification

        Definition:
          Selection of packets based on the contents of packet header
          according to defined rules.

        Discussion:
          Packets can be selected based on the DS field or IP
          Precedence in the packet header.  Classification can also be
          based on Multi-Field (MF) criteria such as IP Source and
          destination addresses, protocol and port number.

          Classification determines the per-hop behaviors and traffic
          conditioning functions such as shaping and dropping that are
          to be applied to the packet.

        Measurement units:

                 Network-layer Traffic Control Mechanisms

           n/a

        Issues:

        See Also:
        Rules

   3.3

     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 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
               Network-layer Traffic Control Mechanisms 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:

   3.4 Conforming

      Definition:
        Packets that lie within the bounds specified by a traffic
        profile.

      Discussion:
        Rules may be configured that allow a given traffic class to
        consume only X bit/s of channel capacity and no more.  All
        additional packets are dropped.  All packets that constitute
        the first X bits/s measured over a period of time specified by
        the traffic profile, are then said to be conforming whereas
        those exceeding the bound are non conforming.

        In particular in a congestion scenario, some individual packets
        will be conforming and others will not.

      Measurement units:

         n/a

      Issues:

      See Also:
        Expected Vector
        Forwarding Vector
        Offered Vector

   3.5

     3.1.3 Congestion

        Definition:
          A condition in which one or more egress interfaces are
          offered more packets than can be are forwarded at any given instant.

        Discussion:
          This condition is a superset of the overload definition [2].
        That
          The overload definition assumes the overload congestion is introduced
          strictly by the tester on ingress of a DUT/SUT. That may or
          may not be the case here.

               Network-layer Traffic Control Mechanisms

          Another difference is that with multiple-DUT measurements,
          congestion may occur at multiple points. For example,
          multiple edge devices collectively may congest a core device.
          In contrast, overload [1] deals only with overload on
          ingress.

                 Network-layer Traffic Control Mechanisms

          Ingress observations alone are not sufficient to cover all
          cases in which congestion may occur. A device with an
          infinite amount of memory could buffer an infinite amount of
          packets, and eventually forward all of them. However, these
          packets may or may not be forwarded during the test duration.
          Even though ingress interfaces accept all packets without
          loss, this hypothetical device may still be congested.

          The definition presented here explicitly defines congestion
          as an event observable on egress interfaces. Regardless of
          internal architecture, any device that cannot forward packets
          on one or more egress interfaces is congested.

        Measurement units:

           n/a

        Issues:

        See Also:

   3.6

     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. Such mechanisms classify packets
          based upon IP Precedence or DSCP settings in a packetĂs packet's IP
          header.

          Congestion avoidance mechanisms seek to prevent congestion
          before it actually occurs.

          Congestion control mechanisms gives one or more service
          classes preferential treatment over other classes during
          periods of congestion.

        Measurement units:

           n/a

        Issues:

        See Also:

                 Network-layer Traffic Control Mechanisms

   3.7 Delay

      Definition:
        The time interval starting when the last bit of the input IP
        packets reaches the input port of the DUT/SUT and ending when
        the last bit of the output IP packets is seen on the output
        port of the DUT/SUT.

      Discussion:
        Delay

     3.2 Vectors
          A vector is measured the same regardless of the type of DUT/SUT.
        Latency [1] require some knowledge a group of whether the DUT/SUT is packets all containing a
        "store and forward" specific DSCP
          or IP precedence value.  Vectors are expressed as a "bit forwarding" device.  The fact
        that a DUT/SUT's technology has a lower delay than another
        technology should be visible. pair of
          numbers.  The measurement point at the end is more like the way an
        internet datagram is processed.  An internet datagram first is not
        passed up or down being the stack unless it particular diff-serv value.
          The second is complete.  Completion
        occurs once the last bit of the IP packet has been received.

        Delay can be run at any offered load.  Recommend at or below the channel capacity for non-congested delay.  For congested metric expressed as a rate, loss
          percentage, delay, run the offered load above the channel capacity.

      Measurement units:

         Seconds.

      Issues:

      See Also:

   3.8 Expected or jitter.

     3.2.1 Intended Vector

        Definition:

          A vector describing the expected output rate of at which packets having a
          specific code-point. The value is dependent on code-point (or IP precedence) that an external
          source attempts to transmit to a DUT/SUT.

        Discussion:
          Intended loads across the set of
        offered vectors and configuration of different code-point classes
          determine the DUT.

      Discussion:
        The DUT is configured in metrics associated with a certain way in order that service
        discrimination happens specific code-point
          traffic class.

        Measurement Units:
          N-octets packets per second

        Issues:

        See Also:
          Offered Vector
          Expected Forwarding Vector
          Expected Loss Vector
          Expected Sequence Vector
          Expected Delay Vector
          Expected Jitter Vector
          Forwarding Vector
          Loss Vector

     3.2.2 Offered Vector

        Definition:
          A vector describing the measured rate at which packets having
          a specific DSCP or IP precedence value are offered to the
          DUT/SUT.

        Discussion:
          Offered loads across the different code-point classes,
          constituting a code-point set, determine the metrics
          associated with a specific code-point traffic class.

        Measurement Units:
          N-octets packets per second
                 Network-layer Traffic Control Mechanisms

        Issues:
          Packet size.

        See Also:
          Expected Forwarding Vector
          Expected Loss Vector
          Expected Sequence Vector
          Expected Delay Vector
          Expected Jitter Vector
          Forwarding Vector
          Codepoint Set

     3.2.3 Expected Vectors

     3.2.3.1 Expected Forwarding Vector

        Definition:
          A vector describing the expected output rate of packets
          having a specific DSCP or IP precedence value.  The value is
          dependent on the set of offered vectors and configuration of
          the DUT.

        Discussion:
          The DUT is configured in a certain way in order that service
          differentiation occurs for behavior aggregates when a
          specific traffic mix consisting of multiple behavior
          aggregates is applied. This term attempts to capture the
          expected forwarding behavior, for which the device is
          configured, when subjected to a certain offered load.

               Network-layer Traffic Control Mechanisms

          The actual algorithms or mechanism, that the DUT uses to
          achieve service discrimination, differentiation, is not important in
          describing the expected vector.

        Measurement units:
        N-octets
          N-octet packets per second

        Issues:

        See Also:
        Forwarding
          Intended Vector
          Offered Vector
        Codepoint Set

   3.9 Flow
          Output Vectors
          Expected Loss Vector
          Expected Sequence Vector
          Expected Delay Vector
          Expected Jitter Vector
                 Network-layer Traffic Control Mechanisms

     3.2.3.2 Expected Loss Vector

        Definition:
          A flow is a one or more vector describing the percentage of packets sharing packets, having a common intended
        pair
          specific DSCP or IP precedence value, that should not be
          forwarded.  The value is dependent on the set of source offered
          vectors and destination interfaces.

      Discussion:
        Packets are groups by configuration of the ingress and egress interfaces they
        use on DUT.

        Discussion:
          The DUT is configured in a given DUT/SUT.

        A flow can contain certain way in order that service
          differentiation occurs for behavior aggregates when a
          specific traffic mix consisting of multiple source behavior
          aggregates is applied.  This term attempts to capture the
          expected loss behavior, for which the device is configured,
          when subjected to a certain offered load.

          The actual algorithms or mechanism, that the DUT uses to
          achieve service differentiation, is not important in
          describing the expected loss vector.

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

        Issues:

        See Also:
          Intended Vector
          Offered Vector
          Expected Forwarding Vector
          Expected Sequence Vector
          Expected Delay Vector
          Expected Jitter Vector

     3.2.3.3 Expected Sequence Vector

        Definition:
          A vector describing the expected sequencing of packets having
          a specific DSCP or IP precedence value. The value is
          dependent on the set of offered vectors and configuration of
          the DUT.

        Discussion:
          The DUT is configured in a certain way in order that service
          differentiation occurs for behavior aggregates when a
          specific traffic mix consisting of multiple behavior
          aggregates is applied. This term attempts to capture the
          expected sequence behavior, for which the device is
          configured, when subjected to a certain offered load.

                 Network-layer Traffic Control Mechanisms

          The actual algorithms or mechanism, that the DUT uses to
          achieve service differentiation, is not important in
          describing the expected vector.

        Measurement Units:
          N-octet packets per second

        Issues:

        See Also:
          Intended Vector
          Offered Vector
          Output Vectors
          Expected Loss Vector
          Expected Forwarding Vector
          Expected Delay Vector
          Expected Jitter Vector

     3.2.3.4 Expected Delay Vector

        Definition:
          A vector describing the expected delay for packets having a
          specific DSCP or IP precedence value. The value is dependent
          on the set of offered vectors and configuration of the DUT.

        Discussion:
          The DUT is configured in a certain way in order that service
          differentiation occurs for behavior aggregates when a
          specific traffic mix consisting of multiple behavior
          aggregates is applied. This term attempts to capture the
          expected delay behavior, for which the device is configured,
          when subjected to a certain offered load.

          The actual algorithms or mechanism, that the DUT uses to
          achieve service differentiation, is not important in
          describing the expected delay vector.

     Measurement units:

          Seconds.

        Issues:

        See Also:
          Intended Vector
          Offered Vector
          Output Vectors
          Expected Loss Vector
          Expected Sequence Vector
          Expected Forwarding Vector
          Expected Jitter Vector
                 Network-layer Traffic Control Mechanisms

     3.2.3.5 Expected Jitter Vector

        Definition:
          A vector describing the expected variation in the delay of
          packet arrival times for packets having specific DSCP or IP
          precedence value. The value is dependent on the set of
          offered vectors and configuration of the DUT.

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

          The jitter 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 delay
          and i is the test sequence number.  Packets lost are not
          counted in the jitter measurement.

          Average Jitter is the average of the instantaneous jitter
          measured during the test duration.

          Peak-to-peak jitter is the maximum delay minus the minimum
          delay of the packets forwarded by the DUT/SUT.

        Measurement units:
          Seconds (instantaneous)
          Seconds P-P (peak to peak)
          Seconds Avg (average)

        Issues:

        See Also:
          Intended Vector
          Offered Vector
          Output Vectors
          Expected Loss Vector
          Expected Sequence Vector
          Expected Delay Vector
          Expected Forwarding Vector

     3.2.4 Output Vectors
                 Network-layer Traffic Control Mechanisms

     3.2.4.1 Forwarding Vector

        Definition:
          The number of packets per second for all packets containing a
          specific DSCP or IP precedence value that a device can be
          observed to successfully transmit to the correct destination
          interface in response to an offered vector.

        Discussion:
          Forwarding Vector is expressed as pair of numbers.  Both the
          specific DSCP (or IP precedence) value AND the packets per
          second value combine to make a vector.

          The Forwarding Vector represents packet rate based on its
          specific DSCP (or IP precedence) value.  It is not
          necessarily based on a stream or flow.  The Forwarding Vector
          may be expressed as per port of the DUT/SUT. However, it must
          be consistent with the Expected Forwarding Vector.

          Forwarding Vector is a per-hop measurement.  The DUT/SUT may
          change the specific DSCP (or IP precedence) value for a
          multiple-hop measurement.

        Measurement units:
          N-octet packets per second

        Issues:

        See Also:
          Intended Vector
          Offered Vector
          Expected Vectors
          Loss Vector
          Sequence Vector
          Delay Vector
          Jitter Vector

     3.2.4.2 Loss Vector

        Definition:
          The percentage of packets containing specific DSCP or IP
          precedence value that a DUT/SUT did not transmit to the
          correct destination interface in response to an offered
          vector.

        Discussion:
          Loss Vector is expressed as pair of numbers.  Both the
          specific DSCP (or IP precedence) value AND the percentage
          value combine to make a vector.

                 Network-layer Traffic Control Mechanisms

          The Loss Vector represents percentage based on a specific
          DSCP or IP precedence value.  It is not necessarily based on
          a stream or flow.  The Loss Vector may be expressed as per
          port of the DUT/SUT. However, it must be consistent with the
          Expected Loss Vector

          Loss Vector is a per-hop measurement.  The DUT/SUT may change
          the specific DSCP or IP precedence value for a multiple-hop
          measurement.

        Measurement Units:
          Percentage of offered packets that are not forwarded.

        Issues:

        See Also:
          Intended Vector
          Offered Vector
          Expected Vectors
          Forwarding Vector
          Sequence Vector
          Delay Vector
          Jitter Vector

     3.2.4.3 Sequence Vector

        Definition:
          The number of packets per second for all packets containing a
          specific DSCP or IP precedence value that a device can be
          observed to transmit out of sequence to the correct
          destination interface in response to an offered vector.

        Discussion:
          Sequence Vector is expressed as pair of numbers.  Both the
          specific DSCP (or IP precedence) value AND the packets per
          second value combine to make a vector.

          The Sequence Vector represents packet rate based on its
          specific DSCP or IP precedence value.  It is not necessarily
          based on a stream or flow.  The Sequence Vector may be
          expressed as per port of the DUT/SUT.  However, it must be
          consistent with the Expected Sequence Vector.

          Sequence Vector is a per-hop measurement.  The DUT/SUT may
          change the specific DSCP or IP precedence value for a
          multiple-hop measurement.

        Measurement Units:
          N-octet packets per second

        Issues:

                 Network-layer Traffic Control Mechanisms

        See Also:
          Intended Vector
          Offered Vector
          Expected Vectors
          Loss Vector
          Forwarding Vector
          Delay Vector
          Jitter Vector

     3.2.4.4 Delay Vector

        Definition:
          The delay for packets containing specific DSCP or IP
          precedence value that a device can be observed to
          successfully transmit to the correct destination interface in
          response to an offered vector.

        Discussion:
          Delay vector is expressed as pair of numbers.  Both the
          specific DSCP (or IP precedence) value AND delay value
          combine to make a vector.

          The Delay Vector represents delay on its specific DSCP or IP
          precedence value.  It is not necessarily based on a stream or
          flow.  The Delay vector may be expressed as per port of the
          DUT/SUT.  However, it must be consistent with the Expected
          Delay vector.

          Delay vector is measured similarly regardless of the type of
          DUT/SUT.  Latency [1] require some knowledge of whether the
          DUT/SUT is a "store and forward" or a "bit forwarding"
          device.  The fact that a DUT/SUT's technology has a lower
          delay than another technology should be visible.

          Delay Vector is a per-hop measurement.  The DUT/SUT may
          change the specific DSCP or IP addresses and/or precedence value for a
          multiple-hop measurement.

          Delay vector can be obtained at any offered load.  Recommend
          at or below the channel capacity in the absence of
          congestion.  For congested delay, run the offered load above
          the channel capacity.

        Measurement Units:
          seconds

        Issues:

        See Also:
          Delay
                 Network-layer Traffic Control Mechanisms

          Intended Vector
          Offered Vector
          Expected Delay Vector
          Loss Vector
          Forwarding Vector
          Jitter Vector

     3.2.4.5 Jitter Vector

        Definition:
          The variation in the delay for packets containing specific
          DSCP or IP precedence value that a device can be observed to
          successfully transmit to the correct destination interface in
          response to an offered vector.

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

          Jitter vector is expressed as pair of numbers.  Both the
          specific DSCP (or IP addresses.  All precedence) value AND jitter value
          combine to make a vector.

          The jitter 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 delay
          and i is the test sequence number.  Packets lost are not
          counted in the jitter measurement.

          Jitter vector is a per-hop measurement.  The DUT/SUT may
          change the specific DSCP or IP precedence value for a
          multiple-hop measurement.

          Average Jitter is the average of the instantaneous jitter
          measured during the test duration.

          Peak-to-peak Jitter is the maximum delay minus the minimum
          delay of the packets in a flow must enter on forwarded by the same ingress interface and exit on DUT/SUT.

        Measurement units:
          Seconds (instantaneous)
          Seconds P-P (peak to peak)
          Seconds Avg (average)

        Issues:

        See Also:
          Intended Vector
          Offered Vector
          Expected Vectors
                 Network-layer Traffic Control Mechanisms

          Loss Vector
          Sequence Vector
          Delay Vector
          Forwarding Vector

     3.3 Measurement Terms

     3.3.1 Channel Capacity

        Definition:
          The maximum forwarding rate [2] at which none of the same egress
        interface, and have some common network layer content.

        Microflows [3] offered
          packets are a subset dropped by the DUT/SUT.

        Discussion:
          Channel capacity measures the packet rate at the egress
          interface(s) of flows.  As defined in [3],
        microflows require application-to-application measurement. the DUT/SUT. In contrast, flows use lower-layer classification criteria. Since
        this document focuses on network-layer classification criteria,
        we concentrate here throughput as
          defined in RFC 1242 measures the packet rate is based on the use
          ingress interface(s) of network-layer identifiers in
        describing a flow. Flow identifiers also may reside at the
        data-link, transport, or application layers DUT/SUT.

          Ingress-based measurements do not account for congestion of
          the ISO model.
        However, identifiers other DUT/SUT. Channel capacity, as an egress measurement, does
          take congestion into account.

          Understanding channel capacity is a necessary precursor to
          any measurement involving congestion.  Throughput numbers can
          be higher than those channel capacity because of queueing.

          This measurement differs from forwarding rate at the network layer are
        out maximum
          offered load (FRMOL) [2] in that it is intolerant of scope for this document. loss.

        Measurement units:

           N-octet packets per second

        Issues:

        See Also:
          Throughput [1]
          Forwarding Rate at Maximum Offered Load [2]

     3.3.2 Conforming

        Definition:
          Packets which lie within specific rate, delay, or jitter
          bounds.

        Discussion:
          A flow DUT/SUT may contain be configured to allow a single code point/IP precedence value or
        may contain multiple values destined for given traffic class to
          consume a single egress
        interface.  This is determined by given amount of bandwidth, or to fall within
                 Network-layer Traffic Control Mechanisms

          predefined delay or jitter boundaries. All packets that lie
          within specified bounds are then said to be conforming,
          whereas those outside the test methodology. bounds are nonconforming.

        Measurement units:

           n/a

        Issues:

        See Also:
        Microflow [3]
               Network-layer Traffic Control Mechanisms

        Streams

   3.10
          Expected Vector
          Forwarding Vector
          Offered Vector
          Nonconforming

     3.3.3 Nonconforming

        Definition:
        The number of packets per second for all packets containing a
        single DSCP (or IP precedence)
          Packets that a device can do not lie within specific rate, delay, or
          jitter bounds.

        Discussion:
          A DUT/SUT may be observed to
        successfully transmit configured to the correct destination interface in
        response allow a given traffic class to an offered vector.

      Discussion:
        Forwarding Vector is expressed as pair
          consume a given amount of numbers.  Both the
        codepoint (or IP precedence) value AND the packets per second
        value combine bandwidth, or to make a vector.

        The forwarding vector represents packet rate based on their
        codepoint fall within
          predefined delay or IP precedence value.  It is jitter boundaries. All packets that do
          not necessary based on
        stream or flow.  The forwarding vector may lie within these bounds are then said to be expresses as ˘per
        port÷ or ˘of the DUT/SUT÷.
          nonconforming.

        Measurement units:

           n/a

        Issues:

        See Also:
          Expected Vector
          Forwarding Vector is a per-hop measurement.
          Offered Vector
          Conforming

     3.3.4 Delay

        Definition:
          The time interval starting when the last bit of the input IP
          packets reaches the input port of the DUT/SUT may
        change and ending when
          the codepoint or last bit of the output IP precedence value for a multiple-hop
        measurement.

      Measurement units:

        N-octet packets per second

      Issues:

      See Also:
        Codepoint Set
        Expected Vector
        Offered Vector.

   3.11 Jitter

      Definition:
        Variation in a stream's delay.

      Discussion:
        Jitter is seen on the absolute value output
          port of the difference between DUT/SUT.

        Discussion:

                 Network-layer Traffic Control Mechanisms

          Delay is measured the
        delay measurement same regardless of two packets belonging to the same stream. type of DUT/SUT.
          Latency [1] require some knowledge of whether the DUT/SUT is
          a "store and forward" or a "bit forwarding" device.  The jitter between two consecutive packets in fact
          that a stream is
        reported as DUT/SUT's technology has a lower delay than another
          technology should be visible.

          By specifying the "instantaneous jitter". Instantaneous jitter
        can metric to be expressed as |D(i) ű D(i+1)| where D equals inside the delay
        and i Internet protocol,
          the tester is relieved from specifying the test sequence number.  Packets lost start/end for
          every data link layer protocol that IP runs on.  This avoids
          determining if the start/end delimiter are not
        counted included in the jitter measurement.

               Network-layer Traffic Control Mechanisms

        Average Jitter is the average of
          frame.  Also heterogeneous data link protocol can be used in
          a test.

          The measurement point at the instantaneous jitter
        measured during end is closely simulates the test duration.

        Peak-to-peak jitter way
          an internet datagram is processed.  An internet datagram is
          not passed up or down the maximum delay minus stack unless it is complete.
          Completion occurs once the minimum
        delay last bit of the packets forwarded by IP packet has been
          received.

          Delay can be run at any offered load.  Recommend at or below
          the DUT/SUT.

      Measurement units:

        Seconds (instantaneous)
        Seconds P-P (peak to peak)
        Seconds avg (average) channel capacity for non-congested delay.  For congested
          delay, run the offered load above the channel capacity.

        Measurement units:

           Seconds.

        Issues:
        Mean
        Standard Deviation
        Median
        90th percentile
        Inter Quartile Range

        See Also:
        Stream

   3.12 Nonconforming
          Latency [1]

     3.3.5 Flow

        Definition:
        Packets that lie outside the parameter bounds
          A flow is a one or more of packets sharing a given
        traffic profile. common intended
          pair of source and destination interfaces.

        Discussion:
        Rules may be configured for
          Packets are grouped by the ingress and egress interfaces they
          use on a given traffic class based on
        parameters, such as an upper bound on the rate of packet
        arrivals. DUT/SUT.

          A flow can contain multiple source IP addresses and/or
          destination IP addresses.  All packets that lie outside in a flow must enter
          on the bounds specified by same ingress interface and exit on the traffic profile, measured over same egress
          interface, and have some common network layer content.

          Microflows [3] are a period subset of time specified flows.  As defined in the traffic profile, are said to be nonconforming.

      Measurement units:

         n/a

      Issues:

      See Also:
        Conforming

   3.13 Offered Vector

      Definition: [3],
          microflows require application-to-application measurement. In
          contrast, flows use lower-layer classification criteria.
          Since this document focuses on network-layer classification
                 Network-layer Traffic Control Mechanisms

        A vector describing

          criteria, we concentrate here on the rate at which packets having use of network-layer
          identifiers in describing a specific
        code-point are offered to flow. Flow identifiers also may
          reside at the DUT/SUT.

      Discussion:
        Offered loads across data-link, transport, or application layers of
          the different code-point classes,
        constituting a code-point set, determine ISO model. However, identifiers other than those at the metrics associated
        with
          network layer are out of scope for this document.

          A flow may contain a specific code-point traffic class. 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-octets packets per second units:

           n/a

        Issues:
        Packet size.

        See Also:
        Expected Vector
        Forwarding Vector
        Codepoint Set

   3.14
          Microflow [3]
          Streams

     3.3.6 Stream

        Definition:
          A group of packets tracked as a single entity by the traffic
          receiver.  A stream shares may share a common content such as type
          (IP, UDP), frame packet size, or payload.

        Discussion:
          Streams are tracked by "sequence number" Test sequence number or "unique
          signature field" (RFC 2889).  Streams define how individual
          packet's 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 transverse 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 mulitcast stream can be forward to
          multiple destination interfaces.

        Measurement units:

           n/a

        Issues:

                 Network-layer Traffic Control Mechanisms

        See Also:
          Flow
          MicroFlow [3]
               Network-layer Traffic Control Mechanisms
          Test sequence number

   3.15 Tail dropping

      Definition:
        The condition in which a congested DUT/SUT discards newly
        arriving packets.

      Discussion:
        Every DUT/SUT has a finite amount of traffic it can forward,
        beyond which congestion occurs. Once the offered load crosses
        the congestion threshold, the device may discard any additional
        traffic that arrives until congestion clears.

        Tail dropping is typically a function of offered load exceeding
        a DUT/SUTĂs buffer capacity, but other factors internal to the
        DUT/SUT may also come into play. In terms of what is externally
        observable, tail dropping can be said to occur only when
        offered load exceeds channel capacity. Since a DUT/SUT may
        buffer traffic on ingress, the actual threshold for tail
        dropping may be higher than channel capacity.

      Measurement units:

         n/a

      Issues:
        Some congestion management mechanisms seek to avoid tail
        dropping by discarding packets before offered load exceeds
        channel capacity. In the presence of such mechanisms, neither
        congestion nor tail dropping should occur.

      See Also:
        Channel capacity
        Congestion

   3.16

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

               Network-layer Traffic Control Mechanisms

          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 number of in-sequence
          packets, number of out-sequence packets and 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

        Issues:

        See Also:
          Stream

   3.17 Unburdened

     3.3.8 Undifferentiated Response

        Definition:
        A performance measure
          The vector(s) obtained when mechanisms used to support diff-
          serv or IP precedence and DiffServ are disabled.

        Discussion:
          Enabling Diffserv diff-serv or IP precedence mechanisms such as scheduling algorithms may impose an
          additional processing overhead for packets, which packets. This overhead may
        cause the aggregate response to suffer
          degrade performance even when traffic belonging to only one
          class, the best effort best-effort class, is offered to the device. Comparisons

                 Network-layer Traffic Control Mechanisms

          Measurements with "unburdened performance" may
        thus "undifferentiated response" should be in order when obtaining metrics made
          to ensure that enabling
        Diffserv mechanisms doesn't impose an excessive performance
        penalty. establish a baseline.

          The vector(s) obtained with DSCPs or IP precedence enabled
          can be compared to the undifferentiated response to determine
          the effect of differentiating traffic.

        Measurement units:

          n/a

     4. Security Considerations

          Documents of this type do not directly effect affect the security of
          the Internet or of corporate networks as long as benchmarking
          is not performed on devices or systems connected to operating
          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.

     5. References

        [1]   Bradner, S., Editor, "Benchmarking Terminology for
              Network
               Network-layer Traffic Control Mechanisms Interconnection Devices", RFC 1242, July 1991.

        [2]   Mandeville, R., "Benchmarking Terminology for LAN
              Switching Devices", RFC 2285, February 1998.

        [3]   K. Nichols, S. Blake, F. Baker, D. Black,"Definition of
              the Differentiated Services Field (DS Field) in the IPv4
              and IPv6 Headers", RFC 2474, December 1998.

        [4]   S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
              Weiss, "An Architecture for Differentiated Services", RFC
              2475, December 1998.

                 Network-layer Traffic Control Mechanisms

     6. Author's Authors' Address

          Jerry Perser
          Spirent Communications
          26750 Agoura Road
          Calabasas, CA 91302
          USA

          Phone: + 1 818 676 2300
          EMail: jerry.perser@spirentcom.com

          David Newman
          Network Test
          31324 Via Colinas, Suite 113
          Westlake Village, CA 91362
          USA

          Phone: + 1 818 889 0011, x10
          EMail: dnewman@networktest.com

          Sumit Khurana
          Telcordia Technologies
          445 South Street
          Morristown, NJ 07960
          USA

          Phone: + 1 973 829 3170
          EMail: sumit@research.telcordia.com

          Shobha Erramilli
        Telcordia Technologies
        331 Newman Springs Road,
        Navesink,
          QNetworx Inc
          1119 Campus Drive West
          Morganville NJ 07701 07751
          USA
               Network-layer Traffic Control Mechanisms

          Phone: + 1 732 758 5508
          EMail: shobha@research.telcordia.com shobha@qnetworx.com

          Scott Poretsky
          Avici Systems
          101 Billerica Ave¨Building Ave_Building #6
          N. Billerica, MA 01862
          USA

          Phone: + 1 978 964 2287
          EMail: sporetsky@avici.com
                 Network-layer Traffic Control Mechanisms

     7.  Full Copyright Statement

          Copyright (C) The Internet Society (1998).  All Rights
          Reserved.

          This document and translations of it may be copied and
          furnished to others, and derivative works that comment on or
          otherwise explain it or assist in its implementation may be
          prepared, copied, published and distributed, in whole or in
          part, without restriction of any kind, provided that the
          above copyright notice and this paragraph are included on all
          such copies and derivative works.  However, this document
          itself may not be modified in any way, such as by removing
          the copyright notice or references to the Internet Society or
          other Internet organizations, except as needed for the
          purpose of developing Internet standards in which case the
          procedures for copyrights defined in the Internet Standards
          process must be followed, or as required to translate it into
          languages other than English.

          The limited permissions granted above are perpetual and will
          not be revoked by the Internet Society or its successors or
          assigns.  This document and the information contained herein
          is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
          THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.