draft-ietf-bmwg-dsmterm-13.txt   rfc4689.txt 
Network Working Group Scott Poretsky Network Working Group S. Poretsky
INTERNET-DRAFT Reef Point Systems Request for Comments: 4689 Reef Point Systems
Expires in: December 2006 Category: Informational J. Perser
Jerry Perser Veriwave
Veriwave S. Erramilli
Telcordia
Shobha Erramilli S. Khurana
Telcordia Motorola
October 2006
Sumit Khurana
Telcordia
June 2006
Terminology for Benchmarking Network-layer
Traffic Control Mechanisms
<draft-ietf-bmwg-dsmterm-13.txt>
Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Terminology for Benchmarking Network-layer Traffic Control Mechanisms
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 Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This memo provides information for the Internet community. It does
http://www.ietf.org/shadow.html. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes terminology for the benchmarking of
devices that implement traffic control using packet classification
based on defined criteria. The terminology is to be applied to
measurements made on the data plane to evaluate IP traffic control
mechanisms. Rules for packet classification can be based on any
field in the IP header, such as DSCP, or field in the packet
payload, such as port number.
Network-layer Traffic Control Mechanisms 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.
Table of Contents Table of Contents
1. Introduction .............................................. 3
2. Existing definitions ...................................... 3
3. Term definitions............................................4
3.1 Configuration Terms
3.1.1 Classification.........................................4
3.1.2 Codepoint Set..........................................4
3.1.3 Forwarding Congestion..................................5
3.1.4 Congestion Management..................................6
3.1.5 Flow...................................................7
3.2 Measurement Terms
3.2.1 Forwarding Capacity....................................7
3.2.2 Conforming Packet......................................8
3.2.3 Nonconforming Packet...................................9
3.2.4 Forwarding Delay.......................................9
3.2.5 Jitter................................................11
3.2.6 Undifferentiated Response.............................11
3.3 Sequence Tracking
3.3.1 In-sequence Packet....................................12
3.3.2 Out-of-order Packet...................................12
3.3.3 Duplicate Packet......................................13
3.3.4 Stream................................................14
3.3.5 Test Sequence number .................................15
3.4 Vectors...................................................15
3.4.1 Intended Vector.......................................15
3.4.2 Offered Vector........................................16
3.4.3 Expected Vectors......................................16
3.4.4 Output Vectors........................................23
4. IANA Considerations........................................31
5. Security Considerations....................................31
6. Acknowledgments............................................31
7. References.................................................32
8. Author's Address...........................................33
9. Full Copyright Statement...................................34
1. Introduction 1. Introduction ....................................................2
2. Existing Definitions ............................................3
3. Term Definitions ................................................4
3.1. Configuration Terms ........................................4
3.1.1. Classification ......................................4
3.1.2. Codepoint Set .......................................4
3.1.3. Forwarding Congestion ...............................5
3.1.4. Congestion Management ...............................6
3.1.5. Flow ................................................7
3.2. Measurement Terms ..........................................7
3.2.1. Forwarding Capacity .................................7
3.2.2. Conforming Packet ...................................8
3.2.3. Nonconforming Packet ................................9
3.2.4. Forwarding Delay ....................................9
3.2.5. Jitter .............................................11
3.2.6. Undifferentiated Response ..........................11
3.3. Sequence Tracking .........................................12
3.3.1. Test Sequence Number ...............................12
3.3.2. Stream .............................................12
3.3.3. In-Sequence Packet .................................13
3.3.4. Out-of-Order Packet ................................14
3.3.5. Duplicate Packet ...................................14
3.4. Vectors ...................................................15
3.4.1. Intended Vector ....................................15
3.4.2. Offered Vector .....................................16
3.4.3. Expected Vectors ...................................16
3.4.4. Output Vectors .....................................23
4. Security Considerations ........................................30
5. Acknowledgements ...............................................30
6. References .....................................................31
6.1. Normative References ......................................31
6.2. Informative References ....................................31
New terminology is needed because most existing measurements 1. Introduction
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 New terminology is needed because most existing measurements assume
of measurements as observed on egress as well as ingress of a the absence of congestion and only a single per-hop behavior. This
device/system under test. Again, the existence of congestion document introduces several new terms that will allow measurements to
requires the addition of egress measurements as well as those be taken during periods of congestion.
taken on ingress; without observing traffic leaving a
device/system it is not possible to say whether traffic-control
mechanisms effectively dealt with congestion.
Network-layer Traffic Control Mechanisms 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.
The principal measurements introduced in this document are vectors The principal measurements introduced in this document are vectors
for rate, delay, and jitter, all of which can be observed with or for rate, delay, and jitter, all of which can be observed with or
without congestion of the Device Under Test (DUT)/ System Under without congestion of the Device Under Test (DUT)/System Under Test
Test (SUT). This document describes only those terms relevant to (SUT). This document describes only those terms relevant to
measuring behavior of a DUT or SUT at the Egress during periods of measuring behavior of a DUT or SUT at the egress during periods of
congestion. End-to-end and service-level measurements are beyond congestion. End-to-end and service-level measurements are beyond the
the scope of this document. scope of this document.
2. Existing definitions 2. Existing Definitions
RFC 1224 "Techniques for Managing Asynchronously Generated Alerts"
[St91] is used for 'Time with fine enough units to distinguish
between two events'
RFC 1242 "Benchmarking Terminology for Network Interconnect RFC 1224, "Techniques for Managing Asynchronously Generated Alerts"
Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching [St91], is used for 'Time with fine enough units to distinguish
Devices" should be consulted before attempting to make use of this between two events'.
document.
RFC 2474 "Definition of the Differentiated Services Field (DS RFC 1242, "Benchmarking Terminology for Network Interconnect
Field) in the IPv4 and IPv6 Headers" section 2, contains Devices", and RFC 2285, "Benchmarking Terminology for LAN Switching
discussions of a number of terms relevant to network-layer traffic Devices", should be consulted before attempting to make use of this
control mechanisms and should also be consulted. document.
For the sake of clarity and continuity this RFC adopts the RFC 2474, "Definition of the Differentiated Services Field (DS Field)
template for definitions set out in Section 2 of RFC 1242. in the IPv4 and IPv6 Headers", section 2, contains discussions of a
Definitions are indexed and grouped together in sections for ease number of terms relevant to network-layer traffic control mechanisms
of reference. 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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[Br97]. RFC 2119 defines the use of these key words to help make the [Br97]. RFC 2119 defines the use of these key words to help make the
intent of standards track documents as clear as possible. While this intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track document uses these keywords, this document is not a standards track
document. document.
2.1 Frequently Used Acronyms 2.1. Frequently Used Acronyms
DA Destination Address
DS DiffServ
DSCP DiffServ Code Point
DUT Device Under Test
IP Internet Protocol
PHB Per Hop Behavior
SA Source Address
SUT System Under Test
Network-layer Traffic Control Mechanisms
3. Term definitions 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
3.1 Configuration Terms 3. Term Definitions
3.1.1 Classification 3.1. Configuration Terms
Definition: 3.1.1. Classification
Selection of packets according to defined rules.
Discussion: Definition:
Classification determines the per-hop behaviors and traffic Selection of packets according to defined rules.
conditioning functions such as shaping and dropping that
are to be applied to the packet.
Classification of packets can be made based on the DS field Discussion:
or IP Precedence in the packet header. Classification can Classification determines the per-hop behaviors and traffic
be based on other IP header fields such as IP Source conditioning functions, such as shaping and dropping, that are to
Address (SA), Destination Address (DA), and protocol, or be applied to the packet.
fields in the packet payload such as port number.
Classification can also be based on ingress interface.
It is possible to classify based on Multi-Field (MF)
criteria such as IP source and destination addresses,
protocol and port number.
Measurement units: n/a 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 [Bl98].
See Also: None Measurement units:
n/a
3.1.2 Codepoint Set See Also:
None
Definition: 3.1.2. Codepoint Set
The set of all DS Code-points or IP precedence values used
during the test duration.
Discussion: Definition:
Describes all the code-point markings associated with packets The set of all DS Code-points or IP precedence values used during
that are input to the DUT/SUT. For each entry in the the test duration.
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- Discussion:
point gets is subject to the DUT classifying packets to map Describes all the code-point markings associated with packets that
to the correct PHB. Moreover, the forwarding treatment in are input to the DUT/SUT. For each entry in the codepoint set,
general is also dependent on the complete set of offered there are associated vectors describing the rate of traffic,
vectors. delay, loss, or jitter containing that particular DSCP or IP
precedence value.
Measurement Units: n/a 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.
See Also: None Measurement Units:
Network-layer Traffic Control Mechanisms n/a
3.1.3 Forwarding Congestion See Also:
None
Definition: 3.1.3. Forwarding Congestion
A condition in which one or more egress interfaces are
offered more packets than are forwarded.
Discussion: Definition:
This condition is a superset of the overload definition A condition in which one or more egress interfaces are offered
[Ma98]. Overload [Ma98] deals with overloading input and more packets than are forwarded.
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 Discussion:
occurs when the SUT comprises multiple elements, in that This condition is a superset of the overload definition [Ma98].
Forwarding Congestion may occur at multiple points. Consider Overload [Ma98] deals with overloading input and output interfaces
a SUT comprising multiple edge devices exchanging traffic beyond the maximum transmission allowed by the medium. Forwarding
with a single core device. Depending on traffic patterns, congestion does not assume ingress interface overload as the only
the edge devices may induce Forwarding Congestion on multiple source of overload on output interfaces.
egress interfaces on the core device.
Throughput [Br91] defines the lower boundary of Forwarding Another difference between Forwarding Congestion and overload
Congestion. Throughput is the maximum offered rate with no occurs when the SUT comprises multiple elements, in that
Forwarding Congestion. At offered rates above throughput, Forwarding Congestion may occur at multiple points. Consider an
the DUT/SUT is considered to be in a state of Forwarding SUT comprising multiple edge devices exchanging traffic with a
Congestion. single core device. Depending on traffic patterns, the edge
devices may induce Forwarding Congestion on multiple egress
interfaces on the core device.
Packet Loss, not increased Forwarding Delay, is the Throughput [Br91] defines the lower boundary of Forwarding
external observable metric used to indicate the condition Congestion. Throughput is the maximum offered rate with no
of Forwarding Congestion. Packet Loss is a deterministic Forwarding Congestion. At offered rates above throughput, the
indicator of Forwarding Congestion. The condition of DUT/SUT is considered to be in a state of Forwarding Congestion.
increased Forwarding Delay without Packet Loss is an
indicator of Forwarding Congestion known as Incipient
Congestion. Incipient Congestion is a non-deterministic
indicator of Forwarding Congestion [Fl93]. As stated in
[Ec98], RED [Br98] detects incipient congestion before the
buffer overflows, but the current Internet environment is
limited to packet loss as the mechanism for indicating
congestion to the end-nodes. [Ra99] implies that it is
impractical to build a black-box test to observe Incipient
Congestion. [Ra99] instead introduces Explicit Congestion
Notification (ECN) as a deterministic Black-Box method for
observing Incipient Congestion. [Ra99] is an Experimental
RFC with limited deployment, so ECN is not used for this
particular methodology. For the purpose of "black-box"
testing a DUT/SUT, this methodology uses Packet Loss as the
indicator of Forwarding Congestion.
Network-layer Traffic Control Mechanisms Packet Loss, not increased Forwarding Delay, is the external
observable metric used to indicate the condition of Forwarding
Congestion. Packet Loss is a deterministic indicator of
Forwarding Congestion. The condition of increased Forwarding
Delay without Packet Loss is an indicator of Forwarding Congestion
known as Incipient Congestion. Incipient Congestion is a non-
deterministic indicator of Forwarding Congestion [Fl93]. As
stated in [Ec98], RED [Br98] detects incipient congestion before
the buffer overflows, but the current Internet environment is
limited to packet loss as the mechanism for indicating congestion
to the end-nodes. [Ra99] implies that it is impractical to build
a black-box test to observe Incipient Congestion. [Ra99] instead
introduces Explicit Congestion Notification (ECN) as a
deterministic Black-Box method for observing Incipient Congestion.
[Ra99] is an Experimental RFC with limited deployment, so ECN is
not used for this particular methodology. For the purpose of
"black-box" testing a DUT/SUT, this methodology uses Packet Loss
as the indicator of Forwarding Congestion.
Ingress observations alone are not sufficient to cover all Ingress observations alone are not sufficient to cover all cases
cases in which Forwarding Congestion may occur. A device in which Forwarding Congestion may occur. A device with an
with an infinite amount of memory could buffer an infinite infinite amount of memory could buffer an infinite number of
number of packets, and eventually forward all of them. packets and eventually forward all of them. However, these
However, these packets may or may not be forwarded during packets may or may not be forwarded during the test duration.
the test duration. Congestion Collapse [Na84] is defined Congestion Collapse [Na84] is defined as the state in which
as the state in which buffers are full and all arriving buffers are full and all arriving packets MUST be dropped across
packets MUST be dropped across the network. Even though the network. Even though ingress interfaces accept all packets
ingress interfaces accept all packets without loss, without loss, Forwarding Congestion is present in this
Forwarding Congestion is present in this hypothetical hypothetical device.
device.
The definition presented here explicitly defines The definition presented here explicitly defines Forwarding
Forwarding Congestion as an event observable on egress Congestion as an event observable on egress interfaces.
interfaces. Regardless of internal architecture, any Regardless of internal architecture, any device exhibiting Packet
device exhibiting Packet Loss on one or more egress Loss on one or more egress interfaces is experiencing Forwarding
interfaces is experiencing Forwarding Congestion. Congestion.
Measurement units: Measurement units:
None None
See Also: See Also:
Gateway Congestion Control Survey [Ma91] Gateway Congestion Control Survey [Ma91]
3.1.4 Congestion Management 3.1.4. Congestion Management
Definition: Definition:
An implementation of one or more per-hop-behaviors to avoid An implementation of one or more per-hop behaviors to avoid or
or minimize the condition of congestion. minimize the condition of congestion.
Discussion: Discussion:
Congestion management may seek either to control congestion Congestion management may seek either to control congestion or
or avoid it altogether through Classification. avoid it altogether through Classification.
Congestion avoidance mechanisms seek to prevent congestion Congestion avoidance mechanisms seek to prevent congestion before
before it actually occurs. it actually occurs.
Congestion control mechanisms give one or more flows (with a Congestion control mechanisms give one or more flows (with a
discrete IP Precedence or DSCP value) preferential treatment discrete IP Precedence or DSCP value) preferential treatment over
over other classes during periods of congestion. other classes during periods of congestion.
Measurement units: Measurement units:
n/a n/a
See Also: See Also:
Classification Classification
Network-layer Traffic Control Mechanisms
3.1.5 Flow 3.1.5. Flow
Definition: Definition:
A flow is a one or more of packets sharing a common intended A flow is one or more packets sharing a common intended pair of
pair of ingress and egress interfaces. ingress and egress interfaces.
Discussion: Discussion:
Packets are grouped by the ingress and egress interfaces they Packets are grouped by the ingress and egress interfaces they use
use on a given DUT/SUT. on a given DUT/SUT.
A flow can contain multiple source IP addresses and/or A flow can contain multiple source IP addresses and/or destination
destination IP addresses. All packets in a flow MUST enter IP addresses. All packets in a flow MUST enter on the same
on the same ingress interface and exit on the same egress ingress interface and exit on the same egress interface and have
interface, and have some common network layer content. some common network layer content.
Microflows [Ni98] are a subset of flows. As defined in Microflows [Ni98] are a subset of flows. As defined in [Ni98],
[Ni98], microflows require application-to-application microflows require application-to-application measurement. In
measurement. In contrast, flows use lower-layer contrast, flows use lower-layer classification criteria. Since
classification criteria. Since this document focuses on this document focuses on network-layer classification criteria, it
network-layer classification criteria, we concentrate here on concentrates here on the use of network-layer identifiers in
the use of network-layer identifiers in describing a flow. describing a flow. Flow identifiers also may reside at the data-
Flow identifiers also may reside at the data-link, transport, link, transport, or application layers of the OSI model. However,
or application layers of the OSI model. However, identifiers identifiers other than those at the network layer are out of scope
other than those at the network layer are out of scope for for this document.
this document.
A flow may contain a single code point/IP precedence value or A flow may contain a single code point/IP precedence value or may
may contain multiple values destined for a single egress contain multiple values destined for a single egress interface.
interface. This is determined by the test methodology. This is determined by the test methodology.
Measurement units: Measurement units:
n/a n/a
See Also: See Also:
Microflow [Ni98] Microflow [Ni98]
Streams Streams
3.2 Measurement Terms 3.2. Measurement Terms
3.2.1 Forwarding Capacity 3.2.1. Forwarding Capacity
Definition: Definition:
The number of packets per second that a device can be The number of packets per second that a device can be observed to
observed to successfully transmit to the correct destination transmit successfully to the correct egress interface in response
interface in response to a specified offered load while the to a specified offered load while the device drops none of the
device drops none of the offered packets. offered packets.
Discussion: Discussion:
Forwarding Capacity measures the packet rate at the egress Forwarding Capacity measures the packet rate at the egress
interface(s) of the DUT/SUT. In contrast, throughput as interface(s) of the DUT/SUT. In contrast, throughput (as defined
defined in RFC 1242 measures the packet rate at the ingress in RFC 1242) measures the packet rate at the ingress interface(s)
interface(s) of the DUT/SUT. of the DUT/SUT.
Network-layer Traffic Control Mechanisms Ingress-based measurements do not account for queuing of the
DUT/SUT. Throughput rates can be higher than the Forwarding
Capacity because of queueing. The difference is dependent upon
test duration, packet rate, and queue size. Forwarding Capacity,
as an egress measurement, does take queuing into account.
Ingress-based measurements do not account for queuing of the Understanding Forwarding Capacity is a necessary precursor to any
DUT/SUT. Throughput rates can be higher than the Forwarding measurement involving Traffic Control Mechanisms. The
Capacity because of queueing. The difference is dependent accompanying methodology document MUST take into consideration
upon test duration, packet rate, and queue size. Forwarding Forwarding Capacity when determining the expected forwarding
Capacity, as an egress measurement, does take queuing into vectors. When the sum of the expected forwarding vectors on an
account. interface exceeds the Forwarding Capacity, the Forwarding Capacity
will govern the forwarding rate.
Understanding Forwarding Capacity is a necessary precursor to This measurement differs from forwarding rate at maximum offered
any measurement involving Traffic Control Mechanisms. The load (FRMOL) [Ma98] in that the Forwarding Capacity requires zero
accompanying methodology document MUST take into loss.
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 Measurement units:
offered load (FRMOL) [Ma98] in that Forwarding Capacity N-octet packets per second
requires zero loss.
Measurement units: See Also:
N-octet packets per second Throughput [Br91]
Forwarding Rate at Maximum Offered Load [Ma98]
See Also: 3.2.2. Conforming Packet
Throughput [Br91]
Forwarding Rate at Maximum Offered Load [Ma98]
3.2.2 Conforming Packet Definition:
Packets that lie within specific rate, delay, or jitter bounds.
Definition: Discussion:
Packets which lie within specific rate, delay, or jitter A DUT/SUT may be configured to allow a given traffic class to
bounds. 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.
Discussion: Measurement units:
A DUT/SUT may be configured to allow a given traffic class to n/a
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: See Also:
n/a Expected Vector
Forwarding Vector
Offered Vector
Nonconforming
See Also: 3.2.3. Nonconforming Packet
Expected Vector
Forwarding Vector
Offered Vector
Nonconforming
Network-layer Traffic Control Mechanisms
3.2.3 Nonconforming Packet Definition:
Packets that do not lie within specific rate, delay, or jitter
bounds.
Definition: Discussion:
Packets that do not lie within specific rate, delay, or A DUT/SUT may be configured to allow a given traffic class to
jitter bounds. 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.
Discussion: Measurement units:
A DUT/SUT may be configured to allow a given traffic class to n/a
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: See Also:
n/a Expected Vector
Forwarding Vector
Offered Vector
Conforming
See Also: 3.2.4. Forwarding Delay
Expected Vector
Forwarding Vector
Offered Vector
Conforming
3.2.4 Forwarding Delay Definition:
The time interval starting when the last bit of the input IP
packet is offered to the input port of the DUT/SUT and ending when
the last bit of the output IP packet is received from the output
port of the DUT/SUT.
Definition: Discussion:
The time interval starting when the last bit of the input IP The delay time interval MUST be externally observed. The delay
packet is offered to the input port of the DUT/SUT and ending measurement MUST NOT include delays added by test bed components
when the last bit of the output IP packet is received from other than the DUT/SUT, such as propagation time introduced by
the output port of the DUT/SUT. cabling or non-zero delay added by the test instrument.
Forwarding Delay differs from latency [Br91] and one-way delay
[Al99] in several key regards:
Discussion: 1. Latency [Br91] assumes knowledge of whether the DUT/SUT uses
The delay time interval MUST be externally observed. The "store and forward" or "bit forwarding" technology. Forwarding
delay measurement MUST NOT include delays added by test bed Delay is the same metric, measured the same way, regardless of
components other than the DUT/SUT, such as propagation time the architecture of the DUT/SUT.
introduced by cabling or non-zero delay added by the test
instrument. Forwarding Delay differs from latency [Br91]
and one-way delay [Al99] in several key regards:
1. Latency [Br91] assumes knowledge of whether the DUT/SUT 2. Forwarding Delay is a last-in, last-out (LILO) measurement,
uses "store and forward" or "bit forwarding" technology. unlike the last-in, first-out method [Br91] or the first-in,
Forwarding Delay is the same metric, measured the same way, last-out method [Al99].
regardless of the architecture of the DUT/SUT.
2. Forwarding Delay is a last-in, last-out (LILO) The LILO method most closely simulates the way a network-layer
measurement, unlike the last-in, first-out method [Br91] or device actually processes an IP datagram. IP datagrams are not
the first-in, last-out method [Al99]. 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.
The LILO method most closely simulates the way a network- Further, the LILO method has an additive property, where the
layer device actually processes an IP datagram. IP datagrams sum of the parts MUST equal the whole. This is a key
are not passed up and down the stack unless they are difference from [Br91] and [Al99]. For example, the delay
complete, and processing begins only once the last bit of the added by two DUTs MUST equal the sum of the delay of the DUTs.
IP datagram has been received. This may or may not be the case with [Br91] and [Al99].
Network-layer Traffic Control Mechanisms 3. Forwarding Delay measures the IP datagram only, unlike [Br91],
which also includes link-layer overhead.
Further, the LILO method has an additive property, where the A metric focused exclusively on the Internet protocol relieves
sum of the parts MUST equal the whole. This is a key the tester from specifying the start/end for every link-layer
difference from [Br91] and [Al99]. For example, the delay protocol that IP runs on. This avoids the need to determine
added by two DUTs MUST equal the sum of the delay of the whether the start/stop delimiters are included. It also allows
DUTs. This may or may not be the case with [Br91] and the use of heterogeneous link-layer protocols in a test.
[Al99].
3. Forwarding Delay measures the IP datagram only, unlike 4. Forwarding Delay can be measured at any offered load, whereas
[Br91], which also includes link layer overhead. the latency methodology [Br99] recommends measurement at, and
only at, the throughput level. Comparing the Forwarding Delay
below the throughput to Forwarding Delay above the Forwarding
Capacity will give insight to the traffic control mechanisms.
A metric focused exclusively on the Internet protocol For example, non-congested delay may be measured with an
relieves the tester from specifying the start/end for every offered load that does not exceed the Forwarding Capacity,
link layer protocol that IP runs on. This avoids the need to while congested delay may involve an offered load that exceeds
determine whether the start/stop delimiters are included. It the Forwarding Capacity.
also allows the use of heterogeneous link layer protocols in
a test.
4. Forwarding Delay can be measured at any offered load, Note: Forwarding Delay SHOULD NOT be used as an absolute
whereas the latency methodology [Br99] recommends measurement indicator of DUT/SUT Forwarding Congestion. While Forwarding
at, and only at, the throughput level. Comparing the Delay may rise when offered load nears or exceeds the
Forwarding Delay below the throughput to Forwarding Delay Forwarding Capacity, there is no universal point at which
above the Forwarding Capacity will give insight to the Forwarding Delay can be said to indicate the presence or
traffic control mechanisms. absence of Forwarding Congestion.
For example, non-congested delay may be measured with an Measurement units:
offered load that does not exceed the Forwarding Capacity, milliseconds
while congested delay may involve an offered load that
exceeds Forwarding Capacity.
Note: Forwarding Delay SHOULD NOT be used as an absolute See Also:
indicator of DUT/SUT Forwarding Congestion. While Forwarding Latency [Br91]
Delay may rise when offered load nears or exceeds Forwarding Latency [Al99]
Capacity, there is no universal point at which Forwarding One-way Delay [Br99]
Delay can be said to indicate the presence or absence of
Forwarding Congestion.
Measurement units: 3.2.5. Jitter
milliseconds
See Also: Definition:
Latency [Br91] The absolute value of the difference between the Forwarding Delay
Latency [Al99] of two consecutive received packets belonging to the same stream.
One-way Delay [Br99]
Network-layer Traffic Control Mechanisms
3.2.5 Jitter 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.
Definition: Under loss, jitter can be measured between non-consecutive test
The absolute value of the difference between the arrival sequence numbers. When IP Traffic Control Mechanisms are dropping
delay of two consecutive received packets belonging to the packets, fluctuating Forwarding Delay may be observed. Jitter
same stream. MUST be able to benchmark the delay variation independently of
packet loss.
Discussion: Jitter is related to the IPDV [De02] (IP Delay Variation) by
The Forwarding Delay fluctuation between two consecutive taking the absolute value of the ipdv. The two metrics will
received packets in a stream is reported as the Jitter. produce different mean values. Mean Jitter will produce a
Jitter can be expressed as |D(i) - D(i-1)| where D equals positive value, where the mean ipdv is typically zero. Also, IPDV
the Forwarding Delay and i is the order the packets were is undefined when one packet from a pair is lost.
received.
Under loss, jitter can be measured between non-consecutive Measurement units:
test sequence numbers. When IP Traffic Control Mechanisms milliseconds
are dropping packets, fluctuating Forwarding Delay may be
observed. Jitter MUST be able to benchmark the delay
variation independent of packet loss.
Jitter is related to the IPDV [De02] (IP Delay Variation) by See Also:
taking the absolute value of the ipdv. The two metrics will Forwarding Delay
produce different mean values. Mean Jitter will produce a Jitter variation [Ja99]
positive value, where the mean ipdv is typically zero. Also, ipdv [De02]
IPDV is undefined when one packet from a pair is lost. interarrival jitter [Sc96]
Measurement units: 3.2.6. Undifferentiated Response
milliseconds
See Also: Definition:
Forwarding Delay The vector(s) obtained when mechanisms used to support diff-serv
Jitter variation [Ja99] or IP precedence are disabled.
ipdv [De02]
interarrival jitter [Sc96]
3.2.6 Undifferentiated Response Discussion:
Enabling diff-serv or IP precedence mechanisms may impose
additional processing overhead for packets. This overhead may
degrade performance even when traffic belonging to only one class,
the best-effort class, is offered to the device. Measurements
with "undifferentiated response" SHOULD be made to establish a
baseline.
Definition: The vector(s) obtained with DSCP or IP precedence enabled can be
The vector(s) obtained when mechanisms used to support compared to the undifferentiated response to determine the effect
diff-serv or IP precedence are disabled. of differentiating traffic.
Discussion: Measurement units:
Enabling diff-serv or IP precedence mechanisms may impose n/a
additional processing overhead for packets. This overhead
may degrade performance even when traffic belonging to only
one class, the best-effort class, is offered to the device.
Measurements with "undifferentiated response" SHOULD be made
to establish a baseline.
Network-layer Traffic Control Mechanisms 3.3. Sequence Tracking
The vector(s) obtained with DSCP or IP precedence enabled can 3.3.1. Test Sequence Number
be compared to the undifferentiated response to determine the
effect of differentiating traffic.
Measurement units: Definition:
n/a 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.
3.3 Sequence Tracking 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.
3.3.1 In-sequence Packet 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.
Definition: Measurement units:
A received packet with the expected Test Sequence number. n/a
Discussion: See Also:
In-sequence is done on a stream level. As packets are Stream
received on a stream, each packets Test Sequence number is
compared with the previous packet. Only packets that match
the expected Test Sequence number are considered in-sequence.
Packets that do not match the expected Test Sequence number 3.3.2. Stream
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 Definition:
incrementing: packet loss and reordered packets. 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.
Measurement units: Discussion:
Packet count Streams are tracked by test sequence number or "unique signature
field" [Ma00]. Streams define how individual packet statistics
are grouped together to form an intelligible summary.
See Also: Common stream groupings would be by egress interface, destination
Stream address, source address, DSCP, or IP precedence. A stream using
Test Sequence number test sequence numbers can track the ordering of packets as they
traverse the DUT/SUT.
3.3.2 Out-of-order Packet 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.
Definition: Measurement units:
A received packet with a sequence number less than n/a
the sequence number of a previously arriving packet.
Network-layer Traffic Control Mechanisms See Also:
Flow
Microflow [Ni98]
Test sequence number
Discussion: 3.3.3. In-Sequence Packet
As a stream of packets enters a DUT/SUT, they include a
Stream Test Sequence number indicating the order the packets
were sent to the DUT/SUT. On exiting the DUT/SUT, these
packets may arrive in a different order. Each packet that
was re-ordered is counted as an Out-of-order Packet.
Certain streaming protocol (such as TCP) require the packets Definition:
to be in a certain order. Packets outside this are dropped A received packet with the expected Test Sequence number.
by the streaming protocols even though there were properly
received by the IP layer. The type of reordering tolerated
by a streaming protocol varies from protocol to protocol, and
also by implementation.
Packet loss does not affect the Out-of-order Packet count. Discussion:
Only packets that were not received in the order that they In-sequence is done on a stream level. As packets are received on
were transmitted. 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.
Measurement units: Packets that do not match the expected Test Sequence number are
packets 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.
See Also: Two types of events will prevent the in-sequence from
Stream incrementing: packet loss and reordered packets.
Test Sequence number
Packet Reordering Metric for IPPM [Mo03]
3.3.3 Duplicate Packet Measurement units:
Packet count
Definition: See Also:
A received packet with a Test Sequence number matching a Stream
previously received packet. Test Sequence number
Discussion: 3.3.4. Out-of-Order Packet
A Duplicate Packet is a packet that the DUT/SUT has
successfully transmitted out an egress interface more than
once. The egress interface has previously forwarded this
packet.
A Duplicate Packet SHOULD be a bit for bit copy of an already Definition:
transmitted packet (including Test Sequence number). If the A received packet with a sequence number less than the sequence
Duplicate Packet traversed different paths through the number of any previously arriving packet.
DUT/SUT, some fields (such as TTL or checksum) may have
changed.
A multicast packet is not a Duplicate Packet by definition. Discussion:
For a given IP multicast group, a DUT/SUT SHOULD forward a As a stream of packets enters a DUT/SUT, they include a Stream
packet once on a given egress interface provided the path to Test Sequence number indicating the order the packets were sent to
one or more multicast receivers is through that interface. the DUT/SUT. On exiting the DUT/SUT, these packets may arrive in
Several egress interfaces will transmit the same packet, but a different order. Each packet that was reordered is counted as
only once per interface. an Out-of-Order Packet.
Network-layer Traffic Control Mechanisms 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.
To detect a Duplicate Packet, each offered packet to the Packet loss does not affect the Out-of-Order Packet count. The
DUT/SUT MUST contain a unique packet-by-packet identifier. Out-of-Order Packet count is impacted only by packets that were
not received in the order that they were transmitted.
Measurement units: Measurement units:
Packet count packets
See Also: See Also:
Stream Stream
Test Sequence number Test Sequence number
Packet Reordering Metric for IPPM [Mo03]
3.3.4 Stream 3.3.5. Duplicate Packet
Definition: Definition:
A group of packets tracked as a single entity by the traffic A received packet with a Test Sequence number matching a
receiver. A stream MUST share common content such as type previously received packet.
(IP, UDP), IP SA/DA, packet size, or payload.
Discussion: Discussion:
Streams are tracked by test sequence number or "unique A Duplicate Packet is a packet that the DUT/SUT has successfully
signature field" [Ma00]. Streams define how individual transmitted out an egress interface more than once. The egress
packets statistic are grouped together to form an interface has previously forwarded this packet.
intelligible summary.
Common stream groupings would be by egress interface, A Duplicate Packet SHOULD be a bit-for-bit copy of an already
destination address, source address, DSCP, or IP precedence. transmitted packet (including Test Sequence number). If the
A stream using test sequence numbers can track the ordering Duplicate Packet traversed different paths through the DUT/SUT,
of packets as they traverse the DUT/SUT. some fields (such as TTL or checksum) may have changed.
Streams are not restricted to a pair of source and A multicast packet is not a Duplicate Packet by definition. For a
destination interfaces as long as all packets are tracked as given IP multicast group, a DUT/SUT SHOULD forward a packet once
a single entity. A multicast stream can be forwarded to on a given egress interface provided the path to one or more
multiple destination interfaces. multicast receivers is through that interface. Several egress
interfaces will transmit the same packet, but only once per
interface.
Measurement units: To detect a Duplicate Packet, each packet offered to the DUT/SUT
n/a MUST contain a unique packet-by-packet identifier.
See Also: Measurement units:
Flow Packet count
Microflow [Ni98]
Test sequence number
Network-layer Traffic Control Mechanisms
3.3.5 Test Sequence Number See Also:
Definition: Stream
A field in the IP payload portion of the packet that is used Test Sequence number
to verify the order of the packets on the egress of the
DUT/SUT.
Discussion: 3.4. Vectors
The traffic generator sets the test sequence number value and
the traffic receiver checks the value upon receipt of the
packet. The traffic generator changes the value on each
packet transmitted based on an algorithm agreed to by the
traffic receiver.
The traffic receiver keeps track of the sequence numbers on a A vector is a group of packets all matching a specific
per stream basis. In addition to number of received packets, classification criteria, such as DSCP. Vectors are
the traffic receiver may also report the number of identified by the classification criteria and benchmarking
in-sequence packets, number of out-of-sequence packets, metrics, such as a Forwarding Capacity, Forwarding Delay,
number of duplicate packets, and number of reordered packets. or Jitter.
The RECOMMENDED algorithm to use to change the sequence
number on sequential packets is an incrementing value.
Measurement units: 3.4.1. Intended Vector
n/a
See Also: Definition:
Stream 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.
3.4 Vectors Discussion:
A vector is a group of packets all matching a specific The Intended Vector of a stream influences the benchmark
classification criteria, such as DSCP. Vectors are measurements. The Intended Vector is described by the
identified by the classification criteria and benchmarking classification criteria and attempted rate.
metrics such as a Forwarding Capacity, Forwarding Delay,
or Jitter.
3.4.1 Intended Vector Measurement Units:
Definition: N-bytes packets per second
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: See Also:
The Intended Vector of a stream influences the benchmark Stream
measurements. The Intended Vector is described by the Offered Vector
classification criteria and attempted rate. Forwarding Vector
Measurement Units: 3.4.2. Offered Vector
N-bytes packets per second
See Also: Definition:
Stream A description for the attempted rate of a stream offered to
Offered Vector a DUT/SUT matching specific classification rules.
Forwarding Vector
Network-layer Traffic Control Mechanisms
3.4.2 Offered Vector Discussion:
The Offered Vector of a stream influences the benchmark
measurements. The Offered Vector is described by the
classification criteria and offered rate.
Definition: Measurement Units:
A description for the attempted rate of a stream offered to N-bytes packets per second
a DUT/SUT matching specific classification rules.
Discussion: See Also:
The Offered Vector of a stream influences the benchmark Stream
measurements. The Offered Vector is described by the Intended Vector
classification criteria and offered rate. Forwarding Vector
Measurement Units: 3.4.3. Expected Vectors
N-bytes packets per second
See Also: 3.4.3.1. Expected Forwarding Vector
Stream
Intended Vector
Forwarding Vector
3.4.3 Expected Vectors Definition:
3.4.3.1 Expected Forwarding Vector A description of the expected output rate of packets matching a
specific classification, such as DSCP.
Definition: Discussion:
A description of the expected output rate of packets The value of the Expected Forwarding Vector is dependent on the
matching a specific classification, such as DSCP. 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.
Discussion: This term captures the expected forwarding behavior from the DUT
The value of the Expected Minimum Delay Vector is dependent receiving multiple Offered Vectors. The actual algorithm or
on the set of offered vectors and Classification mechanism the DUT uses to achieve service differentiation is
configuration on the DUT/SUT. The DUT is configured in a implementation specific and is not important when describing the
certain way in order that classification occurs when a Expected Forwarding Vector.
traffic mix consisting of multiple streams is applied.
This term captures the expected forwarding behavior from the Measurement units:
DUT receiving multiple Offered Vectors. The actual algorithm N-octet packets per second
or mechanism the DUT uses to achieve service differentiation
is implementation specific and not important when describing
the Expected Forwarding Vector.
Measurement units: See Also:
N-octet packets per second Classification
Stream
Intended Vector
Offered Vector
See Also: 3.4.3.2. Expected Loss Vector
Classification
Stream
Intended Vector
Offered Vector
Network-layer Traffic Control Mechanisms
3.4.3.2 Expected Loss Vector Definition:
A description of the percentage of packets having a specific
classification that should not be forwarded.
Definition: Discussion:
A description of the percentage of packets, having a The value of the Expected Loss Vector is dependent on the set of
specific classification that SHOULD NOT be forwarded. 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.
Discussion: This term captures the expected forwarding behavior from the DUT
The value of the Expected Minimum Delay Vector is dependent receiving multiple Offered Vectors. The actual algorithm or
on the set of offered vectors and Classification mechanism the DUT uses to achieve service differentiation is
configuration on the DUT/SUT. The DUT is configured in a implementation specific and is not important when describing the
certain way in order that classification occurs when a Expected Loss Vector.
traffic mix consisting of multiple streams is applied.
This term captures the expected forwarding behavior from the Measurement Units:
DUT receiving multiple Offered Vectors. The actual algorithm Percentage of intended packets expected to be dropped.
or mechanism the DUT uses to achieve service differentiation
is implementation specific and not important when describing
the Expected Loss Vector.
Measurement Units: See Also:
Percentage of intended packets that is expected to be Classification
dropped. Stream
Intended Vector
Offered Vector
One-way Packet Loss Metric [Ka99]
See Also: 3.4.3.3. Expected Sequence Vector
Classification
Stream
Intended Vector
Offered Vector
One-way Packet Loss Metric [Ka99]
3.4.3.3 Expected Sequence Vector Definition:
A description of the expected in-sequence packets matching a
specific classification, such as DSCP.
Definition: Discussion:
A description of the expected in-sequence packets matching The value of the Expected Sequence Vector is dependent on the set
a specific classification, such as DSCP. 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.
Discussion: This term captures the expected forwarding behavior from the DUT
The value of the Expected Minimum Delay Vector is dependent receiving multiple Offered Vectors. The actual algorithm or
on the set of offered vectors and Classification mechanism the DUT uses to achieve service differentiation is
configuration on the DUT/SUT. The DUT is configured in a implementation specific and is not important when describing the
certain way in order that classification occurs when a Expected Sequence Vector.
traffic mix consisting of multiple streams is applied.
This term captures the expected forwarding behavior from the Measurement Units:
DUT receiving multiple Offered Vectors. The actual algorithm N-octet packets per second
or mechanism the DUT uses to achieve service differentiation
is implementation specific and not important when describing
the Expected Sequence Vector.
Network-layer Traffic Control Mechanisms See Also:
Classification
Stream
In-Sequence Packet
Intended Vector
Offered Vector
Measurement Units: 3.4.3.4. Expected Delay Vector
N-octet packets per second
See Also: Definition:
Classification A description of the expected instantaneous Forwarding Delay for
Stream packets matching a specific classification, such as DSCP.
In-Sequence Packet
Intended Vector
Offered Vector
3.4.3.4 Expected Delay Vector 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.
Definition: This term captures the expected forwarding behavior from the DUT
A description of the expected instantaneous Forwarding receiving multiple Offered Vectors. The actual algorithm or
Delay for packets matching a specific classification, such mechanism the DUT uses to achieve service differentiation is
as DSCP. implementation specific and is not important when describing the
Expected Delay Vector.
Discussion: Measurement units:
The value of the Expected Minimum Delay Vector is dependent milliseconds
on the set of offered vectors and Classification
configuration on the DUT/SUT. The DUT is configured in a
certain way in order that classification occurs when a
traffic mix consisting of multiple streams is applied.
This term captures the expected forwarding behavior from the See Also:
DUT receiving multiple Offered Vectors. The actual algorithm Classification
or mechanism the DUT uses to achieve service differentiation Stream
is implementation specific and not important when describing Forwarding Delay
the Expected Delay Vector. Intended Vector
Offered Vector
Measurement units: 3.4.3.5. Expected Average Delay Vector
milliseconds
See Also: Definition:
Classification A description of the expected average Forwarding Delay for packets
Stream matching a specific classification, such as DSCP.
Forwarding Delay
Intended Vector
Offered Vector
3.4.3.5 Expected Average Delay Vector 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.
Definition: This term captures the expected forwarding behavior from the DUT
A description of the expected average Forwarding Delay receiving multiple Offered Vectors. The actual algorithm or
for packets matching a specific classification, such as mechanism the DUT uses to achieve service differentiation is
DSCP. implementation specific and is not important when describing the
Expected Average Delay Vector.
Network-layer Traffic Control Mechanisms Measurement units:
milliseconds
Discussion: See Also:
The value of the Expected Minimum Delay Vector is dependent Classification
on the set of offered vectors and Classification Stream
configuration on the DUT/SUT. The DUT is configured in a Forwarding Delay
certain way in order that classification occurs when a Intended Vector
traffic mix consisting of multiple streams is applied. Offered Vector
Expected Delay Vector
This term captures the expected forwarding behavior from the 3.4.3.6. Expected Maximum Delay Vector
DUT receiving multiple Offered Vectors. The actual algorithm
or mechanism the DUT uses to achieve service differentiation
is implementation specific and not important when describing
the Expected Average Delay Vector.
Measurement units: Definition:
milliseconds A description of the expected maximum Forwarding Delay for packets
matching a specific classification, such as DSCP.
See Also: Discussion:
Classification The value of the Expected Maximum Delay Vector is dependent on the
Stream set of offered vectors and Classification configuration on the
Forwarding Delay DUT/SUT. The DUT is configured in a certain way so that
Intended Vector classification occurs when a traffic mix consisting of multiple
Offered Vector streams is applied.
Expected Delay Vector
3.4.3.6 Expected Maximum Delay Vector 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.
Definition: Measurement units:
A description of the expected maximum Forwarding Delay milliseconds
for packets matching a specific classification, such as
DSCP.
Discussion: See Also:
The value of the Expected Minimum Delay Vector is dependent Classification
on the set of offered vectors and Classification Stream
configuration on the DUT/SUT. The DUT is configured in a Forwarding Delay
certain way in order that classification occurs when a Intended Vector
traffic mix consisting of multiple streams is applied. Offered Vector
Expected Delay Vector
This term captures the expected forwarding behavior from the 3.4.3.7. Expected Minimum Delay Vector
DUT receiving multiple Offered Vectors. The actual algorithm
or mechanism the DUT uses to achieve service differentiation
is implementation specific and not important when describing
the Expected Maximum Delay Vector.
Measurement units: Definition:
milliseconds A description of the expected minimum Forwarding Delay for packets
Network-layer Traffic Control Mechanisms matching a specific classification, such as DSCP.
See Also: Discussion:
Classification The value of the Expected Minimum Delay Vector is dependent on the
Stream set of offered vectors and Classification configuration on the
Forwarding Delay DUT/SUT. The DUT is configured in a certain way so that
Intended Vector classification occurs when a traffic mix consisting of multiple
Offered Vector streams is applied.
Expected Delay Vector
3.4.3.7 Expected Minimum Delay Vector 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.
Definition: Measurement units:
A description of the expected minimum Forwarding Delay milliseconds
for packets matching a specific classification, such as
DSCP.
Discussion: See Also:
The value of the Expected Minimum Delay Vector is dependent Classification
on the set of offered vectors and Classification Stream
configuration on the DUT/SUT. The DUT is configured in a Forwarding Delay
certain way in order that classification occurs when a Intended Vector
traffic mix consisting of multiple streams is applied. Offered Vector
Expected Delay Vector
This term captures the expected forwarding behavior from the 3.4.3.8. Expected Instantaneous Jitter Vector
DUT receiving multiple Offered Vectors. The actual algorithm
or mechanism the DUT uses to achieve service differentiation
is implementation specific and not important when describing
the Expected Minimum Delay Vector.
Measurement units: Definition:
milliseconds A description of the expected Instantaneous Jitter between two
consecutive packets arrival times matching a specific
classification, such as DSCP.
See Also: Discussion:
Classification Instantaneous Jitter is the absolute value of the difference
Stream between the Forwarding Delay measurement of two packets belonging
Forwarding Delay to the same stream.
Intended Vector
Offered Vector
Expected Delay Vector
3.4.3.8 Expected Instantaneous Jitter Vector 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.
Definition: The Forwarding Vector may contain several Jitter Vectors. For n
A description of the expected instantaneous jitter between two packets received in a Forwarding Vector, there is a total of (n-1)
consecutive packets arrival times matching a specific Instantaneous Jitter Vectors.
classification, such as DSCP.
Discussion: Measurement units:
Instantaneous Jitter is the absolute value of the difference milliseconds
between the Forwarding Delay measurement of two packets
belonging to the same stream.
Network-layer Traffic Control Mechanisms See Also:
Classification
Stream
Jitter
Intended Vector
Offered Vector
The Forwarding Delay fluctuation between two consecutive 3.4.3.9. Expected Average Jitter Vector
packets in a stream is reported as the "Instantaneous
Jitter". Instantaneous Jitter can be expressed as
|D(i) - D(i-1)| where D equals the Forwarding Delay and i is
the test sequence number. Packets lost are not counted in
the measurement.
Forwarding Vector may contain several Jitter Vectors. For n Definition:
packets received in a Forwarding Vector, there is a total of A description of the expected average jitter for packets arriving
(n-1) Instantaneous Jitter Vectors. in a stream matching a specific classification, such as DSCP.
Measurement units: Discussion:
milliseconds Average Jitter Vector is the average of all the Instantaneous
Jitter Vectors measured during the test duration for the same
stream.
See Also: The value of the Expected Average Jitter Vector is dependent on
Classification the set of offered vectors and Classification configuration on the
Stream DUT/SUT. The DUT is configured in a certain way so that
Jitter classification occurs when a traffic mix consisting of multiple
Intended Vector streams is applied.
Offered Vector
3.4.3.9 Expected Average Jitter Vector 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.
Definition: Measurement units:
A description of the expected average jitter for packets milliseconds
arriving in a stream matching a specific classification, such
as DSCP.
Discussion: See Also:
Average Jitter Vector is the average of all the Instantaneous Classification
Jitter Vectors measured during the test duration for the same Stream
stream. Jitter
Intended Vector
Offered Vector
Expected Instantaneous Jitter Vector
The value of the Expected Average Jitter Vector is dependent 3.4.3.10. Expected Peak-to-peak Jitter Vector
on the set of offered vectors and Classification
configuration on the DUT/SUT. The DUT is configured in a
certain way in order that classification occurs when a
traffic mix consisting of multiple streams is applied.
This term captures the expected forwarding behavior from the Definition:
DUT receiving multiple Offered Vectors. The actual algorithm A description of the expected maximum variation in the Forwarding
or mechanism the DUT uses to achieve service differentiation Delay of packet arrival times for packets arriving in a stream
is implementation specific and not important when describing matching a specific classification, such as DSCP.
the Expected Average Jitter Vector.
Measurement units: Discussion:
milliseconds Peak-to-peak Jitter Vector is the maximum Forwarding Delay minus
Network-layer Traffic Control Mechanisms the minimum Forwarding Delay of the packets (in a vector)
forwarded by the DUT/SUT.
See Also: Peak-to-peak Jitter is not derived from the Instantaneous Jitter
Classification Vector. Peak-to-peak Jitter is based upon all the packets during
Stream the test duration, not just two consecutive packets.
Jitter
Intended Vector
Offered Vector
Expected Instantaneous Jitter Vector
3.4.3.10 Expected Peak-to-peak Jitter Vector 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.
Definition: This term captures the expected forwarding behavior from the DUT
A description of the expected maximum variation in the receiving multiple Offered Vectors. The actual algorithm or
Forwarding Delay of packet arrival times for packets mechanism the DUT uses to achieve service differentiation is
arriving in a stream matching a specific classification, implementation specific and is not important when describing the
such as DSCP. Expected Peak-to-peak Jitter Vector.
Discussion: Measurement units:
Peak-to-peak Jitter Vector is the maximum Forwarding Delay milliseconds
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 See Also:
Jitter Vector. Peak-to-peak Jitter is based upon all the Classification
packets during the test duration, not just two consecutive Stream
packets. Jitter
Intended Vector
Offered Vector
Expected Instantaneous Jitter Vector
Expected Average Jitter Vector
The value of the Expected Peak-to-peak Jitter Vector is 3.4.4. Output Vectors
dependent on the set of offered vectors and Classification
configuration on the DUT/SUT. The DUT is configured in a
certain way in order that classification occurs when a
traffic mix consisting of multiple streams is applied.
This term captures the expected forwarding behavior from the 3.4.4.1. Forwarding Vector
DUT receiving multiple Offered Vectors. The actual algorithm
or mechanism the DUT uses to achieve service differentiation
is implementation specific and not important when describing
the Expected Peak-to-peak Jitter Vector.
Measurement units: Definition:
milliseconds 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.
See Also: Discussion:
Classification Forwarding Vector is expressed as a combination of values: the
Stream classification rules AND the measured packets per second for the
Jitter stream matching the classification rules. Forwarding Vector is a
Intended Vector per-hop measurement. The DUT/SUT MAY remark the specific DSCP (or
Offered Vector IP precedence) value for a multi-hop measurement. The stream
Expected Instantaneous Jitter Vector remains the same.
Expected Average Jitter Vector
Network-layer Traffic Control Mechanisms
3.4.4 Output Vectors Measurement units:
3.4.4.1 Forwarding Vector N-octet packets per second
Definition:
The number of packets per second for a stream matching a
specific classification, such as DSCP, that a DUT/SUT
is measured to successfully forward to the correct
destination interface in response to an offered vector.
Discussion: See Also:
Forwarding Vector is expressed as a combination of values: Classification
the classification rules AND the measured packets per Stream
second for the stream matching the classification rules. Forwarding Capacity
Forwarding Vector is a per-hop measurement. The DUT/SUT Intended Vector
MAY remark the specific DSCP (or IP precedence) value for Offered Vector
a multi-hop measurement. The stream remains the same. Expected Vector
Measurement units: 3.4.4.2. Loss Vector
N-octet packets per second
See Also: Definition:
Classification The percentage of packets per second for a stream matching a
Stream specific classification, such as DSCP, that a DUT/SUT is measured
Forwarding Capacity not to transmit to the correct destination interface in response
Intended Vector to an offered vector.
Offered Vector
Expected Vector
3.4.4.2 Loss Vector Discussion:
Definition: Loss Vector is expressed as a combination of values: the
The percentage of packets per second for a stream classification rules AND the measured percentage value of packet
matching a specific classification, such as DSCP, that loss. Loss Vector is a per-hop measurement. The DUT/SUT MAY
a DUT/SUT is measured to not transmit to the correct remark the specific DSCP or IP precedence value for a multi-hop
destination interface in response to an offered vector. measurement. The stream remains the same.
Discussion: Measurement Units:
Loss Vector is expressed as a combination of values: Percentage of packets
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: See Also:
Percentage of packets Classification
Stream
Intended Vector
Offered Vector
Expected Vector
One-way Packet Loss Metric [Ka99]
See Also: 3.4.4.3. Sequence Vector
Classification
Stream
Intended Vector
Offered Vector
Expected Vector
One-way Packet Loss Metric [Ka99]
Network-layer Traffic Control Mechanisms
3.4.4.3 Sequence Vector Definition:
Definition: The number of packets per second for all packets in a stream
The number of packets per second for all packets in a matching a specific classification, such as DSCP, that a DUT/SUT
stream matching a specific classification, such as DSCP, is measured to transmit in sequence to the correct destination
that a DUT/SUT is measured to transmit in sequence to the interface in response to an offered vector.
correct destination interface in response to an offered
vector.
Discussion: Discussion:
Sequence Vector is expressed as a combination of values: Sequence Vector is expressed as a combination of values: the
the classification rules AND the number of packets per classification rules AND the number of packets per second that are
second that are in-sequence. in-sequence.
Sequence Vector is a per-hop measurement. The DUT/SUT Sequence Vector is a per-hop measurement. The DUT/SUT MAY remark
MAY remark the specific DSCP or IP precedence value for the specific DSCP or IP precedence value for a multi-hop
a multi-hop measurement. The stream remains the same. measurement. The stream remains the same.
Measurement Units: Measurement Units:
N-octet packets per second N-octet packets per second
See Also: See Also:
Classification Classification
Stream Stream
In-sequence Packet In-sequence Packet
Intended Vector Intended Vector
Offered Vector Offered Vector
Expected Vector Expected Vector
3.4.4.4 Instantaneous Delay Vector 3.4.4.4. Instantaneous Delay Vector
Definition:
The instantaneous Forwarding Delay for a packet in a
stream matching a specific classification, such as DSCP,
that a DUT/SUT is measured to successfully transmit to the
correct destination interface in response to an offered
vector.
Discussion: Definition:
Instantaneous Delay Vector is expressed as a combination The instantaneous Forwarding Delay for a packet in a stream
of values: the classification rules AND Forwarding Delay. matching a specific classification, such as DSCP, that a DUT/SUT
For every packet received in a Forwarding Vector, there is measured to transmit to the correct destination interface
is a corresponding Instantaneous Delay Vector. successfully in response to an offered vector.
Instantaneous Delay Vector is a per-hop measurement. The Discussion:
DUT/SUT MAY remark the specific DSCP or IP precedence value Instantaneous Delay Vector is expressed as a combination of
for a multi-hop measurement. The stream remains the same. 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 can be obtained at any offered Instantaneous Delay Vector is a per-hop measurement. The DUT/SUT
load. It is RECOMMENDED to obtain this vector at or below MAY remark the specific DSCP or IP precedence value for a multi-
the Forwarding Capacity in the absence of Forwarding hop measurement. The stream remains the same.
Congestion. For congested Forwarding Delay, run the
offered load above the Forwarding Capacity.
Network-layer Traffic Control Mechanisms 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: Measurement Units:
milliseconds milliseconds
See Also: See Also:
Classification Classification
Stream Stream
Forwarding Capacity Forwarding Capacity
Forwarding Delay Forwarding Delay
Intended Vector Intended Vector
Offered Vector Offered Vector
Expected Delay Vector Expected Delay Vector
3.4.4.5 Average Delay Vector 3.4.4.5. Average Delay Vector
Definition: Definition:
The average Forwarding Delay for packets in a stream The average Forwarding Delay for packets in a stream matching a
matching a specific classification, such as DSCP, that specific classification, such as DSCP, that a DUT/SUT is measured
a DUT/SUT is measured to successfully transmit to the to transmit to the correct destination interface successfully in
correct destination interface in response to an offered response to an offered vector.
vector.
Discussion: Discussion:
Average Delay Vector is expressed as combination of values: Average Delay Vector is expressed as combination of values: the
the classification rules AND average Forwarding Delay. classification rules AND average Forwarding Delay.
The average Forwarding Delay is computed by averaging all The average Forwarding Delay is computed by averaging all the
the Instantaneous Delay Vectors for a given stream. Instantaneous Delay Vectors for a given stream.
Average Delay Vector is a per-hop measurement. The DUT/SUT Average Delay Vector is a per-hop measurement. The DUT/SUT MAY
MAY remark the specific DSCP or IP precedence value for a remark the specific DSCP or IP precedence value for a multi-hop
multi-hop measurement. The stream remains the same. measurement. The stream remains the same.
Average Delay Vector can be obtained at any offered load. Average Delay Vector can be obtained at any offered load. It is
Recommend at or below the Forwarding Capacity in the recommended that the offered load be at or below the Forwarding
absence of congestion. For congested Forwarding Delay, run Capacity in the absence of congestion. For congested Forwarding
the offered load above the Forwarding Capacity. Delay, run the offered load above the Forwarding Capacity.
Measurement Units: Measurement Units:
milliseconds milliseconds
See Also: See Also:
Classification Classification
Stream Stream
Forwarding Capacity Forwarding Capacity
Forwarding Delay Forwarding Delay
Intended Vector Intended Vector
Offered Vector Offered Vector
Expected Delay Vector Expected Delay Vector
Instantaneous Delay Vector Instantaneous Delay Vector
Network-layer Traffic Control Mechanisms
3.4.4.6 Maximum Delay Vector 3.4.4.6. Maximum Delay Vector
Definition:
The maximum Forwarding Delay for packets in a stream
matching a specific classification, such as DSCP, that
a DUT/SUT is measured to successfully transmit to the
correct destination interface in response to an offered
vector.
Discussion: Definition:
Maximum Delay Vector is expressed as combination of values: The maximum Forwarding Delay for packets in a stream matching a
the classification rules AND maximum Forwarding Delay. 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.
The maximum Forwarding Delay is computed by selecting the Discussion:
highest value from the Instantaneous Delay Vectors for a Maximum Delay Vector is expressed as combination of values: the
given stream. classification rules AND maximum Forwarding Delay.
Maximum Delay Vector is a per-hop measurement. The DUT/SUT The maximum Forwarding Delay is computed by selecting the highest
MAY remark the specific DSCP or IP precedence value for a value from the Instantaneous Delay Vectors for a given stream.
multi-hop measurement. The stream remains the same.
Maximum Delay Vector can be obtained at any offered load. Maximum Delay Vector is a per-hop measurement. The DUT/SUT MAY
Recommend at or below the Forwarding Capacity in the remark the specific DSCP or IP precedence value for a multi-hop
absence of congestion. For congested Forwarding Delay, run measurement. The stream remains the same.
the offered load above the Forwarding Capacity.
Measurement Units: Maximum Delay Vector can be obtained at any offered load. It is
milliseconds 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.
See Also: Measurement Units:
Classification milliseconds
Stream
Forwarding Capacity
Forwarding Delay
Intended Vector
Offered Vector
Expected Delay Vector
Instantaneous Delay Vector
3.4.4.7 Minimum Delay Vector See Also:
Definition: Classification
The minimum Forwarding Delay for packets in a stream Stream
matching a specific classification, such as DSCP, that Forwarding Capacity
a DUT/SUT is measured to successfully transmit to the Forwarding Delay
correct destination interface in response to an offered Intended Vector
vector. Offered Vector
Expected Delay Vector
Instantaneous Delay Vector
Discussion: 3.4.4.7. Minimum Delay Vector
Minimum Delay Vector is expressed as a combination of
values: the classification rules AND maximum Forwarding
Delay. The minimum Forwarding Delay is computed by
selecting the highest value from the Instantaneous Delay
Vectors for a given stream.
Network-layer Traffic Control Mechanisms 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.
Minimum Delay Vector is a per-hop measurement. The DUT/SUT Discussion:
MAY remark the specific DSCP or IP precedence value for a Minimum Delay Vector is expressed as a combination of values: the
multi-hop measurement. The stream remains the same. 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 can be obtained at any offered load. Minimum Delay Vector is a per-hop measurement. The DUT/SUT MAY
Recommend at or below the Forwarding Capacity in the remark the specific DSCP or IP precedence value for a multi-hop
absence of congestion. For congested Forwarding Delay, run measurement. The stream remains the same.
the offered load above the Forwarding Capacity.
Measurement Units: Minimum Delay Vector can be obtained at any offered load. It is
milliseconds 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.
See Also: Measurement Units:
Classification milliseconds
Stream
Forwarding Capacity
Forwarding Delay
Intended Vector
Offered Vector
Expected Delay Vector
3.4.4.8 Instantaneous Jitter Vector See Also:
Definition: Classification
The jitter for two consecutive packets in a Stream
stream matching a specific classification, such as DSCP, Forwarding Capacity
that a DUT/SUT is measured to successfully transmit to the Forwarding Delay
correct destination interface in response to an offered Intended Vector
vector. Offered Vector
Expected Delay Vector
Discussion: 3.4.4.8. Instantaneous Jitter Vector
Instantaneous Jitter is the absolute value of the difference
between the Forwarding Delay measurement of two packets
belonging to the same stream.
Jitter vector is expressed as pair of numbers. Both the Definition:
specific DSCP (or IP precedence) value AND jitter value The jitter for two consecutive packets in a stream matching a
combine to make a vector. 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.
The Forwarding Delay fluctuation between two consecutive Discussion:
packets in a stream is reported as the "Instantaneous Jitter". Instantaneous Jitter is the absolute value of the difference
Instantaneous Jitter Vector can be expressed as between the Forwarding Delay measurement of two packets belonging
|D(i) - D(i-1)| where D equals the Forwarding Delay and i is to the same stream.
the test sequence number. Packets lost are not counted in
the measurement.
Instantaneous Jitter Vector is a per-hop measurement. The The Instantaneous Jitter vector is expressed as a pair of numbers.
DUT/SUT MAY remark the specific DSCP or IP precedence value Both the specific DSCP (or IP precedence) value AND jitter value
for a multi-hop measurement. The stream remains the same. combine to make a vector.
There may be several Instantaneous Jitter Vectors for a The Forwarding Delay fluctuation between two consecutive packets
single stream. For n packets measured, there may be (n-1) in a stream is reported as the "Instantaneous Jitter".
Instantaneous Jitter Vectors. 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.
Network-layer Traffic Control Mechanisms 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.
Measurement units: There may be several Instantaneous Jitter Vectors for a single
milliseconds stream. For n packets measured, there may be (n-1) Instantaneous
Jitter Vectors.
See Also: Measurement units:
Classification milliseconds
Stream
Forwarding Delay
Jitter
Forwarding Vector
Expected Vectors
3.4.4.9 Average Jitter Vector See Also:
Classification
Stream
Forwarding Delay
Jitter
Forwarding Vector
Expected Vectors
Definition: 3.4.4.9. Average Jitter Vector
The average jitter for packets in a stream matching a
specific classification, such as DSCP, that a DUT/SUT is
measured to successfully transmit to the correct
destination interface in response to an offered vector.
Discussion: Definition:
Average jitter is calculated by the average of all the The average jitter for packets in a stream matching a specific
Instantaneous Jitter Vectors of the same stream measured classification, such as DSCP, that a DUT/SUT is measured to
during the test duration. Average Jitter Vector is transmit to the correct destination interface successfully in
expressed as a combination of values: the response to an offered vector.
classification rules AND average Jitter.
Average Jitter vector is a per-hop measurement. The Discussion:
DUT/SUT MAY remark the specific DSCP or IP precedence value Average jitter is calculated by the average of all the
for a multi-hop measurement. The stream remains the same. 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.
Measurement units: Average Jitter Vector is a per-hop measurement. The DUT/SUT MAY
milliseconds remark the specific DSCP or IP precedence value for a multi-hop
measurement. The stream remains the same.
See Also: Measurement units:
Classification milliseconds
Stream
Jitter
Forwarding Vector
Expected Vector
Instantaneous Jitter Vector
3.4.4.10 Peak-to-peak Jitter Vector See Also:
Classification
Stream
Jitter
Forwarding Vector
Expected Vector
Instantaneous Jitter Vector
Definition: 3.4.4.10. Peak-to-peak Jitter Vector
The maximum possible variation in the Forwarding Delay for
packets in a stream matching a specific classification,
such as DSCP, that a DUT/SUT is measured to successfully
transmit to the correct destination interface in response
to an offered vector.
Network-layer Traffic Control Mechanisms 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.
Discussion: Discussion:
Peak-to-peak Jitter Vector is calculated by subtracting Peak-to-peak Jitter Vector is calculated by subtracting the
the maximum Forwarding Delay from the minimum Forwarding maximum Forwarding Delay from the minimum Forwarding Delay of the
Delay of the packets forwarded by the DUT/SUT. Jitter packets forwarded by the DUT/SUT. Jitter vector is expressed as a
vector is expressed as a combination of values: the combination of values: the classification rules AND peak-to-peak
classification rules AND peak-to-peak Jitter. Jitter.
Peak-to-peak Jitter is not derived from the Instantaneous Peak-to-peak Jitter is not derived from the Instantaneous Jitter
Jitter Vector. Peak-to-peak Jitter is based upon all the Vector. Peak-to-peak Jitter is based upon all the packets during
packets during the test duration, not just two consecutive the test duration, not just two consecutive packets.
packets.
Measurement units: Measurement units:
milliseconds milliseconds
See Also: See Also:
Jitter Jitter
Forwarding Vector Forwarding Vector
Stream Stream
Expected Vectors Expected Vectors
Instantaneous Jitter Vector Instantaneous Jitter Vector
Average Jitter Vector Average Jitter Vector
4. IANA Considerations 4. Security Considerations
This document requires no IANA considerations. Documents of this type do not directly affect the security of the
Internet or of corporate networks as long as benchmarking is not
performed on devices or systems connected to production networks.
5. Security Considerations 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.
Documents of this type do not directly affect the security of 5. Acknowledgements
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 The authors gratefully acknowledge the contributions of the IETF's
precedence values may present security issues. Determining Benchmarking Methodology Working Group members in reviewing this
the security consequences of such packets is out of scope for document. The authors would like to express our thanks to David
this document. 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.
6. Acknowledgments 6. References
The authors gratefully acknowledge the contributions of the 6.1. Normative References
IETF's benchmarking working group members in reviewing this
document. The authors would like to express our thanks to
David Newman for his consistent and valuable assistance
throughout the development of this document. The authors
would also like to thank Al Morton (acmorton@att.com) and
Kevin Dubray (kdubray@juniper.net) for their ideas and
support.
Network-layer Traffic Control Mechanisms [Br91] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991.
7. References [Br97] Bradner, S., "Key words for use in RFCs to Indicate
7.1 Normative References Requirement Levels", BCP 14, RFC 2119, March 1997.
[Br91] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991.
[Br97] Bradner, S., "Key words for use in RFCs to Indicate [Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Requirement Levels", RFC 2119, March 1997 Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,
J., and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B., [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching
Deering, S., Estrin, D., Floyd, S., Jacobson, V., Devices", RFC 2285, February 1998.
Minshall, G., Partridge, C., Peterson, L., Ramakrishnan,
K., Shenker, S., Wroclawski, J. and L. Zhang,
"Recommendations on Queue Management and Congestion
Avoidance in the Internet", RFC 2309, April 1998.
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN [Ni98] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition
Switching Devices", RFC 2285, July 1998. of the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers", RFC 2474, December 1998.
[Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition [St91] Steinberg, L., "Techniques for managing asynchronously
of the Differentiated Services Field (DS Field) in the generated alerts", RFC 1224, May 1991.
IPv4 and IPv6 Headers", RFC 2474, December 1998.
[St91] Steinberg, L., "Techniques for Managing Asynchronously 6.2. Informative References
Generated Alerts", RC 1224, May 1991.
7.2 Informative References [Al99] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay
[Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
Metric for IPPM", RFC 2679, September 1999
[Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and
Weiss, W., "An Architecture for Differentiated Services", W. Weiss, "An Architecture for Differentiated Service", RFC
RFC 2475, December 1998. 2475, December 1998.
[Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for [Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999 Network Interconnect Devices", RFC 2544, March 1999.
[De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation [De02] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IPPM", RFC 3393, November 2002 Metric for IP Performance Metrics (IPPM)", RFC 3393, November
2002.
[Ec98] http://www3.ietf.org/proceedings/98mar/ [Ec98] http://www3.ietf.org/proceedings/98mar/98mar-edited-135.htm
98mar-edited-135.htm
[Fl93] Floyd, S., and Jacobson, V., "Random Early Detection [Fl93] Floyd, S., and Jacobson, V., "Random Early Detection gateways
gateways for Congestion Avoidance", IEEE/ACM for Congestion Avoidance", IEEE/ACM Transactions on
Transactions on Networking, V.1 N.4, August 1993, p. Networking, V.1 N.4, August 1993, p. 397-413. URL
397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf". "ftp://ftp.ee.lbl.gov/papers/early.pdf".
[Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited [Ja99] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec,
Forwarding PHB", RFC 2598, June 1999 J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis,
"An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
March 2002.
[Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way [Ka99] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet
Packet Loss Metric for IPPM", RFC 2680, September 1999 Loss Metric for IPPM", RFC 2680, September 1999.
Network-layer Traffic Control Mechanisms
[Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control [Ma91] Mankin, A. and K. Ramakrishnan, "Gateway Congestion Control
Survey", RFC 1254, August 1991 Survey", RFC 1254, August 1991.
[Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for [Ma00] Mandeville, R. and J. Perser, "Benchmarking Methodology for
LAN Switching Devices", RFC 2889, August 2000 LAN Switching Devices", RFC 2889, August 2000.
[Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, [Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.,
S., Perser, J., "Packet Reordering Metric for IPPM", Perser, J., "Packet Reordering Metric for IPPM", Work in
Work in Progress Progress.
[Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", [Na84] Nagle, J., "Congestion control in IP/TCP internetworks", RFC
RFC 896, January 1984. 896, January 1984.
[Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add [Ra99] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 2481, Explicit Congestion Notification (ECN) to IP", RFC 3168,
January 1999. September 2001.
[Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., [Sc96] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications", STD
RFC 1889, January 1996 64, RFC 3550, July 2003.
8. Authors' Addresses Authors' Addresses
Jerry Perser Jerry Perser
Veriwave Veriwave
USA 8770 SW Nimbus Ave.
EMail: jperser@veriwave.com Suite B
Beaverton, OR 97008 USA
USA
Scott Poretsky Phone: + 1 818 338 4112
Reef Point Systems EMail: jerry@perser.org
8 New England Executive Park
Burlington, MA 01803
USA
Phone: + 1 508 439 9008
EMail: sporetsky@reefpoint.com
Shobha Erramilli Scott Poretsky
Telcordia Technologies Reef Point Systems
331 Newman Springs Road 8 New England Executive Park
Red Bank, New Jersey 07701 Burlington, MA 01803
USA USA
Email: shobha@research.telcordia.com
Sumit Khurana Phone: + 1 508 439 9008
Telcordia Technologies EMail: sporetsky@reefpoint.com
445 South Street
Morristown, NJ 07960 Shobha Erramilli
USA Telcordia Technologies
Phone: + 1 973 829 3170 331 Newman Springs Road
EMail: sumit@research.telcordia.com Red Bank, New Jersey 07701
Network-layer Traffic Control Mechanisms 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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 32, line 43 skipping to change at page 34, line 42
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society. Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 319 change blocks. 
1260 lines changed or deleted 1167 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/