draft-ietf-bmwg-dsmterm-09.txt   draft-ietf-bmwg-dsmterm-10.txt 
Network Working Group Jerry Perser Network Working Group Jerry Perser
INTERNET-DRAFT INTERNET-DRAFT
Expires in: April 2004 Scott Poretsky Expires in: October 2005 Scott Poretsky
Quarry Technologies Quarry Technologies
Shobha Erramilli Shobha Erramilli
Qnetworx Qnetworx
Sumit Khurana Sumit Khurana
Telcordia Telcordia
October 2003 February 2005
Terminology for Benchmarking Network-layer Terminology for Benchmarking Network-layer
Traffic Control Mechanisms Traffic Control Mechanisms
<draft-ietf-bmwg-dsmterm-09.txt> <draft-ietf-bmwg-dsmterm-10.txt>
Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be disclosed,
in accordance with RFC 3668.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-Drafts
Drafts as reference material or to cite them other than as "work as reference material or to cite them other than as "work in
in progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes terminology for the benchmarking of This document describes terminology for the benchmarking of
devices that implement traffic control based on IP precedence or devices that implement traffic control based on IP precedence or
diff-serv code point criteria. diff-serv code point criteria. The terminology is to be applied
to measurements made on the data plane to evaluate IP traffic
control meachanisms.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
Table of Contents Table of Contents
1. Introduction .............................................. 3 1. Introduction .............................................. 3
2. Existing definitions ...................................... 3 2. Existing definitions ...................................... 3
3. Term definitions............................................4 3. Term definitions............................................4
3.1 Configuration Terms 3.1 Configuration Terms
3.1.1 Classification.........................................4 3.1.1 Classification.........................................4
3.1.2 Codepoint Set..........................................4 3.1.2 Codepoint Set..........................................4
3.1.3 Forwarding Congestion..................................5 3.1.3 Forwarding Congestion..................................5
3.1.4 Congestion Management..................................6 3.1.4 Congestion Management..................................6
3.1.5 Flow...................................................7 3.1.5 Flow...................................................7
3.2 Measurement Terms 3.2 Measurement Terms
skipping to change at page 1, line 136 skipping to change at page 3, line 35
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 DUT/SUT. without congestion of the DUT/SUT.
This document describes only those terms relevant to measuring This document describes only those terms relevant to measuring
behavior of a device or a group of devices using one of these two behavior of a device or a group of devices using one of these two
mechanisms. End-to-end and service-level measurements are beyond mechanisms. End-to-end and service-level measurements are beyond
the scope of this document. the scope of this document.
2. Existing definitions 2. Existing definitions
RFC 1242 "Benchmarking Terminology for Network Interconnect RFC 1242 "Benchmarking Terminology for Network Interconnect
Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching
Devices" should be consulted before attempting to make use of this Devices" SHOULD be consulted before attempting to make use of this
document. document.
RFC 2474 "Definition of the Differentiated Services Field (DS RFC 2474 "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers" section 2, contains Field) in the IPv4 and IPv6 Headers" section 2, contains
discussions of a number of terms relevant to network-layer traffic discussions of a number of terms relevant to network-layer traffic
control mechanisms and should also be consulted. control mechanisms and SHOULD also be consulted.
For the sake of clarity and continuity this RFC adopts the For the sake of clarity and continuity this RFC adopts the
template for definitions set out in Section 2 of RFC 1242. template for definitions set out in Section 2 of RFC 1242.
Definitions are indexed and grouped together in sections for ease Definitions are indexed and grouped together in sections for ease
of reference. of reference.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described in document are to be interpreted as described in BCP 14, RFC 2119
RFC 2119 [Br97]. [Br97]. RFC 2119 defines the use of these key words to help make the
intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track
document.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
3. Term definitions 3. Term definitions
3.1 Configuration Terms 3.1 Configuration Terms
3.1.1 Classification 3.1.1 Classification
Definition: Definition:
Selection of packets based on the contents of packet header Selection of packets based on the contents of packet header
according to defined rules. according to defined rules.
Discussion: Discussion:
Packets can be selected based on the DS field or IP Packets can be selected based on the DS field or IP
Precedence in the packet header. Classification can also be Precedence in the packet header. Classification can also be
based on Multi-Field (MF) criteria such as IP Source and based on Multi-Field (MF) criteria such as IP Source and
skipping to change at page 1, line 179 skipping to change at page 4, line 25
Discussion: Discussion:
Packets can be selected based on the DS field or IP Packets can be selected based on the DS field or IP
Precedence in the packet header. Classification can also be Precedence in the packet header. Classification can also be
based on Multi-Field (MF) criteria such as IP Source and based on Multi-Field (MF) criteria such as IP Source and
destination addresses, protocol and port number. destination addresses, protocol and port number.
Classification determines the per-hop behaviors and traffic Classification determines the per-hop behaviors and traffic
conditioning functions such as shaping and dropping that are conditioning functions such as shaping and dropping that are
to be applied to the packet. to be applied to the packet.
Measurement units: Measurement units: n/a
n/a
See Also: See Also:
3.1.2 Codepoint Set 3.1.2 Codepoint Set
Definition: Definition:
The set of all DS Code-points or IP precedence values used The set of all DS Code-points or IP precedence values used
during the test duration. during the test duration.
Discussion: Discussion:
skipping to change at page 1, line 203 skipping to change at page 4, line 48
codepoint set, there are associated vectors describing the codepoint set, there are associated vectors describing the
rate of traffic, delay, loss, or jitter containing that rate of traffic, delay, loss, or jitter containing that
particular DSCP or IP precedence value. particular DSCP or IP precedence value.
The treatment that a packet belonging to a particular code- The treatment that a packet belonging to a particular code-
point gets is subject to the DUT classifying packets to map point gets is subject to the DUT classifying packets to map
to the correct PHB. Moreover, the forwarding treatment in to the correct PHB. Moreover, the forwarding treatment in
general is also dependent on the complete set of offered general is also dependent on the complete set of offered
vectors. vectors.
Measurement Units: Measurement Units: n/a
n/a
See Also:
See Also: None
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
3.1.3 Forwarding Congestion 3.1.3 Forwarding Congestion
Definition: Definition:
A condition in which one or more egress interfaces are A condition in which one or more egress interfaces are
offered more packets than are forwarded. offered more packets than are forwarded.
Discussion: Discussion:
This condition is a superset of the overload definition This condition is a superset of the overload definition
skipping to change at page 1, line 271 skipping to change at page 6, line 19
with an infinite amount of memory could buffer an infinite with an infinite amount of memory could buffer an infinite
number of packets, and eventually forward all of them. number of packets, and eventually forward all of them.
However, these packets may or may not be forwarded during the However, these packets may or may not be forwarded during the
test duration. Even though ingress interfaces accept all test duration. Even though ingress interfaces accept all
packets without loss, Forwarding Congestion is present in packets without loss, Forwarding Congestion is present in
this hypothetical device. this hypothetical device.
Forwarding Congestion, indicated by occurrence of packet Forwarding Congestion, indicated by occurrence of packet
loss, is one type of congestion for a DUT/SUT. Congestion loss, is one type of congestion for a DUT/SUT. Congestion
Collapse [Na84] is defined as the state in which buffers are Collapse [Na84] is defined as the state in which buffers are
full and all arriving packets must be dropped across the full and all arriving packets MUST be dropped across the
network. Incipient Congestion [Ra99] is defined as network. Incipient Congestion [Ra99] is defined as
congestion that produces increased delay without packet loss. congestion that produces increased delay without packet loss.
The definition presented here explicitly defines Forwarding The definition presented here explicitly defines Forwarding
Congestion as an event observable on egress interfaces. Congestion as an event observable on egress interfaces.
Regardless of internal architecture, any device that cannot Regardless of internal architecture, any device that cannot
forward packets on one or more egress interfaces is under forward packets on one or more egress interfaces is under
Forwarding Congestion. Forwarding Congestion.
Measurement units: Measurement units:
skipping to change at page 1, line 296 skipping to change at page 6, line 44
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 minimize the condition of congestion. or minimize the condition of congestion.
Discussion: Discussion:
Congestion management may seek either to control congestion Congestion management may seek either to control congestion
or avoid it altogether. Such mechanisms classify packets or avoid it altogether. Such mechanisms classify packets
based upon IP Precedence or DSCP settings in a packetĂs IP based upon IP Precedence or DSCP settings in a packets IP
header. header.
Congestion avoidance mechanisms seek to prevent congestion Congestion avoidance mechanisms seek to prevent congestion
before it actually occurs. before 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 other classes during periods of congestion. over other classes during periods of congestion.
Measurement units: Measurement units:
skipping to change at page 1, line 324 skipping to change at page 7, line 18
Definition: Definition:
A flow is a one or more of packets sharing a common intended A flow is a one or more of packets sharing a common intended
pair of source and destination interfaces. pair of source and destination interfaces.
Discussion: Discussion:
Packets are grouped by the ingress and egress interfaces they Packets are grouped by the ingress and egress interfaces they
use on a given DUT/SUT. use 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 IP addresses. All packets in a flow must enter destination IP addresses. All packets in a flow MUST enter
on the same ingress interface and exit on the same egress on the same ingress interface and exit on the same egress
interface, and have some common network layer content. interface, and have 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], microflows require application-to-application [Ni98], microflows require application-to-application
measurement. In contrast, flows use lower-layer measurement. In contrast, flows use lower-layer
classification criteria. Since this document focuses on classification criteria. Since this document focuses on
network-layer classification criteria, we concentrate here on network-layer classification criteria, we concentrate here on
the use of network-layer identifiers in describing a flow. the use of network-layer identifiers in describing a flow.
Flow identifiers also may reside at the data-link, transport, Flow identifiers also may reside at the data-link, transport,
skipping to change at page 1, line 542 skipping to change at page 11, line 33
is the order the packets were received. is the order the packets were received.
Under loss, jitter can be measured between non-consecutive Under loss, jitter can be measured between non-consecutive
test sequence numbers. When Traffic Control Mechanisms are test sequence numbers. When Traffic Control Mechanisms are
losing packets, the Forwarding Delay may fluctuate as a losing packets, the Forwarding Delay may fluctuate as a
response. Jitter MUST be able to benchmark the delay response. Jitter MUST be able to benchmark the delay
variation with or with out loss. variation with or with out loss.
Jitter is related to the ipdv [De02] (IP Delay Variation) by Jitter is related to the ipdv [De02] (IP Delay Variation) by
taking the absolute value of the ipdv. The two metrics will taking the absolute value of the ipdv. The two metrics will
produce different mean values. ˘Mean Jitter÷ will produce a produce different mean values. Mean Jitter will produce a
positive value, where the ˘mean ipdv÷ is typically zero. positive value, where the mean ipdv is typically zero.
Measurement units: Measurement units:
Seconds Seconds
See Also: See Also:
Forwarding Delay Forwarding Delay
Jitter variation [Ja99] Jitter variation [Ja99]
ipdv [De02] ipdv [De02]
interarrival jitter [Sc96] interarrival jitter [Sc96]
skipping to change at page 1, line 568 skipping to change at page 12, line 7
serv or IP precedence are disabled. serv or IP precedence are disabled.
Discussion: Discussion:
Enabling diff-serv or IP precedence mechanisms may impose Enabling diff-serv or IP precedence mechanisms may impose
additional processing overhead for packets. This overhead additional processing overhead for packets. This overhead
may degrade performance even when traffic belonging to only may degrade performance even when traffic belonging to only
one class, the best-effort class, is offered to the device. one class, the best-effort class, is offered to the device.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
Measurements with "undifferentiated response" should be made Measurements with "undifferentiated response" SHOULD be made
to establish a baseline. to establish a baseline.
The vector(s) obtained with DSCP or IP precedence enabled can The vector(s) obtained with DSCP or IP precedence enabled can
be compared to the undifferentiated response to determine the be compared to the undifferentiated response to determine the
effect of differentiating traffic. effect of differentiating traffic.
Measurement units: Measurement units:
n/a n/a
3.3 Sequence Tracking 3.3 Sequence Tracking
3.3.1 In-sequence Packet 3.3.1 In-sequence Packet
Definition: Definition:
A received packet with the expected Test Sequence number. A received packet with the expected Test Sequence number.
Discussion: Discussion:
In-sequence is done on a stream level. As packets are In-sequence is done on a stream level. As packets are
received on a stream, each packetĂs Test Sequence number is received on a stream, each packets Test Sequence number is
compared with the previous packet. Only packets that match compared with the previous packet. Only packets that match
the expected Test Sequence number are considered in-sequence. the expected Test Sequence number are considered in-sequence.
Packets that do not match the expected Test Sequence number Packets that do not match the expected Test Sequence number
are counted as "not in-sequence" or out-of-sequence. Every are counted as "not in-sequence" or out-of-sequence. Every
packet that is received is either in-sequence or out-of- packet that is received is either in-sequence or out-of-
sequence. Subtracting the in-sequence from the received sequence. Subtracting the in-sequence from the received
packets (for that stream) can derive the out-of-sequence packets (for that stream) can derive the out-of-sequence
count. count.
skipping to change at page 1, line 692 skipping to change at page 14, line 34
3.3.4 Stream 3.3.4 Stream
Definition: Definition:
A group of packets tracked as a single entity by the traffic A group of packets tracked as a single entity by the traffic
receiver. A stream may share a common content such as type receiver. A stream may share a common content such as type
(IP, UDP), packet size, or payload. (IP, UDP), packet size, or payload.
Discussion: Discussion:
Streams are tracked by test sequence number or "unique Streams are tracked by test sequence number or "unique
signature field" [Ma00]. Streams define how individual signature field" [Ma00]. Streams define how individual
packetsĂ statistic are grouped together to form an packets statistic are grouped together to form an
intelligible summary. intelligible summary.
Common stream groupings would be by egress interface, Common stream groupings would be by egress interface,
destination address, source address, DSCP, or IP precedence. destination address, source address, DSCP, or IP precedence.
A stream using test sequence numbers can track the ordering A stream using test sequence numbers can track the ordering
of packets as they transverse the DUT/SUT. of packets as they transverse the DUT/SUT.
Streams are not restricted to a pair of source and Streams are not restricted to a pair of source and
destination interfaces as long as all packets are tracked as destination interfaces as long as all packets are tracked as
a single entity. A mulitcast stream can be forward to a single entity. A multicast stream can be forward to
multiple destination interfaces. multiple destination interfaces.
Measurement units: Measurement units:
n/a n/a
See Also: See Also:
Flow Flow
Microflow [Ni98] Microflow [Ni98]
Test sequence number Test sequence number
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
skipping to change at page 1, line 731 skipping to change at page 15, line 23
Discussion: Discussion:
The traffic generator sets the test sequence number value and The traffic generator sets the test sequence number value and
the traffic receiver checks the value upon receipt of the the traffic receiver checks the value upon receipt of the
packet. The traffic generator changes the value on each packet. The traffic generator changes the value on each
packet transmitted based on an algorithm agreed to by the packet transmitted based on an algorithm agreed to by the
traffic receiver. traffic receiver.
The traffic receiver keeps track of the sequence numbers on a The traffic receiver keeps track of the sequence numbers on a
per stream basis. In addition to number of received packets, per stream basis. In addition to number of received packets,
the traffic receiver may also report number of in-sequence the traffic receiver may also report number of in-sequence
packets, number of out-sequence packets, number of duplicate packets, number of out-of-sequence packets, number of duplicate
packets, and number of reordered packets. packets, and number of reordered packets.
The recommended algorithm to use to change the sequence The RECOMMENDED algorithm to use to change the sequence
number on sequential packets is an incrementing value. number on sequential packets is an incrementing value.
Measurement units: Measurement units:
n/a n/a
See Also: See Also:
Stream Stream
3.4 Vectors 3.4 Vectors
A vector is a group of packets all containing a specific DSCP A vector is a group of packets all containing a specific DSCP
skipping to change at page 1, line 840 skipping to change at page 17, line 35
Output Vectors Output Vectors
Expected Loss Vector Expected Loss Vector
Expected Sequence Vector Expected Sequence Vector
Expected Delay Vector Expected Delay Vector
Expected Jitter Vector Expected Jitter Vector
3.4.3.2 Expected Loss Vector 3.4.3.2 Expected Loss Vector
Definition: Definition:
A vector describing the percentage of packets, having a A vector describing the percentage of packets, having a
specific DSCP or IP precedence value, that should not be specific DSCP or IP precedence value that SHOULD not be
forwarded. The value is dependent on the set of offered forwarded. The value is dependent on the set of offered
vectors and configuration of the DUT. vectors and configuration of the DUT.
Discussion: Discussion:
The DUT is configured in a certain way in order that service The DUT is configured in a certain way in order that service
differentiation occurs for a particular DSCP or IP precedence differentiation occurs for a particular DSCP or IP precedence
value when a specific traffic mix consisting of multiple value when a specific traffic mix consisting of multiple
DSCPs or IP precedence values are applied. This term DSCPs or IP precedence values are applied. This term
attempts to capture the expected forwarding behavior when attempts to capture the expected forwarding behavior when
subjected to a certain offered vector. subjected to a certain offered vector.
skipping to change at page 1, line 1040 skipping to change at page 21, line 35
Output Vectors Output Vectors
Expected Loss Vector Expected Loss Vector
Expected Sequence Vector Expected Sequence Vector
Expected Forwarding Vector Expected Forwarding Vector
Expected Jitter Vector Expected Jitter Vector
3.4.3.8 Expected Instantaneous Jitter Vector 3.4.3.8 Expected Instantaneous Jitter Vector
Definition: Definition:
A vector describing the expected jitter between two A vector describing the expected jitter between two
consecutive packetsĂ arrival times having a specific DSCP or consecutive packets arrival times having a specific DSCP or
IP precedence value. The value is dependent on the set of IP precedence value. The value is dependent on the set of
offered vectors and configuration of the DUT. offered vectors and configuration of the DUT.
Discussion: Discussion:
Instantaneous Jitter is the absolute value of the difference Instantaneous Jitter is the absolute value of the difference
between the delay measurement of two packets belonging to the between the delay measurement of two packets belonging to the
same stream. same stream.
The delay fluctuation between two consecutive packets in a The delay fluctuation between two consecutive packets in a
stream is reported as the "Instantaneous Jitter". stream is reported as the "Instantaneous Jitter".
Instantaneous Jitter can be expressed as |D(i) - D(i-1)| Instantaneous Jitter can be expressed as |D(i) - D(i-1)|
where D equals the delay and i is the test sequence number. where D equals the delay and is the test sequence number.
Packets lost are not counted in the measurement. Packets lost are not counted in the measurement.
Forwarding Vector may contain several Jitter Vectors. For n Forwarding Vector may contain several Jitter Vectors. For n
packets received in a Forwarding Vector, there is a total of packets received in a Forwarding Vector, there is a total of
(n-1) Instantaneous Jitter Vectors. (n-1) Instantaneous Jitter Vectors.
Measurement units: Measurement units:
Seconds Seconds
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
skipping to change at page 1, line 1144 skipping to change at page 23, line 36
Discussion: Discussion:
Forwarding Vector is expressed as pair of numbers. Both the Forwarding Vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND the packets per specific DSCP (or IP precedence) value AND the packets per
second value combine to make a vector. second value combine to make a vector.
The Forwarding Vector represents packet rate based on its The Forwarding Vector represents packet rate based on its
specific DSCP (or IP precedence) value. It is not specific DSCP (or IP precedence) value. It is not
necessarily based on a stream or flow. The Forwarding Vector necessarily based on a stream or flow. The Forwarding Vector
may be expressed as per port of the DUT/SUT. However, it may be expressed as per port of the DUT/SUT. However, it
must be consistent with the Expected Forwarding Vector. MUST be consistent with the Expected Forwarding Vector.
Forwarding Vector is a per-hop measurement. The DUT/SUT may Forwarding Vector is a per-hop measurement. The DUT/SUT may
change the specific DSCP (or IP precedence) value for a change the specific DSCP (or IP precedence) value for a
multiple-hop measurement. multiple-hop measurement.
Measurement units: Measurement units:
N-octet packets per second N-octet packets per second
See Also: See Also:
Intended Vector Intended Vector
skipping to change at page 1, line 1178 skipping to change at page 24, line 22
vector. vector.
Discussion: Discussion:
Loss Vector is expressed as pair of numbers. Both the Loss Vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND the percentage specific DSCP (or IP precedence) value AND the percentage
value combine to make a vector. value combine to make a vector.
The Loss Vector represents percentage based on a specific The Loss Vector represents percentage based on a specific
DSCP or IP precedence value. It is not necessarily based on DSCP or IP precedence value. It is not necessarily based on
a stream or flow. The Loss Vector may be expressed as per a stream or flow. The Loss Vector may be expressed as per
port of the DUT/SUT. However, it must be consistent with the port of the DUT/SUT. However, it MUST be consistent with the
Expected Loss Vector Expected Loss Vector
Loss Vector is a per-hop measurement. The DUT/SUT may change Loss Vector is a per-hop measurement. The DUT/SUT may change
the specific DSCP or IP precedence value for a multiple-hop the specific DSCP or IP precedence value for a multiple-hop
measurement. measurement.
Measurement Units: Measurement Units:
Percentage of offered packets that is not forwarded. Percentage of offered packets that is not forwarded.
See Also: See Also:
skipping to change at page 1, line 1215 skipping to change at page 25, line 10
Discussion: Discussion:
Sequence Vector is expressed as pair of numbers. Both the Sequence Vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND the packets per specific DSCP (or IP precedence) value AND the packets per
second value combine to make a vector. second value combine to make a vector.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
The Sequence Vector represents packet rate based on its The Sequence Vector represents packet rate based on its
specific DSCP or IP precedence value. It is not necessarily specific DSCP or IP precedence value. It is not necessarily
based on a stream or flow. The Sequence Vector may be based on a stream or flow. The Sequence Vector may be
expressed as per port of the DUT/SUT. However, it must be expressed as per port of the DUT/SUT. However, it MUST be
consistent with the Expected Sequence Vector. consistent with the Expected Sequence Vector.
Sequence Vector is a per-hop measurement. The DUT/SUT may Sequence Vector is a per-hop measurement. The DUT/SUT may
change the specific DSCP or IP precedence value for a change the specific DSCP or IP precedence value for a
multiple-hop measurement. multiple-hop measurement.
Measurement Units: Measurement Units:
N-octet packets per second N-octet packets per second
Issues: Issues:
skipping to change at page 1, line 1252 skipping to change at page 25, line 47
response to an offered vector. response to an offered vector.
Discussion: Discussion:
Instantaneous Delay vector is expressed as pair of numbers. Instantaneous Delay vector is expressed as pair of numbers.
Both the specific DSCP (or IP precedence) value AND delay Both the specific DSCP (or IP precedence) value AND delay
value combine to make a vector. value combine to make a vector.
The Instantaneous Delay Vector represents delay on its The Instantaneous Delay Vector represents delay on its
specific DSCP or IP precedence value. It is not necessarily specific DSCP or IP precedence value. It is not necessarily
based on a stream or flow. The Delay vector may be expressed based on a stream or flow. The Delay vector may be expressed
as per port of the DUT/SUT. However, it must be consistent as per port of the DUT/SUT. However, it MUST be consistent
with the Expected Delay vectors. with the Expected Delay vectors.
Instantaneous Delay Vector is a per-hop measurement. The Instantaneous Delay Vector is a per-hop measurement. The
DUT/SUT may change the specific DSCP or IP precedence value DUT/SUT may change the specific DSCP or IP precedence value
for a multiple-hop measurement. for a multiple-hop measurement.
Instantaneous Delay vector can be obtained at any offered Instantaneous Delay vector can be obtained at any offered
load. RECOMMEND at or below the Forwarding Capacity in the load. RECOMMEND at or below the Forwarding Capacity in the
absence of forwarding congestion. For congested delay, run absence of forwarding congestion. For congested delay, run
the offered load above the Forwarding Capacity. the offered load above the Forwarding Capacity.
skipping to change at page 1, line 1342 skipping to change at page 27, line 31
response to an offered vector. response to an offered vector.
Discussion: Discussion:
Maximum Delay vector is expressed as pair of numbers. Both Maximum Delay vector is expressed as pair of numbers. Both
the specific DSCP (or IP precedence) value AND delay value the specific DSCP (or IP precedence) value AND delay value
combine to make a vector. combine to make a vector.
The Maximum Delay Vector represents delay on its specific The Maximum Delay Vector represents delay on its specific
DSCP or IP precedence value. It is not necessarily based on DSCP or IP precedence value. It is not necessarily based on
a stream or flow. The Maximum Delay vector may be expressed a stream or flow. The Maximum Delay vector may be expressed
as per port of the DUT/SUT. However, it must be consistent as per port of the DUT/SUT. However, it MUST be consistent
with the Expected Delay vector. with the Expected Delay vector.
Maximum Delay Vector is based upon the maximum Instantaneous Maximum Delay Vector is based upon the maximum Instantaneous
Delay Vector of all packets in a Forwarding Vector. Delay Vector of all packets in a Forwarding Vector.
Maximum Delay Vector is a per-hop measurement. The DUT/SUT Maximum Delay Vector is a per-hop measurement. The DUT/SUT
may change the specific DSCP or IP precedence value for a may change the specific DSCP or IP precedence value for a
multiple-hop measurement. multiple-hop measurement.
Measurement Units: Measurement Units:
skipping to change at page 1, line 1382 skipping to change at page 28, line 22
response to an offered vector. response to an offered vector.
Discussion: Discussion:
Delay vector is expressed as pair of numbers. Both the Delay vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND delay value specific DSCP (or IP precedence) value AND delay value
combine to make a vector. combine to make a vector.
The Minimum Delay Vector represents delay on its specific The Minimum Delay Vector represents delay on its specific
DSCP or IP precedence value. It is not necessarily based on DSCP or IP precedence value. It is not necessarily based on
a stream or flow. The Minimum Delay vector may be expressed a stream or flow. The Minimum Delay vector may be expressed
as per port of the DUT/SUT. However, it must be consistent as per port of the DUT/SUT. However, it MUST be consistent
with the Expected Delay vector. with the Expected Delay vector.
Minimum Delay Vector is based upon the minimum Instantaneous Minimum Delay Vector is based upon the minimum Instantaneous
Delay Vector of all packets in a Forwarding Vector. Delay Vector of all packets in a Forwarding Vector.
Minimum Delay Vector is a per-hop measurement. The DUT/SUT Minimum Delay Vector is a per-hop measurement. The DUT/SUT
may change the specific DSCP or IP precedence value for a may change the specific DSCP or IP precedence value for a
multiple-hop measurement. multiple-hop measurement.
Minimum Delay vector can be obtained at any offered load. Minimum Delay vector can be obtained at any offered load.
skipping to change at page 1, line 1431 skipping to change at page 29, line 18
Instantaneous Jitter is the absolute value of the difference Instantaneous Jitter is the absolute value of the difference
between the delay measurement of two packets belonging to the between the delay measurement of two packets belonging to the
same stream. same stream.
Jitter vector is expressed as pair of numbers. Both the Jitter vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND jitter value specific DSCP (or IP precedence) value AND jitter value
combine to make a vector. combine to make a vector.
The delay fluctuation between two consecutive packets in a The delay fluctuation between two consecutive packets in a
stream is reported as the "Instantaneous Jitter". stream is reported as the "Instantaneous Jitter".
Instantaneous Jitter Vector can be expressed as |D(i) - D(i- Instantaneous Jitter Vector can be expressed as |D(i) - D(i-1)|
1)| where D equals the delay and i is the test sequence where D equals the delay and i is the test sequence
number. Packets lost are not counted in the measurement. number. Packets lost are not counted in the measurement.
Instantaneous Jitter Vector is a per-hop measurement. The Instantaneous Jitter Vector is a per-hop measurement. The
DUT/SUT may change the specific DSCP or IP precedence value DUT/SUT may change the specific DSCP or IP precedence value
for a multiple-hop measurement. for a multiple-hop measurement.
Forwarding Vector may contain several Instantaneous Jitter Forwarding Vector may contain several Instantaneous Jitter
Vectors. For n packets received in a Forwarding Vector, Vectors. For n packets received in a Forwarding Vector,
there are exactly (n-1) Instantaneous Jitter Vectors. there are exactly (n-1) Instantaneous Jitter Vectors.
skipping to change at page 1, line 1468 skipping to change at page 29, line 55
The average jitter for packets containing a specific DSCP or The average jitter for packets containing a specific DSCP or
IP precedence value that a device can be observed to IP precedence value that a device can be observed to
successfully transmit to the correct destination interface in successfully transmit to the correct destination interface in
response to an offered vector. response to an offered vector.
Discussion: Discussion:
Average Jitter Vector is the average of all the Instantaneous Average Jitter Vector is the average of all the Instantaneous
Jitter Vectors of the same DSCP or IP precedence value, Jitter Vectors of the same DSCP or IP precedence value,
measured during the test duration. measured during the test duration.
Network-layer Traffic Control Mechanisms
Average Jitter vector is expressed as pair of numbers. Both Average Jitter vector is expressed as pair of numbers. Both
the specific DSCP (or IP precedence) value AND jitter value the specific DSCP (or IP precedence) value AND jitter value
combine to make a vector. combine to make a vector.
Network-layer Traffic Control Mechanisms
Average Jitter vector is a per-hop measurement. The DUT/SUT Average Jitter vector is a per-hop measurement. The DUT/SUT
may change the specific DSCP or IP precedence value for a may change the specific DSCP or IP precedence value for a
multiple-hop measurement. multiple-hop measurement.
Measurement units: Measurement units:
Seconds Seconds
See Also: See Also:
Jitter Jitter
Forwarding Vector Forwarding Vector
skipping to change at page 1, line 1618 skipping to change at page 33, line 17
Jerry Perser Jerry Perser
USA USA
Phone: Phone:
EMail: jerry@perser.org EMail: jerry@perser.org
Scott Poretsky Scott Poretsky
Quarry Technologies Quarry Technologies
New England Executive Park 8 New England Executive Park
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: + 1 781 359 5090 Phone: + 1 508 439 9008
EMail: sporetsky@quarrytech.com EMail: sporetsky@quarrytech.com
Shobha Erramilli Shobha Erramilli
QNetworx Inc QNetworx Inc
1119 Campus Drive West 1119 Campus Drive West
Morganville, NJ 07751 Morganville, NJ 07751
USA USA
Phone: Phone:
EMail: shobha@qnetworx.com EMail: shobha@qnetworx.com
skipping to change at page 1, line 1644 skipping to change at page 34, line 6
Sumit Khurana Sumit Khurana
Telcordia Technologies Telcordia Technologies
445 South Street 445 South Street
Morristown, NJ 07960 Morristown, NJ 07960
USA USA
Phone: + 1 973 829 3170 Phone: + 1 973 829 3170
EMail: sumit@research.telcordia.com EMail: sumit@research.telcordia.com
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
9. Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2003). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document
itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein
is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Network Working Group Jerry Perser
INTERNET-DRAFT
Expires in: April 2004 Scott Poretsky
Quarry Technologies
Shobha Erramilli
Qnetworx
Sumit Khurana
Telcordia
October 2003
Terminology for Benchmarking Network-layer
Traffic Control Mechanisms
<draft-ietf-bmwg-dsmterm-09.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes terminology for the benchmarking of
devices that implement traffic control based on IP precedence or
diff-serv code point criteria.
Network-layer Traffic Control Mechanisms
Table of Contents
1. Introduction .............................................. 3
2. Existing definitions ...................................... 3
3. Term definitions............................................4
3.1 Configuration Terms
3.1.1 Classification.........................................4
3.1.2 Codepoint Set..........................................4
3.1.3 Forwarding Congestion..................................5
3.1.4 Congestion Management..................................6
3.1.5 Flow...................................................7
3.2 Measurement Terms
3.2.1 Forwarding Capacity....................................7
3.2.2 Conforming Packet......................................8
3.2.3 Nonconforming Packet...................................9
3.2.4 Forwarding Delay.......................................9
3.2.5 Jitter................................................11
3.2.6 Undifferentiated Response.............................11
3.3 Sequence Tracking
3.3.1 In-sequence Packet....................................12
3.3.2 Out-of-order Packet...................................12
3.3.3 Duplicate Packet......................................13
3.3.4 Stream................................................14
3.3.5 Test Sequence number .................................15
3.4 Vectors...................................................15
3.4.1 Intended Vector.......................................15
3.4.2 Offered Vector........................................16
3.4.3 Expected Vectors
3.4.3.1 Expected Forwarding Vector........................16
3.4.3.2 Expected Loss Vector..............................17
3.4.3.3 Expected Sequence Vector..........................18
3.4.3.4 Expected Instantaneous Delay Vector...............18
3.4.3.5 Expected Average Delay Vector.....................19
3.4.3.6 Expected Maximum Delay Vector.....................10
3.4.3.7 Expected Minimum Delay Vector.....................20
3.4.3.8 Expected Instantaneous Jitter Vector..............21
3.4.3.9 Expected Average Jitter Vector....................22
3.4.3.10 Expected Peak-to-peak Jitter Vector..............22
3.4.4 Output Vectors
3.4.4.1 Forwarding Vector.................................23
3.4.4.2 Loss Vector.......................................24
3.4.4.3 Sequence Vector...................................24
3.4.4.4 Instantaneous Delay Vector........................25
3.4.4.5 Average Delay Vector..............................26
3.4.4.6 Maximum Delay Vector..............................27
3.4.4.7 Minimum Delay Vector..............................28
3.4.4.8 Instantaneous Jitter Vector.......................28
3.4.4.9 Average Jitter Vector.............................29
3.4.4.10 Peak-to-peak Jitter Vector.......................30
4. Acknowledgments............................................31
5. Security Considerations....................................31
6. Normative References.......................................31
Network-layer Traffic Control Mechanisms
7. Informative References.....................................32
8. Author's Address...........................................33
9. Full Copyright Statement...................................34
1. Introduction
New terminology is needed because most existing measurements
assume the absence of congestion and only a single per-hop-
behavior. This document introduces several new terms that will
allow measurements to be taken during periods of congestion.
Another key difference from existing terminology is the definition
of measurements as observed on egress as well as ingress of a
device/system under test. Again, the existence of congestion
requires the addition of egress measurements as well as those
taken on ingress; without observing traffic leaving a
device/system it is not possible to say whether traffic-control
mechanisms effectively dealt with congestion.
The principal measurements introduced in this document are vectors
for rate, delay, and jitter, all of which can be observed with or
without congestion of the DUT/SUT.
This document describes only those terms relevant to measuring
behavior of a device or a group of devices using one of these two
mechanisms. End-to-end and service-level measurements are beyond
the scope of this document.
2. Existing definitions
RFC 1242 "Benchmarking Terminology for Network Interconnect
Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching
Devices" should be consulted before attempting to make use of this
document.
RFC 2474 "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers" section 2, contains
discussions of a number of terms relevant to network-layer traffic
control mechanisms and should also be consulted.
For the sake of clarity and continuity this RFC adopts the
template for definitions set out in Section 2 of RFC 1242.
Definitions are indexed and grouped together in sections for ease
of reference.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [Br97].
Network-layer Traffic Control Mechanisms
3. Term definitions
3.1 Configuration Terms
3.1.1 Classification
Definition:
Selection of packets based on the contents of packet header
according to defined rules.
Discussion:
Packets can be selected based on the DS field or IP
Precedence in the packet header. Classification can also be
based on Multi-Field (MF) criteria such as IP Source and
destination addresses, protocol and port number.
Classification determines the per-hop behaviors and traffic
conditioning functions such as shaping and dropping that are
to be applied to the packet.
Measurement units:
n/a
See Also:
3.1.2 Codepoint Set
Definition:
The set of all DS Code-points or IP precedence values used
during the test duration.
Discussion:
Describes all the code-point markings associated with packets
that are input to the DUT/SUT. For each entry in the
codepoint set, there are associated vectors describing the
rate of traffic, delay, loss, or jitter containing that
particular DSCP or IP precedence value.
The treatment that a packet belonging to a particular code-
point gets is subject to the DUT classifying packets to map
to the correct PHB. Moreover, the forwarding treatment in
general is also dependent on the complete set of offered
vectors.
Measurement Units:
n/a
See Also:
Network-layer Traffic Control Mechanisms
3.1.3 Forwarding Congestion
Definition:
A condition in which one or more egress interfaces are
offered more packets than are forwarded.
Discussion:
This condition is a superset of the overload definition
[Ma98]. Overload [Ma98] deals with overloading input and
output interfaces beyond the maximum transmission allowed by
the medium. Forwarding congestion does not assume ingress
interface overload as the only source of overload on output
interfaces.
Another difference between Forwarding Congestion and overload
occurs when the SUT comprises multiple elements, in that
Forwarding Congestion may occur at multiple points. Consider
an SUT comprising multiple edge devices exchanging traffic
with a single core device. Depending on traffic patterns,
the edge devices may induce Forwarding Congestion on multiple
egress interfaces on the core device.
Packet Loss, not increased Delay, is the metric to indicate
the condition of Forwarding Congestion. Packet Loss is a
deterministic indicator of Forwarding Congestion. While
increased delay may be an indicator of Forwarding Congestion,
it is a non-deterministic indicator of Forwarding Congestion.
External observation of increased delay to indicate
congestion is in effect external observation of Incipient
Congestion.
[Ra99] implies that it is impractical to build a black-box
test to externally observe Incipient Congestion indicated by
increased delay in a router. [Ra99] introduces Explicit
Congestion Notification (ECN) as the externally observable,
deterministic method for indicating Incipient Congestion.
Because [Ra99] is an Experimental RFC with limited
deployment, ECN is not used for this particular methodology.
For the purpose of "black-box" testing a DUT/SUT, Packet Loss
as the indicator of Forwarding Congestion is used.
Throughput [Br91] defines the lower boundary of Forwarding
Congestion. Throughput is the maximum offered rate with no
Forwarding Congestion. At offered rates above throughput,
the DUT/SUT is considered to be in a state of Forwarding
Congestion.
Network-layer Traffic Control Mechanisms
Ingress observations alone are not sufficient to cover all
cases in which Forwarding Congestion may occur. A device
with an infinite amount of memory could buffer an infinite
number of packets, and eventually forward all of them.
However, these packets may or may not be forwarded during the
test duration. Even though ingress interfaces accept all
packets without loss, Forwarding Congestion is present in
this hypothetical device.
Forwarding Congestion, indicated by occurrence of packet
loss, is one type of congestion for a DUT/SUT. Congestion
Collapse [Na84] is defined as the state in which buffers are
full and all arriving packets must be dropped across the
network. Incipient Congestion [Ra99] is defined as
congestion that produces increased delay without packet loss.
The definition presented here explicitly defines Forwarding
Congestion as an event observable on egress interfaces.
Regardless of internal architecture, any device that cannot
forward packets on one or more egress interfaces is under
Forwarding Congestion.
Measurement units:
none
See Also:
Gateway Congestion Control Survey [Ma91]
3.1.4 Congestion Management
Definition:
An implementation of one or more per-hop-behaviors to avoid
or minimize the condition of congestion.
Discussion:
Congestion management may seek either to control congestion
or avoid it altogether. Such mechanisms classify packets
based upon IP Precedence or DSCP settings in a packetĂs IP
header.
Congestion avoidance mechanisms seek to prevent congestion
before it actually occurs.
Congestion control mechanisms give one or more flows (with a
discrete IP Precedence or DSCP value) preferential treatment
over other classes during periods of congestion.
Measurement units:
n/a
See Also:
Network-layer Traffic Control Mechanisms
3.1.5 Flow
Definition:
A flow is a one or more of packets sharing a common intended
pair of source and destination interfaces.
Discussion:
Packets are grouped by the ingress and egress interfaces they
use on a given DUT/SUT.
A flow can contain multiple source IP addresses and/or
destination IP addresses. All packets in a flow must enter
on the same ingress interface and exit on the same egress
interface, and have some common network layer content.
Microflows [Ni98] are a subset of flows. As defined in
[Ni98], microflows require application-to-application
measurement. In contrast, flows use lower-layer
classification criteria. Since this document focuses on
network-layer classification criteria, we concentrate here on
the use of network-layer identifiers in describing a flow.
Flow identifiers also may reside at the data-link, transport,
or application layers of the OSI model. However, identifiers
other than those at the network layer are out of scope for
this document.
A flow may contain a single code point/IP precedence value or
may contain multiple values destined for a single egress
interface. This is determined by the test methodology.
Measurement units:
n/a
See Also:
Microflow [Ni98]
Streams
3.2 Measurement Terms
3.2.1 Forwarding Capacity
Definition:
The number of packets per second that a device can be
observed to successfully transmit to the correct destination
interface in response to a specified offered load while the
device drops none of the offered packets.
Network-layer Traffic Control Mechanisms
Discussion:
Forwarding Capacity measures the packet rate at the egress
interface(s) of the DUT/SUT. In contrast, throughput as
defined in RFC 1242 measures the frame rate at the ingress
interface(s) of the DUT/SUT.
Ingress-based measurements do not account for queuing of the
DUT/SUT. Throughput rates can be higher than the Forwarding
Capacity because of queuing. The difference is dependent
upon test duration, packet rate, and queue size. Forwarding
Capacity, as an egress measurement, does take queuing into
account.
Understanding Forwarding Capacity is a necessary precursor to
any measurement involving Traffic Control Mechanisms. The
accompanying methodology document MUST take into
consideration Forwarding Capacity when determining the
expected forwarding vectors. When the sum of the expected
forwarding vectors on an interface exceeds the Forwarding
Capacity, the Forwarding Capacity will govern the forwarding
rate.
This measurement differs from forwarding rate at maximum
offered load (FRMOL) [Ma98] in that Forwarding Capacity
requires zero loss.
Measurement units:
N-octet packets per second
See Also:
Throughput [Br91]
Forwarding Rate at Maximum Offered Load [Ma98]
3.2.2 Conforming Packet
Definition:
Packets which lie within specific rate, delay, or jitter
bounds.
Discussion:
A DUT/SUT may be configured to allow a given traffic class to
consume a given amount of bandwidth, or to fall within
predefined delay or jitter boundaries. All packets that lie
within specified bounds are then said to be conforming,
whereas those outside the bounds are nonconforming.
Measurement units:
n/a
Network-layer Traffic Control Mechanisms
See Also:
Expected Vector
Forwarding Vector
Offered Vector
Nonconforming
3.2.3 Nonconforming Packet
Definition:
Packets that do not lie within specific rate, delay, or
jitter bounds.
Discussion:
A DUT/SUT may be configured to allow a given traffic class to
consume a given amount of bandwidth, or to fall within
predefined delay or jitter boundaries. All packets that do
not lie within these bounds are then said to be
nonconforming.
Measurement units:
n/a
See Also:
Expected Vector
Forwarding Vector
Offered Vector
Conforming
3.2.4 Forwarding Delay
Definition:
The time interval starting when the last bit of the input IP
packet is offered to the input port of the DUT/SUT and ending
when the last bit of the output IP packet is received from
the output port of the DUT/SUT.
Discussion:
The delay time interval MUST be externally observed. The
delay measurement MUST NOT include delays added by test bed
components other than the DUT/SUT, such as propagation time
introduced by cabling or non-zero delay added by the test
instrument.
Forwarding Delay differs from latency [Br91] and one-way
delay [Al99] in several key regards:
1. Latency [Br91] assumes knowledge of whether the DUT/SUT
uses "store and forward" or "bit forwarding" technology.
Forwarding Delay is the same metric, measured the same way,
regardless of the architecture of the DUT/SUT.
Network-layer Traffic Control Mechanisms
2. Forwarding Delay is a last-in, last-out (LILO)
measurement, unlike the last-in, first-out method [Br91] or
the first-in, last-out method [Al99].
The LILO method most closely simulates the way a network-
layer device actually processes an IP datagram. IP datagrams
are not passed up and down the stack unless they are
complete, and processing begins only once the last bit of the
IP datagram has been received.
Further, the LILO method has an additive property, where the
sum of the parts MUST equal the whole. This is a key
difference from [Br91] and [Al99]. For example, the delay
added by two DUTs MUST equal the sum of the delay of the
DUTs. This may or may not be the case with [Br91] and
[Al99].
3. Forwarding Delay measures the IP datagram only, unlike
[Br91], which also includes link layer overhead.
A metric focused exclusively on the Internet protocol
relieves the tester from specifying the start/end for every
link layer protocol that IP runs on. This avoids the need to
determine whether the start/stop delimiters are included. It
also allows the use of heterogeneous link layer protocols in
a test.
4. Forwarding Delay can be measured at any offered load,
whereas the latency methodology [Br99] recommends measurement
at, and only at, the throughput level. Comparing the
Forwarding Delay below the throughput to Forwarding Delay
above the Forwarding Capacity will give insight to the
traffic control mechanisms.
For example, non-congested delay may be measured with an
offered load that does not exceed the Forwarding Capacity,
while congested delay may involve an offered load that
exceeds Forwarding Capacity.
Note: Forwarding Delay SHOULD NOT be used as an absolute
indicator of DUT/SUT Forwarding Congestion. While Forwarding
Delay may rise when offered load nears or exceeds Forwarding
Capacity, there is no universal point at which Forwarding
Delay can be said to indicate the presence or absence of
Forwarding Congestion.
Measurement units:
Seconds.
Network-layer Traffic Control Mechanisms
See Also:
Latency [Br91]
Latency [Al99]
One-way Delay [Br99]
3.2.5 Jitter
Definition:
The absolute value of the difference between the arrival
delay of two consecutive received packets belonging to the
same stream.
Discussion:
The 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 delay and i
is the order the packets were received.
Under loss, jitter can be measured between non-consecutive
test sequence numbers. When Traffic Control Mechanisms are
losing packets, the Forwarding Delay may fluctuate as a
response. Jitter MUST be able to benchmark the delay
variation with or with out loss.
Jitter is related to the ipdv [De02] (IP Delay Variation) by
taking the absolute value of the ipdv. The two metrics will
produce different mean values. ˘Mean Jitter÷ will produce a
positive value, where the ˘mean ipdv÷ is typically zero.
Measurement units:
Seconds
See Also:
Forwarding Delay
Jitter variation [Ja99]
ipdv [De02]
interarrival jitter [Sc96]
3.2.6 Undifferentiated Response
Definition:
The vector(s) obtained when mechanisms used to support diff-
serv or IP precedence are disabled.
Discussion:
Enabling diff-serv or IP precedence mechanisms may impose
additional processing overhead for packets. This overhead
may degrade performance even when traffic belonging to only
one class, the best-effort class, is offered to the device.
Network-layer Traffic Control Mechanisms
Measurements with "undifferentiated response" should be made
to establish a baseline.
The vector(s) obtained with DSCP or IP precedence enabled can
be compared to the undifferentiated response to determine the
effect of differentiating traffic.
Measurement units:
n/a
3.3 Sequence Tracking
3.3.1 In-sequence Packet
Definition:
A received packet with the expected Test Sequence number.
Discussion:
In-sequence is done on a stream level. As packets are
received on a stream, each packetĂs Test Sequence number is
compared with the previous packet. Only packets that match
the expected Test Sequence number are considered in-sequence.
Packets that do not match the expected Test Sequence number
are counted as "not in-sequence" or out-of-sequence. Every
packet that is received is either in-sequence or out-of-
sequence. Subtracting the in-sequence from the received
packets (for that stream) can derive the out-of-sequence
count.
Two types of events will prevent the in-sequence from
incrementing: packet loss and reordered packets.
Measurement units:
Packet count
See Also:
Stream
Test Sequence number
3.3.2 Out-of-order Packet
Definition:
A received packet with a Test Sequence number less than
expected.
Network-layer Traffic Control Mechanisms
Discussion:
As a stream of packets enters a DUT/SUT, they include a
Stream Test Sequence number indicating the order the packets
were sent to the DUT/SUT. On exiting the DUT/SUT, these
packets may arrive in a different order. Each packet that
was re-ordered is counted as an Out-of-order Packet.
Certain streaming protocol (such as TCP) require the packets
to be in a certain order. Packets outside this are dropped
by the streaming protocols even though there were properly
received by the IP layer. The type of reordering tolerated
by a streaming protocol varies from protocol to protocol, and
also by implementation.
Out-of-order Packet count is based on the worst case
streaming protocol. It allows for no reordering.
Packet loss does not affect the Out-of-order Packet count.
Only packets that were not received in the order that they
were transmitted.
Measurement units:
Packet count
See Also:
Stream
Test Sequence number
Packet Reordering Metric for IPPM [Mo03]
3.3.3 Duplicate Packet
Definition:
A received packet with a Test Sequence number matching a
previously received packet.
Discussion:
A Duplicate Packet is a packet that the DUT/SUT has
successfully transmitted out an egress interface more than
once. The egress interface has previously forwarded this
packet.
A Duplicate Packet SHOULD be a bit for bit copy of an already
transmitted packet (including Test Sequence number). If the
Duplicate Packet traversed different paths through the
DUT/SUT, some fields (such as TTL or checksum) may have
changed.
Network-layer Traffic Control Mechanisms
A multicast packet is not a Duplicate Packet by definition.
For a given IP multicast group, a DUT/SUT SHOULD forward a
packet once on a given egress interface provided the path to
one or more multicast receivers is through that interface.
Several egress interfaces will transmit the same packet, but
only once per interface.
To detect a Duplicate Packet, each offered packet to the
DUT/SUT MUST contain a unique packet-by-packet identifier.
Measurement units:
Packet count
See Also:
Stream
Test Sequence number
3.3.4 Stream
Definition:
A group of packets tracked as a single entity by the traffic
receiver. A stream may share a common content such as type
(IP, UDP), packet size, or payload.
Discussion:
Streams are tracked by test sequence number or "unique
signature field" [Ma00]. Streams define how individual
packetsĂ statistic are grouped together to form an
intelligible summary.
Common stream groupings would be by egress interface,
destination address, source address, DSCP, or IP precedence.
A stream using test sequence numbers can track the ordering
of packets as they transverse the DUT/SUT.
Streams are not restricted to a pair of source and
destination interfaces as long as all packets are tracked as
a single entity. A mulitcast stream can be forward to
multiple destination interfaces.
Measurement units:
n/a
See Also:
Flow
Microflow [Ni98]
Test sequence number
Network-layer Traffic Control Mechanisms
3.3.5 Test Sequence number
Definition:
A field in the IP payload portion of the packet that is used
to verify the order of the packets on the egress of the
DUT/SUT.
Discussion:
The traffic generator sets the test sequence number value and
the traffic receiver checks the value upon receipt of the
packet. The traffic generator changes the value on each
packet transmitted based on an algorithm agreed to by the
traffic receiver.
The traffic receiver keeps track of the sequence numbers on a
per stream basis. In addition to number of received packets,
the traffic receiver may also report number of in-sequence
packets, number of out-sequence packets, number of duplicate
packets, and number of reordered packets.
The recommended algorithm to use to change the sequence
number on sequential packets is an incrementing value.
Measurement units:
n/a
See Also:
Stream
3.4 Vectors
A vector is a group of packets all containing a specific DSCP
or IP precedence value. Vectors are expressed as a pair of
numbers. The first is being the particular diff-serv value.
The second is the metric expressed as a rate, loss
percentage, delay, or jitter.
3.4.1 Intended Vector
Definition:
A vector describing the attempted rate at which packets
having a specific code-point (or IP precedence) are
transmitted to a DUT/SUT by an external source.
Discussion:
Intended loads across the different code-point classes
determine the metrics associated with a specific code-point
traffic class.
Measurement Units:
N-octets packets per second
Network-layer Traffic Control Mechanisms
See Also:
Offered Vector
Expected Forwarding Vector
Expected Loss Vector
Expected Sequence Vector
Expected Delay Vector
Expected Jitter Vector
Forwarding Vector
Loss Vector
3.4.2 Offered Vector
Definition:
A vector describing the measured rate at which packets having
a specific DSCP or IP precedence value are offered to the
DUT/SUT.
Discussion:
Offered loads across the different code-point classes,
constituting a code-point set, determine the metrics
associated with a specific code-point traffic class.
Measurement Units:
N-octets packets per second
See Also:
Expected Forwarding Vector
Expected Loss Vector
Expected Sequence Vector
Expected Delay Vector
Expected Jitter Vector
Forwarding Vector
Codepoint Set
3.4.3 Expected Vectors
3.4.3.1 Expected Forwarding Vector
Definition:
A vector describing the expected output rate of packets
having a specific DSCP or IP precedence value. The value is
dependent on the set of offered vectors and configuration of
the DUT.
Network-layer Traffic Control Mechanisms
Discussion:
The DUT is configured in a certain way in order that service
differentiation occurs for a particular DSCP or IP precedence
value when a specific traffic mix consisting of multiple
DSCPs or IP precedence values are applied. This term
attempts to capture the expected forwarding behavior when
subjected to a certain offered vectors.
The actual algorithm or mechanism the DUT uses to achieve
service differentiation is not important in describing the
expected forwarding vector.
Measurement units:
N-octet packets per second
See Also:
Intended Vector
Offered Vector
Output Vectors
Expected Loss Vector
Expected Sequence Vector
Expected Delay Vector
Expected Jitter Vector
3.4.3.2 Expected Loss Vector
Definition:
A vector describing the percentage of packets, having a
specific DSCP or IP precedence value, that should not be
forwarded. The value is dependent on the set of offered
vectors and configuration of the DUT.
Discussion:
The DUT is configured in a certain way in order that service
differentiation occurs for a particular DSCP or IP precedence
value when a specific traffic mix consisting of multiple
DSCPs or IP precedence values are applied. This term
attempts to capture the expected forwarding behavior when
subjected to a certain offered vector.
The actual algorithm or mechanism the DUT uses to achieve
service differentiation is not important in describing the
expected loss vector.
Measurement Units:
Percentage of intended packets that is expected to be
dropped.
Network-layer Traffic Control Mechanisms
See Also:
Intended Vector
Offered Vector
Expected Forwarding Vector
Expected Sequence Vector
Expected Delay Vector
Expected Jitter Vector
One-way Packet Loss Metric [Ka99]
3.4.3.3 Expected Sequence Vector
Definition:
A vector describing the expected in-sequence packets having a
specific DSCP or IP precedence value. The value is dependent
on the set of offered vectors and configuration of the DUT.
Discussion:
The DUT is configured in a certain way in order that service
differentiation occurs for a particular DSCP or IP precedence
value when a specific traffic mix consisting of multiple
DSCPs or IP precedence values are applied. This term
attempts to capture the expected forwarding behavior when
subjected to a certain offered vectors.
The actual algorithm or mechanism the DUT uses to achieve
service differentiation is not important in describing the
expected sequence vector.
Measurement Units:
N-octet packets per second
See Also:
Intended Vector
Offered Vector
Output Vectors
Expected Loss Vector
Expected Forwarding Vector
Expected Delay Vector
Expected Jitter Vector
3.4.3.4 Expected Instantaneous Delay Vector
Definition:
A vector describing the expected delay for packets having a
specific DSCP or IP precedence value. The value is dependent
on the set of offered vectors and configuration of the DUT.
Network-layer Traffic Control Mechanisms
Discussion:
The DUT is configured in a certain way in order that service
differentiation occurs for a particular DSCP or IP precedence
value when a specific traffic mix consisting of multiple
DSCPs or IP precedence values are applied. This term
attempts to capture the expected forwarding behavior when
subjected to a certain offered vectors.
The actual algorithm or mechanism the DUT uses to achieve
service differentiation is not important in describing the
expected delay vector.
Measurement units:
Seconds.
See Also:
Forwarding Delay
Intended Vector
Offered Vector
Output Vectors
Expected Loss Vector
Expected Sequence Vector
Expected Forwarding Vector
Expected Jitter Vector
3.4.3.5 Expected Average Delay Vector
Definition:
A vector describing the expected average delay for packets
having a specific DSCP or IP precedence value. The value is
dependent on the set of offered vectors and configuration of
the DUT.
Discussion:
The DUT is configured in a certain way in order that service
differentiation occurs for a particular DSCP or IP precedence
value when a specific traffic mix consisting of multiple
DSCPs or IP precedence values are applied. This term
attempts to capture the expected forwarding behavior when
subjected to a certain offered vectors.
The actual algorithm or mechanism the DUT uses to achieve
service differentiation is not important in describing the
expected average delay vector.
Measurement units:
Seconds.
Network-layer Traffic Control Mechanisms
See Also:
Intended Vector
Offered Vector
Output Vectors
Expected Loss Vector
Expected Sequence Vector
Expected Forwarding Vector
Expected Jitter Vector
3.4.3.6 Expected Maximum Delay Vector
Definition:
A vector describing the expected maximum delay for packets
having a specific DSCP or IP precedence value. The value is
dependent on the set of offered vectors and configuration of
the DUT.
Discussion:
The DUT is configured in a certain way in order that service
differentiation occurs for a particular DSCP or IP precedence
value when a specific traffic mix consisting of multiple
DSCPs or IP precedence values are applied. This term
attempts to capture the expected forwarding behavior when
subjected to a certain offered vectors.
The actual algorithm or mechanism the DUT uses to achieve
service differentiation is not important in describing the
expected maximum delay vector.
Measurement units:
Seconds.
See Also:
Intended Vector
Offered Vector
Output Vectors
Expected Loss Vector
Expected Sequence Vector
Expected Forwarding Vector
Expected Jitter Vector
3.4.3.7 Expected Minimum Delay Vector
Definition:
A vector describing the expected minimum delay for packets
having a specific DSCP or IP precedence value. The value is
dependent on the set of offered vectors and configuration of
the DUT.
Network-layer Traffic Control Mechanisms
Discussion:
The DUT is configured in a certain way in order that service
differentiation occurs for a particular DSCP or IP precedence
value when a specific traffic mix consisting of multiple
DSCPs or IP precedence values are applied. This term
attempts to capture the expected forwarding behavior when
subjected to a certain offered vectors.
The actual algorithm or mechanism the DUT uses to achieve
service differentiation is not important in describing the
expected minimum delay vector.
Measurement units:
Seconds.
See Also:
Intended Vector
Offered Vector
Output Vectors
Expected Loss Vector
Expected Sequence Vector
Expected Forwarding Vector
Expected Jitter Vector
3.4.3.8 Expected Instantaneous Jitter Vector
Definition:
A vector describing the expected jitter between two
consecutive packetsĂ arrival times having a specific DSCP or
IP precedence value. The value is dependent on the set of
offered vectors and configuration of the DUT.
Discussion:
Instantaneous Jitter is the absolute value of the difference
between the delay measurement of two packets belonging to the
same stream.
The 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 delay and i is the test sequence number.
Packets lost are not counted in the measurement.
Forwarding Vector may contain several Jitter Vectors. For n
packets received in a Forwarding Vector, there is a total of
(n-1) Instantaneous Jitter Vectors.
Measurement units:
Seconds
Network-layer Traffic Control Mechanisms
See Also:
Delay
Jitter
Offered Vector
Output Vectors
Expected Average Jitter Vector
Expected Peak-to-peak Jitter Vector
Stream
3.4.3.9 Expected Average Jitter Vector
Definition:
A vector describing the expected jitter in packet arrival
times for packets having a specific DSCP or IP precedence
value. The value is dependent on the set of offered vectors
and configuration of the DUT.
Discussion:
Average Jitter Vector is the average of all the Instantaneous
Jitter Vectors measured during the test duration for the same
DSCP or IP precedence value.
Measurement units:
Seconds
See Also:
Intended Vector
Offered Vector
Output Vectors
Expected Instantaneous Jitter Vector
Expected Peak-to-peak Jitter Vector
3.4.3.10 Expected Peak-to-peak Jitter Vector
Definition:
A vector describing the expected maximum variation in the
delay of packet arrival times for packets having a specific
DSCP or IP precedence value. The value is dependent on the
set of offered vectors and configuration of the DUT.
Discussion:
Peak-to-peak Jitter Vector is the maximum delay minus the
minimum delay of the packets (in a vector) forwarded by the
DUT/SUT.
Peak-to-peak Jitter is not derived from the Instantaneous
Jitter Vector. Peak-to-peak Jitter is based upon all the
packets during the test duration, not just two consecutive
packets.
Network-layer Traffic Control Mechanisms
Measurement units:
Seconds
See Also:
Intended Vector
Offered Vector
Output Vectors
Expected Instantaneous Jitter Vector
Expected Average Jitter Vector
3.4.4 Output Vectors
3.4.4.1 Forwarding Vector
Definition:
The number of packets per second for all packets containing a
specific DSCP or IP precedence value that a device can be
observed to successfully forward to the correct destination
interface in response to an offered vector.
Discussion:
Forwarding Vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND the packets per
second value combine to make a vector.
The Forwarding Vector represents packet rate based on its
specific DSCP (or IP precedence) value. It is not
necessarily based on a stream or flow. The Forwarding Vector
may be expressed as per port of the DUT/SUT. However, it
must be consistent with the Expected Forwarding Vector.
Forwarding Vector is a per-hop measurement. The DUT/SUT may
change the specific DSCP (or IP precedence) value for a
multiple-hop measurement.
Measurement units:
N-octet packets per second
See Also:
Intended Vector
Offered Vector
Expected Vectors
Loss Vector
Sequence Vector
Delay Vectors
Network-layer Traffic Control Mechanisms
3.4.4.2 Loss Vector
Definition:
The percentage of packets containing a specific DSCP or IP
precedence value that a DUT/SUT did not transmit to the
correct destination interface in response to an offered
vector.
Discussion:
Loss Vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND the percentage
value combine to make a vector.
The Loss Vector represents percentage based on a specific
DSCP or IP precedence value. It is not necessarily based on
a stream or flow. The Loss Vector may be expressed as per
port of the DUT/SUT. However, it must be consistent with the
Expected Loss Vector
Loss Vector is a per-hop measurement. The DUT/SUT may change
the specific DSCP or IP precedence value for a multiple-hop
measurement.
Measurement Units:
Percentage of offered packets that is not forwarded.
See Also:
Intended Vector
Offered Vector
Expected Vectors
Forwarding Vector
Sequence Vector
Delay Vectors
One-way Packet Loss Metric [Ka99]
3.4.4.3 Sequence Vector
Definition:
The number of packets per second for all packets containing a
specific DSCP or IP precedence value that a device can be
observed to transmit in sequence to the correct destination
interface in response to an offered vector.
Discussion:
Sequence Vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND the packets per
second value combine to make a vector.
Network-layer Traffic Control Mechanisms
The Sequence Vector represents packet rate based on its
specific DSCP or IP precedence value. It is not necessarily
based on a stream or flow. The Sequence Vector may be
expressed as per port of the DUT/SUT. However, it must be
consistent with the Expected Sequence Vector.
Sequence Vector is a per-hop measurement. The DUT/SUT may
change the specific DSCP or IP precedence value for a
multiple-hop measurement.
Measurement Units:
N-octet packets per second
Issues:
See Also:
In-sequence Packet
Intended Vector
Offered Vector
Expected Vectors
Loss Vector
Forwarding Vector
Delay Vectors
3.4.4.4 Instantaneous Delay Vector
Definition:
The delay for a packet containing a specific DSCP or IP
precedence value that a device can be observed to
successfully transmit to the correct destination interface in
response to an offered vector.
Discussion:
Instantaneous Delay vector is expressed as pair of numbers.
Both the specific DSCP (or IP precedence) value AND delay
value combine to make a vector.
The Instantaneous Delay Vector represents delay on its
specific DSCP or IP precedence value. It is not necessarily
based on a stream or flow. The Delay vector may be expressed
as per port of the DUT/SUT. However, it must be consistent
with the Expected Delay vectors.
Instantaneous Delay Vector is a per-hop measurement. The
DUT/SUT may change the specific DSCP or IP precedence value
for a multiple-hop measurement.
Instantaneous Delay vector can be obtained at any offered
load. RECOMMEND at or below the Forwarding Capacity in the
absence of forwarding congestion. For congested delay, run
the offered load above the Forwarding Capacity.
Network-layer Traffic Control Mechanisms
Forwarding Vector may contain several Instantaneous Delay
Vectors. For every packet received in a Forwarding Vector,
there is a corresponding Instantaneous Delay Vector.
Measurement Units:
Seconds
See Also:
Delay
Intended Vector
Offered Vector
Expected Delay Vectors
Average Delay Vector
Maximum Delay Vector
Minimum Delay Vector
3.4.4.5 Average Delay Vector
Definition:
The average delay for packets containing a specific DSCP or
IP precedence value that a device can be observed to
successfully transmit to the correct destination interface in
response to an offered vector.
Discussion:
Average Delay vector is expressed as pair of numbers. Both
the specific DSCP (or IP precedence) value AND delay value
combine to make a vector.
The Delay Vector represents delay on its specific DSCP or IP
precedence value. It is not necessarily based on a stream or
flow. The Delay vector may be expressed as per port of the
DUT/SUT. However, it MUST be consistent with the Expected
Delay vector.
The Average Delay Vector is computed by averaging all the
Instantaneous Delay Vectors for a given vector.
Average Delay Vector is a per-hop measurement. The DUT/SUT
may change the specific DSCP or IP precedence value for a
multiple-hop measurement.
Average Delay vector can be obtained at any offered load.
Recommend at or below the Forwarding Capacity in the absence
of congestion. For congested delay, run the offered load
above the Forwarding Capacity.
Measurement Units:
Seconds
Network-layer Traffic Control Mechanisms
See Also:
Delay
Intended Vector
Offered Vector
Expected Delay Vectors
Instantaneous Delay Vector
Maximum Delay Vector
Minimum Delay Vector
3.4.4.6 Maximum Delay Vector
Definition:
The maximum delay from all packets containing a specific DSCP
or IP precedence value that a device can be observed to
successfully transmit to the correct destination interface in
response to an offered vector.
Discussion:
Maximum Delay vector is expressed as pair of numbers. Both
the specific DSCP (or IP precedence) value AND delay value
combine to make a vector.
The Maximum Delay Vector represents delay on its specific
DSCP or IP precedence value. It is not necessarily based on
a stream or flow. The Maximum Delay vector may be expressed
as per port of the DUT/SUT. However, it must be consistent
with the Expected Delay vector.
Maximum Delay Vector is based upon the maximum Instantaneous
Delay Vector of all packets in a Forwarding Vector.
Maximum Delay Vector is a per-hop measurement. The DUT/SUT
may change the specific DSCP or IP precedence value for a
multiple-hop measurement.
Measurement Units:
Seconds
See Also:
Delay
Intended Vector
Offered Vector
Expected Delay Vectors
Instantaneous Delay Vector
Forwarding Vector
Average Delay Vector
Minimum Delay Vector
Network-layer Traffic Control Mechanisms
3.4.4.7 Minimum Delay Vector
Definition:
The minimum delay from all packets containing a specific DSCP
or IP precedence value that a device can be observed to
successfully transmit to the correct destination interface in
response to an offered vector.
Discussion:
Delay vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND delay value
combine to make a vector.
The Minimum Delay Vector represents delay on its specific
DSCP or IP precedence value. It is not necessarily based on
a stream or flow. The Minimum Delay vector may be expressed
as per port of the DUT/SUT. However, it must be consistent
with the Expected Delay vector.
Minimum Delay Vector is based upon the minimum Instantaneous
Delay Vector of all packets in a Forwarding Vector.
Minimum Delay Vector is a per-hop measurement. The DUT/SUT
may change the specific DSCP or IP precedence value for a
multiple-hop measurement.
Minimum Delay vector can be obtained at any offered load.
Recommend at or below the Forwarding Capacity in the absence
of congestion. For congested delay, run the offered load
above the Forwarding Capacity.
Measurement Units:
Seconds
See Also:
Delay
Intended Vector
Offered Vector
Expected Delay Vectors
Instantaneous Delay Vector
Forwarding Vector
Average Delay Vector
Maximum Delay Vector
3.4.4.8 Instantaneous Jitter Vector
Definition:
The jitter for two consecutive packets containing a specific
DSCP or IP precedence value that a device can be observed to
successfully transmit to the correct destination interface in
response to an offered vector.
Network-layer Traffic Control Mechanisms
Discussion:
Instantaneous Jitter is the absolute value of the difference
between the delay measurement of two packets belonging to the
same stream.
Jitter vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND jitter value
combine to make a vector.
The delay fluctuation between two consecutive packets in a
stream is reported as the "Instantaneous Jitter".
Instantaneous Jitter Vector can be expressed as |D(i) - D(i-
1)| where D equals the delay and i is the test sequence
number. Packets lost are not counted in the measurement.
Instantaneous Jitter Vector is a per-hop measurement. The
DUT/SUT may change the specific DSCP or IP precedence value
for a multiple-hop measurement.
Forwarding Vector may contain several Instantaneous Jitter
Vectors. For n packets received in a Forwarding Vector,
there are exactly (n-1) Instantaneous Jitter Vectors.
Measurement units:
Seconds
See Also:
Delay
Jitter
Forwarding Vector
Stream
Expected Vectors
Average Jitter Vector
Peak-to-peak Jitter Vector
3.4.4.9 Average Jitter Vector
Definition:
The average jitter for packets containing a specific DSCP or
IP precedence value that a device can be observed to
successfully transmit to the correct destination interface in
response to an offered vector.
Discussion:
Average Jitter Vector is the average of all the Instantaneous
Jitter Vectors of the same DSCP or IP precedence value,
measured during the test duration.
Network-layer Traffic Control Mechanisms
Average Jitter vector is expressed as pair of numbers. Both
the specific DSCP (or IP precedence) value AND jitter value
combine to make a vector.
Average Jitter vector is a per-hop measurement. The DUT/SUT
may change the specific DSCP or IP precedence value for a
multiple-hop measurement.
Measurement units:
Seconds
See Also:
Jitter
Forwarding Vector
Stream
Expected Vectors
Instantaneous Jitter Vector
Peak-to-peak Jitter Vector
3.4.4.10 Peak-to-peak Jitter Vector
Definition:
The maximum possible variation in the delay for packets
containing a specific DSCP or IP precedence value that a
device can be observed to successfully transmit to the
correct destination interface in response to an offered
vector.
Discussion:
Peak-to-peak Jitter Vector is the maximum delay minus the
minimum delay of the packets (in a vector) forwarded by the
DUT/SUT.
Jitter vector is expressed as pair of numbers. Both the
specific DSCP (or IP precedence) value AND jitter value
combine to make a vector.
Peak-to-peak Jitter is not derived from the Instantaneous
Jitter Vector. Peak-to-peak Jitter is based upon all the
packets during the test duration, not just two consecutive
packets.
Measurement units:
Seconds
See Also:
Jitter
Forwarding Vector
Stream
Expected Vectors
Average Jitter Vector
Peak-to-peak Jitter Vector
Network-layer Traffic Control Mechanisms
4. Acknowledgments
The authors gratefully acknowledge the contributions of the
IETF's benchmarking working group members in reviewing this
document. The authors would like to express our thanks to
David Newman for his consistent and valuable assistance
throughout the development of this document. The following
individuals also made noteworthy contributions to the
editors' understanding of the subject matter: John Dawson,
Kevin Dubray, and Kathleen Nichols.
5. Security Considerations
Documents of this type do not directly affect the security of
the Internet or of corporate networks as long as benchmarking
is not performed on devices or systems connected to
production networks.
Packets with unintended and/or unauthorized DSCP or IP
precedence values may present security issues. Determining
the security consequences of such packets is out of scope for
this document.
6. Normative References
[Br91] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991.
[Br97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998.
[Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition
of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers", RFC 2474, December 1998.
Network-layer Traffic Control Mechanisms
7. Informative References
[Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay
Metric for IPPM", RFC 2679, September 1999
[Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
Weiss, W., "An Architecture for Differentiated Services",
RFC 2475, December 1998.
[Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999
[De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation
Metric for IPPM", RFC 3393, November 2002
[Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited
Forwarding PHB", RFC 2598, June 1999
[Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999
[Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control
Survey", RFC 1254, August 1991
[Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for
LAN Switching Devices", RFC 2889, August 2000
[Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., Perser, J., "Packet Reordering Metric for IPPM",
Work in Progress
[Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, January 1984.
[Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add
Explicit Congestion Notification (ECN) to IP", RFC 2481,
January 1999.
[Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996
Network-layer Traffic Control Mechanisms
8. Authors' Addresses
Jerry Perser
USA
Phone:
EMail: jerry@perser.org
Scott Poretsky
Quarry Technologies
New England Executive Park
Burlington, MA 01803
USA
Phone: + 1 781 359 5090
EMail: sporetsky@quarrytech.com
Shobha Erramilli
QNetworx Inc
1119 Campus Drive West
Morganville, NJ 07751
USA
Phone:
EMail: shobha@qnetworx.com
Sumit Khurana The IETF takes no position regarding the validity or scope of any Intel-
Telcordia Technologies lectual Property Rights or other rights that might be claimed to pertain
445 South Street to the implementation or use of the technology described in this docu-
Morristown, NJ 07960 ment or the extent to which any license under such rights might or might
USA not be available; nor does it represent that it has made any independent
effort to identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Phone: + 1 973 829 3170 The IETF invites any interested party to bring to its attention any
EMail: sumit@research.telcordia.com copyrights, patents or patent applications, or other proprietary rights
Network-layer Traffic Control Mechanisms that may cover technology that may be required to implement this stan-
dard. Please address the information to the IETF at ietf-ipr@ietf.org.
9. Full Copyright Statement Disclaimer of Warranty
Copyright (C) The Internet Society (2003). All Rights This document and the information contained herein are provided on an
Reserved. "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA-
TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and translations of it may be copied and Copyright Statement
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document
itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will Copyright (C) The Internet Society (2005). This document is subject to
not be revoked by the Internet Society or its successors or the rights, licenses and restrictions contained in BCP 78, and except as
assigns. This document and the information contained herein set forth therein, the authors retain all their rights.
is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/