draft-ietf-bmwg-dsmterm-01.txt   draft-ietf-bmwg-dsmterm-02.txt 
Network Working Group Jerry Perser Network Working Group Jerry Perser
INTERNET-DRAFT Spirent INTERNET-DRAFT Spirent
Expires in: December 2001 David Newman Expires in: May 2002 David Newman
Network Test Network Test
Sumit Khurana Sumit Khurana
Telcordia Telcordia
Shobha Erramilli Shobha Erramilli
Telcordia QNetworx
Scott Poretsky Scott Poretsky
Avici Systems Avici Systems
June 2001 November 2001
Terminology for Benchmarking Network-layer Terminology for Benchmarking Network-layer
Traffic Control Mechanisms Traffic Control Mechanisms
<draft-ietf-bmwg-dsmterm-01.txt> <draft-ietf-bmwg-dsmterm-02.txt>
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 documents months and may be updated, replaced, or obsoleted by other
at any time. It is inappropriate to use Internet- Drafts as documents at any time. It is inappropriate to use Internet-
reference material or to cite them other than as "work in progress." Drafts as reference material or to cite them other than as "work
in 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.
Table of Contents Table of Contents
1. Introduction ............................................... 2 1. Introduction .............................................. 2
2. Existing definitions ....................................... 3 2. Existing definitions ...................................... 3
3. Term definitions.............................................3 3. Term definitions ............................................3
3.1 Channel Capacity..........................................3 3.1 Configuration Terms
3.2 Classification............................................4 3.1.1 Classification .........................................3
3.3 Codepoint Set.............................................4 3.1.2 Codepoint Set ..........................................4
3.4 Conforming................................................5 3.1.3 Congestion .............................................4
3.5 Congestion................................................5 3.1.4 Congestion Management ..................................5
3.6 Congestion Management.....................................6 3.2 Vectors ....................................................6
3.7 Delay.....................................................7 3.2.1 Intended Vector ........................................6
3.8 Expected Vector...........................................7
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
3.9 Flow......................................................8 3.2.2 Offered Vector .........................................6
3.10 Forwarding Vector .......................................9 3.2.3 Expected Vectors
3.11 Jitter...................................................9 3.2.3.1 Expected Forwarding Vector ...........................7
3.12 Nonconforming...........................................10 3.2.3.2 Expected Loss Vector .................................8
3.13 Offered Vector..........................................11 3.2.3.3 Expected Sequence Vector .............................8
3.14 Stream..................................................11 3.2.3.4 Expected Delay Vector ................................9
3.15 Tail dropping...........................................12 3.2.3.5 Expected Jitter Vector ..............................10
3.16 Test Sequence number....................................12 3.2.4 Output Vectors
3.17 Unburdened Response.....................................13 3.2.4.1 Forwarding Vector ...................................11
4. Security Considerations.....................................13 3.2.4.2 Loss Vector .........................................11
5. References..................................................14 3.2.4.3 Sequence Vector .....................................12
6. Author's Address............................................14 3.2.4.4 Delay Vector ........................................13
7. Full Copyright Statement....................................15 3.2.4.5 Jitter Vector .......................................14
3.3 Measurement Terms
3.3.1 Channel Capacity ......................................15
3.3.2 Conforming ............................................15
3.3.3 Nonconforming .........................................16
3.3.4 Delay .................................................16
3.3.5 Flow ..................................................17
3.3.6 Stream ................................................18
3.3.7 Test Sequence number ..................................19
3.3.8 Undifferentiated Response .............................19
4. Security Considerations ....................................20
5. References .................................................20
6. Author's Address ...........................................21
7. Full Copyright Statement ...................................22
1. Introduction 1. Introduction
Driven by Internet economics, service providers and enterprises This document describes terminology for the benchmarking of
alike have shown strong interest in adding traffic-control devices that implement traffic control based on IP precedence or
capabilities to network devices. These capabilities would enable diff-serv code point criteria.
network operators to define and deliver minimum or maximum levels of
bandwidth, delay, and jitter for multiple classes of traffic.
Perhaps more importantly, network operators would be able to set
pricing according to the level of service delivered.
Networking device manufacturers have responded with a wide variety New terminology is needed because most existing measurements
of approaches for controlling network traffic. While there are assume the absence of congestion and only a single per-hop-
numerous ˘policy management÷ and ˘quality of service÷ frameworks, behavior. This document introduces several new terms that will
many of them rely on one of two network-layer mechanisms for the allow measurements to be taken during periods of congestion.
actual control of forwarding rate, delay, and jitter. These two
mechanisms are the IP precedence setting in the IP header and the
diff-serv code point (DSCP) defined in [3].
This document describes the various terms to be used in benchmarking Another key difference from existing terminology is the definition
devices that implement traffic control based on IP precedence or of measurements as observed on egress as well as ingress of a
DSCP criteria. This document is narrowly focused, in that it device/system under test. Again, the existence of congestion
describes only terms for measuring behavior of a device or a group requires the addition of egress measurements as well as those
of devices using one of these two mechanisms. End-to-end and taken on ingress; without observing traffic leaving a
service-level measurements are beyond the scope of this document. device/system it is not possible to say whether traffic-control
mechanisms effectively dealt with congestion.
This document introduces several new terms that will allow The principal measurements introduced in this document are vectors
measurements to be taken during periods of congestion. New for rate, delay, and jitter, all of which can be observed with or
terminology is needed because most existing benchmarking terms without congestion of the DUT/SUT.
assume the absence of congestion. For example, throughput is one of
the most widely used measurements ű- yet RFC 1242 defines throughput
as a rate in the absence of loss. As a result, throughput is not a
meaningful measurement where congestion exists.
Another key difference from existing benchmarking terminology is the
definition of measurements as observed on egress as well as ingress
of a device/system under test. Again, the existence of congestion
requires the addition of egress measurements as well as those taken
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
on ingress; without observing traffic leaving a device it is not This document describes only those terms relevant to measuring
possible to say whether traffic-control mechanisms effectively dealt behavior of a device or a group of devices using one of these two
with congestion. mechanisms. End-to-end and service-level measurements are beyond
the scope of this document.
The principal measurements introduced in this document are rate
vectors, delay, and jitter, all of which can be observed with or
without congestion of the DUT/SUT.
2. Existing definitions 2. Existing definitions
RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" RFC 1242 "Benchmarking Terminology for Network Interconnect
and RFC 2285 "Benchmarking Terminology for LAN Switching Devices" Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching
should be consulted before attempting to make use of this document. Devices" should be consulted before attempting to make use of this
document.
RFC 2474 "Definition of the Differentiated Services Field (DS Field) RFC 2474 "Definition of the Differentiated Services Field (DS
in the IPv4 and IPv6 Headers" section 2, contains discussions of a Field) in the IPv4 and IPv6 Headers" section 2, contains
number of terms relevant to network-layer traffic control mechanisms discussions of a number of terms relevant to network-layer traffic
and should also be consulted. control mechanisms and should also be consulted.
For the sake of clarity and continuity this RFC adopts the template For the sake of clarity and continuity this RFC adopts the
for definitions set out in Section 2 of RFC 1242. Definitions are template for definitions set out in Section 2 of RFC 1242.
indexed and grouped together in sections for ease of reference. Definitions are indexed and grouped together in sections for ease
of reference.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
this document are to be interpreted as described in RFC 2119. "OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
3. Term definitions 3. Term definitions
3.1 Channel Capacity 3.1 Configuration Terms
3.1.1 Classification
Definition: Definition:
The maximum forwarding rate of a link or set of aggregated Selection of packets based on the contents of packet header
links at which none of the offered packets are dropped by the according to defined rules.
DUT/SUT.
Discussion: Discussion:
Channel capacity measures the data rate at the egress Packets can be selected based on the DS field or IP
interface(s) of the DUT/SUT. In contrast, throughput as defined Precedence in the packet header. Classification can also be
in RFC 1242 measures the data rate is based on the ingress based on Multi-Field (MF) criteria such as IP Source and
interface(s) of the DUT/SUT. destination addresses, protocol and port number.
Ingress-based measurements do not account for congestion of the Classification determines the per-hop behaviors and traffic
DUT/SUT. Channel capacity, as an egress measurement, does take conditioning functions such as shaping and dropping that are
congestion into account. to be applied to the packet.
Understanding channel capacity is a necessary precursor to any Measurement units:
measurement involving congestion. Throughput numbers can be
higher than channel capacity because of queueing. Network-layer Traffic Control Mechanisms
n/a
Issues:
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 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:
3.1.3 Congestion
Definition:
A condition in which one or more egress interfaces are
offered more packets than are forwarded at any given instant.
Discussion:
This condition is a superset of the overload definition [2].
The overload definition assumes the congestion is introduced
strictly by the tester on ingress of a DUT/SUT. That may or
may not be the case here.
Another difference is that with multiple-DUT measurements,
congestion may occur at multiple points. For example,
multiple edge devices collectively may congest a core device.
In contrast, overload [1] deals only with overload on
ingress.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
Ingress observations alone are not sufficient to cover all
cases in which congestion may occur. A device with an
infinite amount of memory could buffer an infinite amount of
packets, and eventually forward all of them. However, these
packets may or may not be forwarded during the test duration.
Even though ingress interfaces accept all packets without
loss, this hypothetical device may still be congested.
The definition presented here explicitly defines congestion
as an event observable on egress interfaces. Regardless of
internal architecture, any device that cannot forward packets
on one or more egress interfaces is congested.
Measurement units: Measurement units:
N-octet packets per second n/a
Issues: Issues:
See Also: See Also:
Throughput [1]
3.2 Classification 3.1.4 Congestion Management
Definition: Definition:
Selection of packets based on the contents of packet header An implementation of one or more per-hop-behaviors to avoid
according to defined rules. or minimize the condition of congestion.
Discussion: Discussion:
Packets can be selected based on the DS field or IP Precedence Congestion management may seek either to control congestion
in the packet header. Classification can also be based on or avoid it altogether. Such mechanisms classify packets
Multi-Field (MF) criteria such as IP Source and destination based upon IP Precedence or DSCP settings in a packet's IP
addresses, protocol and port number. header.
Classification determines the per-hop behaviors and traffic Congestion avoidance mechanisms seek to prevent congestion
conditioning functions such as shaping and dropping that are to before it actually occurs.
be applied to the packet.
Congestion control mechanisms gives one or more service
classes preferential treatment over other classes during
periods of congestion.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Rules
3.3 Codepoint Set Network-layer Traffic Control Mechanisms
3.2 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.2.1 Intended Vector
Definition: Definition:
The set of all DS Code-points or IP precedence values used
during the test duration. A vector describing the rate at which packets having a
specific code-point (or IP precedence) that an external
source attempts to transmit to a DUT/SUT.
Discussion: Discussion:
Describes all the code-point markings associated with packets Intended loads across the different code-point classes
that are input to the DUT/SUT. For each entry in the codepoint determine the metrics associated with a specific code-point
set, there are associated vectors describing the rate of traffic class.
traffic containing that particular DSCP or IP precedence value.
The treatment that a packet belonging to a particular code- Measurement Units:
point gets is subject to the DUT classifying packets to map to N-octets packets per second
Network-layer Traffic Control Mechanisms
the correct PHB. Moreover, the forwarding treatment in general Issues:
is also dependent on the complete set of offered vectors.
See Also:
Offered Vector
Expected Forwarding Vector
Expected Loss Vector
Expected Sequence Vector
Expected Delay Vector
Expected Jitter Vector
Forwarding Vector
Loss Vector
3.2.2 Offered Vector
Definition:
A vector describing the measured rate at which packets having
a specific DSCP or IP precedence value are offered to the
DUT/SUT.
Discussion:
Offered loads across the different code-point classes,
constituting a code-point set, determine the metrics
associated with a specific code-point traffic class.
Measurement Units: Measurement Units:
n/a N-octets packets per second
Network-layer Traffic Control Mechanisms
Issues:
Packet size.
See Also: See Also:
Expected Forwarding Vector
Expected Loss Vector
Expected Sequence Vector
Expected Delay Vector
Expected Jitter Vector
Forwarding Vector
Codepoint Set
3.4 Conforming 3.2.3 Expected Vectors
3.2.3.1 Expected Forwarding Vector
Definition: Definition:
Packets that lie within the bounds specified by a traffic A vector describing the expected output rate of packets
profile. having a specific DSCP or IP precedence value. The value is
dependent on the set of offered vectors and configuration of
the DUT.
Discussion: Discussion:
Rules may be configured that allow a given traffic class to The DUT is configured in a certain way in order that service
consume only X bit/s of channel capacity and no more. All differentiation occurs for behavior aggregates when a
additional packets are dropped. All packets that constitute specific traffic mix consisting of multiple behavior
the first X bits/s measured over a period of time specified by aggregates is applied. This term attempts to capture the
the traffic profile, are then said to be conforming whereas expected forwarding behavior, for which the device is
those exceeding the bound are non conforming. configured, when subjected to a certain offered load.
In particular in a congestion scenario, some individual packets The actual algorithms or mechanism, that the DUT uses to
will be conforming and others will not. achieve service differentiation, is not important in
describing the expected vector.
Measurement units: Measurement units:
N-octet packets per second
n/a Issues:
See Also:
Intended Vector
Offered Vector
Output Vectors
Expected Loss Vector
Expected Sequence Vector
Expected Delay Vector
Expected Jitter Vector
Network-layer Traffic Control Mechanisms
3.2.3.2 Expected Loss Vector
Definition:
A 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 behavior aggregates when a
specific traffic mix consisting of multiple behavior
aggregates is applied. This term attempts to capture the
expected loss behavior, for which the device is configured,
when subjected to a certain offered load.
The actual algorithms or mechanism, that the DUT uses to
achieve service differentiation, is not important in
describing the expected loss vector.
Measurement Units:
Percentage of intended packets that are expected to be
dropped.
Issues: Issues:
See Also: See Also:
Expected Vector Intended Vector
Forwarding Vector
Offered Vector Offered Vector
Expected Forwarding Vector
Expected Sequence Vector
Expected Delay Vector
Expected Jitter Vector
3.5 Congestion 3.2.3.3 Expected Sequence Vector
Definition: Definition:
A condition in which one or more egress interfaces are offered A vector describing the expected sequencing of packets having
more packets than can be forwarded at any given instant. a specific DSCP or IP precedence value. The value is
dependent on the set of offered vectors and configuration of
the DUT.
Discussion: Discussion:
This condition is a superset of the overload definition [2]. The DUT is configured in a certain way in order that service
That definition assumes the overload is introduced strictly by differentiation occurs for behavior aggregates when a
the tester on ingress of a DUT/SUT. That may or may not be the specific traffic mix consisting of multiple behavior
case here. aggregates is applied. This term attempts to capture the
expected sequence behavior, for which the device is
configured, when subjected to a certain offered load.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
Another difference is that with multiple-DUT measurements, The actual algorithms or mechanism, that the DUT uses to
congestion may occur at multiple points. For example, multiple achieve service differentiation, is not important in
edge devices collectively may congest a core device. In describing the expected vector.
contrast, overload [1] deals only with overload on ingress.
Ingress observations alone are not sufficient to cover all Measurement Units:
cases in which congestion may occur. A device with an infinite N-octet packets per second
amount of memory could buffer an infinite amount of packets,
and eventually forward all of them. However, these packets may
or may not be forwarded during the test duration. Even though
ingress interfaces accept all packets without loss, this
hypothetical device may still be congested.
The definition presented here explicitly defines congestion as Issues:
an event observable on egress interfaces. Regardless of
internal architecture, any device that cannot forward packets See Also:
on one or more egress interfaces is congested. Intended Vector
Offered Vector
Output Vectors
Expected Loss Vector
Expected Forwarding Vector
Expected Delay Vector
Expected Jitter Vector
3.2.3.4 Expected Delay Vector
Definition:
A vector describing the expected delay for packets having a
specific DSCP or IP precedence value. The value is dependent
on the set of offered vectors and configuration of the DUT.
Discussion:
The DUT is configured in a certain way in order that service
differentiation occurs for behavior aggregates when a
specific traffic mix consisting of multiple behavior
aggregates is applied. This term attempts to capture the
expected delay behavior, for which the device is configured,
when subjected to a certain offered load.
The actual algorithms or mechanism, that the DUT uses to
achieve service differentiation, is not important in
describing the expected delay vector.
Measurement units: Measurement units:
n/a Seconds.
Issues: Issues:
See Also: See Also:
Intended Vector
Offered Vector
Output Vectors
Expected Loss Vector
Expected Sequence Vector
Expected Forwarding Vector
Expected Jitter Vector
Network-layer Traffic Control Mechanisms
3.6 Congestion Management 3.2.3.5 Expected Jitter Vector
Definition: Definition:
An implementation of one or more per-hop-behaviors to avoid or A vector describing the expected variation in the delay of
minimize the condition of congestion. packet arrival times for packets having specific DSCP or IP
precedence value. The value is dependent on the set of
offered vectors and configuration of the DUT.
Discussion: Discussion:
Congestion management may seek either to control congestion or Jitter is the absolute value of the difference between the
avoid it altogether. Such mechanisms classify packets based delay measurement of two packets belonging to the same
upon IP Precedence or DSCP settings in a packetĂs IP header. stream.
Congestion avoidance mechanisms seek to prevent congestion The jitter between two consecutive packets in a stream is
before it actually occurs. reported as the "instantaneous jitter". Instantaneous jitter
can be expressed as |D(i) - D(i-1)| where D equals the delay
and i is the test sequence number. Packets lost are not
counted in the jitter measurement.
Congestion control mechanisms gives one or more service classes Average Jitter is the average of the instantaneous jitter
preferential treatment over other classes during periods of measured during the test duration.
congestion.
Measurement units: Peak-to-peak jitter is the maximum delay minus the minimum
delay of the packets forwarded by the DUT/SUT.
n/a Measurement units:
Seconds (instantaneous)
Seconds P-P (peak to peak)
Seconds Avg (average)
Issues: Issues:
See Also: See Also:
Intended Vector
Offered Vector
Output Vectors
Expected Loss Vector
Expected Sequence Vector
Expected Delay Vector
Expected Forwarding Vector
3.2.4 Output Vectors
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
3.7 Delay 3.2.4.1 Forwarding Vector
Definition: Definition:
The time interval starting when the last bit of the input IP The number of packets per second for all packets containing a
packets reaches the input port of the DUT/SUT and ending when specific DSCP or IP precedence value that a device can be
the last bit of the output IP packets is seen on the output observed to successfully transmit to the correct destination
port of the DUT/SUT. interface in response to an offered vector.
Discussion: Discussion:
Delay is measured the same regardless of the type of DUT/SUT. Forwarding Vector is expressed as pair of numbers. Both the
Latency [1] require some knowledge of whether the DUT/SUT is a specific DSCP (or IP precedence) value AND the packets per
"store and forward" or a "bit forwarding" device. The fact second value combine to make a vector.
that a DUT/SUT's technology has a lower delay than another
technology should be visible.
The measurement point at the end is more like the way an The Forwarding Vector represents packet rate based on its
internet datagram is processed. An internet datagram is not specific DSCP (or IP precedence) value. It is not
passed up or down the stack unless it is complete. Completion necessarily based on a stream or flow. The Forwarding Vector
occurs once the last bit of the IP packet has been received. may be expressed as per port of the DUT/SUT. However, it must
be consistent with the Expected Forwarding Vector.
Delay can be run at any offered load. Recommend at or below Forwarding Vector is a per-hop measurement. The DUT/SUT may
the channel capacity for non-congested delay. For congested change the specific DSCP (or IP precedence) value for a
delay, run the offered load above the channel capacity. multiple-hop measurement.
Measurement units: Measurement units:
N-octet packets per second
Seconds.
Issues: Issues:
See Also: See Also:
Intended Vector
Offered Vector
Expected Vectors
Loss Vector
Sequence Vector
Delay Vector
Jitter Vector
3.8 Expected Vector 3.2.4.2 Loss Vector
Definition: Definition:
A vector describing the expected output rate of packets having The percentage of packets containing specific DSCP or IP
a specific code-point. The value is dependent on the set of precedence value that a DUT/SUT did not transmit to the
offered vectors and configuration of the DUT. correct destination interface in response to an offered
vector.
Discussion: Discussion:
The DUT is configured in a certain way in order that service Loss Vector is expressed as pair of numbers. Both the
discrimination happens for behavior aggregates when a specific specific DSCP (or IP precedence) value AND the percentage
traffic mix consisting of multiple behavior aggregates is value combine to make a vector.
applied. This term attempts to capture the expected behavior,
for which the device is configured, when subjected to a certain
offered load.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
The actual algorithms or mechanism, that the DUT uses to The Loss Vector represents percentage based on a specific
achieve service discrimination, is not important in describing DSCP or IP precedence value. It is not necessarily based on
the expected vector. 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
Measurement units: Loss Vector is a per-hop measurement. The DUT/SUT may change
N-octets packets per second the specific DSCP or IP precedence value for a multiple-hop
measurement.
Measurement Units:
Percentage of offered packets that are not forwarded.
Issues:
See Also: See Also:
Forwarding Vector Intended Vector
Offered Vector Offered Vector
Codepoint Set Expected Vectors
Forwarding Vector
Sequence Vector
Delay Vector
Jitter Vector
3.9 Flow 3.2.4.3 Sequence Vector
Definition: Definition:
A flow is a one or more of packets sharing a common intended The number of packets per second for all packets containing a
pair of source and destination interfaces. specific DSCP or IP precedence value that a device can be
observed to transmit out of sequence to the correct
destination interface in response to an offered vector.
Discussion: Discussion:
Packets are groups by the ingress and egress interfaces they Sequence Vector is expressed as pair of numbers. Both the
use on a given DUT/SUT. specific DSCP (or IP precedence) value AND the packets per
second value combine to make a vector.
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 [3] are a subset of flows. As defined in [3],
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 ISO 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 The Sequence Vector represents packet rate based on its
may contain multiple values destined for a single egress specific DSCP or IP precedence value. It is not necessarily
interface. This is determined by the test methodology. 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.
Measurement units: Sequence Vector is a per-hop measurement. The DUT/SUT may
change the specific DSCP or IP precedence value for a
multiple-hop measurement.
n/a Measurement Units:
N-octet packets per second
Issues: Issues:
See Also:
Microflow [3]
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
Streams See Also:
Intended Vector
Offered Vector
Expected Vectors
Loss Vector
Forwarding Vector
Delay Vector
Jitter Vector
3.10 Forwarding Vector 3.2.4.4 Delay Vector
Definition: Definition:
The number of packets per second for all packets containing a The delay for packets containing specific DSCP or IP
single DSCP (or IP precedence) that a device can be observed to 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:
Forwarding Vector is expressed as pair of numbers. Both the Delay vector is expressed as pair of numbers. Both the
codepoint (or IP precedence) value AND the packets per second specific DSCP (or IP precedence) value AND delay value
value combine to make a vector. combine to make a vector.
The forwarding vector represents packet rate based on their The Delay Vector represents delay on its specific DSCP or IP
codepoint or IP precedence value. It is not necessary based on precedence value. It is not necessarily based on a stream or
stream or flow. The forwarding vector may be expresses as ˘per flow. The Delay vector may be expressed as per port of the
port÷ or ˘of the DUT/SUT÷. DUT/SUT. However, it must be consistent with the Expected
Delay vector.
Forwarding Vector is a per-hop measurement. The DUT/SUT may Delay vector is measured similarly regardless of the type of
change the codepoint or IP precedence value for a multiple-hop DUT/SUT. Latency [1] require some knowledge of whether the
measurement. DUT/SUT is a "store and forward" or a "bit forwarding"
device. The fact that a DUT/SUT's technology has a lower
delay than another technology should be visible.
Measurement units: Delay Vector is a per-hop measurement. The DUT/SUT may
change the specific DSCP or IP precedence value for a
multiple-hop measurement.
N-octet packets per second Delay vector can be obtained at any offered load. Recommend
at or below the channel capacity in the absence of
congestion. For congested delay, run the offered load above
the channel capacity.
Measurement Units:
seconds
Issues: Issues:
See Also: See Also:
Codepoint Set Delay
Expected Vector Network-layer Traffic Control Mechanisms
Offered Vector.
3.11 Jitter Intended Vector
Offered Vector
Expected Delay Vector
Loss Vector
Forwarding Vector
Jitter Vector
3.2.4.5 Jitter Vector
Definition: Definition:
Variation in a stream's delay. The variation in the delay for packets containing specific
DSCP or IP precedence value that a device can be observed to
successfully transmit to the correct destination interface in
response to an offered vector.
Discussion: Discussion:
Jitter is the absolute value of the difference between the Jitter is the absolute value of the difference between the
delay measurement of two packets belonging to the same stream. 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 jitter between two consecutive packets in a stream is The jitter between two consecutive packets in a stream is
reported as the "instantaneous jitter". Instantaneous jitter reported as the "instantaneous jitter". Instantaneous jitter
can be expressed as |D(i) ű D(i+1)| where D equals the delay 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 and i is the test sequence number. Packets lost are not
counted in the jitter measurement. counted in the jitter measurement.
Network-layer Traffic Control Mechanisms Jitter vector is a per-hop measurement. The DUT/SUT may
change the specific DSCP or IP precedence value for a
multiple-hop measurement.
Average Jitter is the average of the instantaneous jitter Average Jitter is the average of the instantaneous jitter
measured during the test duration. measured during the test duration.
Peak-to-peak jitter is the maximum delay minus the minimum Peak-to-peak Jitter is the maximum delay minus the minimum
delay of the packets forwarded by the DUT/SUT. delay of the packets forwarded by the DUT/SUT.
Measurement units: Measurement units:
Seconds (instantaneous) Seconds (instantaneous)
Seconds P-P (peak to peak) Seconds P-P (peak to peak)
Seconds avg (average) Seconds Avg (average)
Issues: Issues:
Mean
Standard Deviation
Median
90th percentile
Inter Quartile Range
See Also: See Also:
Stream Intended Vector
Offered Vector
Expected Vectors
Network-layer Traffic Control Mechanisms
3.12 Nonconforming Loss Vector
Sequence Vector
Delay Vector
Forwarding Vector
3.3 Measurement Terms
3.3.1 Channel Capacity
Definition: Definition:
Packets that lie outside the parameter bounds of a given The maximum forwarding rate [2] at which none of the offered
traffic profile. packets are dropped by the DUT/SUT.
Discussion: Discussion:
Rules may be configured for a given traffic class based on Channel capacity measures the packet rate at the egress
parameters, such as an upper bound on the rate of packet interface(s) of the DUT/SUT. In contrast, throughput as
arrivals. All packets that lie outside the bounds specified by defined in RFC 1242 measures the packet rate is based on the
the traffic profile, measured over a period of time specified ingress interface(s) of the DUT/SUT.
in the traffic profile, are said to be nonconforming.
Ingress-based measurements do not account for congestion of
the DUT/SUT. Channel capacity, as an egress measurement, does
take congestion into account.
Understanding channel capacity is a necessary precursor to
any measurement involving congestion. Throughput numbers can
be higher than channel capacity because of queueing.
This measurement differs from forwarding rate at maximum
offered load (FRMOL) [2] in that it is intolerant of loss.
Measurement units: Measurement units:
n/a N-octet packets per second
Issues: Issues:
See Also: See Also:
Conforming Throughput [1]
Forwarding Rate at Maximum Offered Load [2]
3.13 Offered Vector 3.3.2 Conforming
Definition: 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
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
A vector describing the rate at which packets having a specific predefined delay or jitter boundaries. All packets that lie
code-point are offered to the DUT/SUT. within specified bounds are then said to be conforming,
whereas those outside the bounds are nonconforming.
Discussion: Measurement units:
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/a
N-octets packets per second
Issues: Issues:
Packet size.
See Also: See Also:
Expected Vector Expected Vector
Forwarding Vector Forwarding Vector
Codepoint Set Offered Vector
Nonconforming
3.14 Stream 3.3.3 Nonconforming
Definition: Definition:
A group of packets tracked as a single entity by the traffic Packets that do not lie within specific rate, delay, or
receiver. A stream shares a common content such as type (IP, jitter bounds.
UDP), frame size, or payload.
Discussion: Discussion:
Streams are tracked by "sequence number" or "unique signature A DUT/SUT may be configured to allow a given traffic class to
field" (RFC 2889). Streams define how individual packet's consume a given amount of bandwidth, or to fall within
statistics are grouped together to form an intelligible predefined delay or jitter boundaries. All packets that do
summary. not lie within these bounds are then said to be
nonconforming.
Common stream groupings would be by egress interface,
destination address, source address, DSCP, or IP precedence. A
stream using 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: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Flow Expected Vector
MicroFlow [3] Forwarding Vector
Offered Vector
Conforming
3.3.4 Delay
Definition:
The time interval starting when the last bit of the input IP
packets reaches the input port of the DUT/SUT and ending when
the last bit of the output IP packets is seen on the output
port of the DUT/SUT.
Discussion:
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
Test sequence number Delay is measured the same regardless of the type of DUT/SUT.
Latency [1] require some knowledge of whether the DUT/SUT is
a "store and forward" or a "bit forwarding" device. The fact
that a DUT/SUT's technology has a lower delay than another
technology should be visible.
3.15 Tail dropping By specifying the metric to be inside the Internet protocol,
the tester is relieved from specifying the start/end for
every data link layer protocol that IP runs on. This avoids
determining if the start/end delimiter are included in the
frame. Also heterogeneous data link protocol can be used in
a test.
The measurement point at the end is closely simulates the way
an internet datagram is processed. An internet datagram is
not passed up or down the stack unless it is complete.
Completion occurs once the last bit of the IP packet has been
received.
Delay can be run at any offered load. Recommend at or below
the channel capacity for non-congested delay. For congested
delay, run the offered load above the channel capacity.
Measurement units:
Seconds.
Issues:
See Also:
Latency [1]
3.3.5 Flow
Definition: Definition:
The condition in which a congested DUT/SUT discards newly A flow is a one or more of packets sharing a common intended
arriving packets. pair of source and destination interfaces.
Discussion: Discussion:
Every DUT/SUT has a finite amount of traffic it can forward, Packets are grouped by the ingress and egress interfaces they
beyond which congestion occurs. Once the offered load crosses use on a given DUT/SUT.
the congestion threshold, the device may discard any additional
traffic that arrives until congestion clears.
Tail dropping is typically a function of offered load exceeding A flow can contain multiple source IP addresses and/or
a DUT/SUTĂs buffer capacity, but other factors internal to the destination IP addresses. All packets in a flow must enter
DUT/SUT may also come into play. In terms of what is externally on the same ingress interface and exit on the same egress
observable, tail dropping can be said to occur only when interface, and have some common network layer content.
offered load exceeds channel capacity. Since a DUT/SUT may
buffer traffic on ingress, the actual threshold for tail Microflows [3] are a subset of flows. As defined in [3],
dropping may be higher than channel capacity. microflows require application-to-application measurement. In
contrast, flows use lower-layer classification criteria.
Since this document focuses on network-layer classification
Network-layer Traffic Control Mechanisms
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 ISO 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: Measurement units:
n/a n/a
Issues: Issues:
Some congestion management mechanisms seek to avoid tail
dropping by discarding packets before offered load exceeds
channel capacity. In the presence of such mechanisms, neither
congestion nor tail dropping should occur.
See Also: See Also:
Channel capacity Microflow [3]
Congestion Streams
3.16 Test Sequence number 3.3.6 Stream
Definition: Definition:
A field in the IP payload portion of the packet that is used to A group of packets tracked as a single entity by the traffic
verify the order of the packets on the egress of the DUT/SUT. receiver. A stream may share a common content such as type
(IP, UDP), packet size, or payload.
Discussion: Discussion:
The traffic generator sets the sequence number value and the Streams are tracked by Test sequence number or "unique
traffic receiver checks the value upon receipt of the packet. signature field" (RFC 2889). Streams define how individual
The traffic generator changes the value on each packet packet's statistics are grouped together to form an
transmitted based on an algorithm agreed to by the traffic intelligible summary.
receiver.
Common stream groupings would be by egress interface,
destination address, source address, DSCP, or IP precedence.
A stream using Test sequence numbers can track the ordering
of packets as they transverse the DUT/SUT.
Streams are not restricted to a pair of source and
destination interfaces as long as all packets are tracked as
a single entity. A mulitcast stream can be forward to
multiple destination interfaces.
Measurement units:
n/a
Issues:
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
See Also:
Flow
MicroFlow [3]
Test sequence number
3.3.7 Test Sequence number
Definition:
A field in the IP payload portion of the packet that is used
to verify the order of the packets on the egress of the
DUT/SUT.
Discussion:
The traffic generator sets the Test sequence number value and
the traffic receiver checks the value upon receipt of the
packet. The traffic generator changes the value on each
packet transmitted based on an algorithm agreed to by the
traffic receiver.
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 and number of duplicate packets, number of out-sequence packets, number of duplicate
packets. packets, and number of reordered packets.
The recommended algorithm to use to change the sequence number The recommended algorithm to use to change the sequence
on sequential packets is an incrementing value. number on sequential packets is an incrementing value.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Stream Stream
3.17 Unburdened Response 3.3.8 Undifferentiated Response
Definition: Definition:
A performance measure obtained when mechanisms used to support The vector(s) obtained when mechanisms used to support diff-
IP precedence and DiffServ are disabled. serv or IP precedence are disabled.
Discussion: Discussion:
Enabling Diffserv mechanisms such as scheduling algorithms may Enabling diff-serv or IP precedence mechanisms may impose
impose an additional processing overhead for packets, which may additional processing overhead for packets. This overhead may
cause the aggregate response to suffer even when traffic degrade performance even when traffic belonging to only one
belonging to only one class, the best effort class, is offered class, the best-effort class, is offered to the device.
to the device. Comparisons with "unburdened performance" may
thus be in order when obtaining metrics to ensure that enabling Network-layer Traffic Control Mechanisms
Diffserv mechanisms doesn't impose an excessive performance
penalty. Measurements with "undifferentiated response" should be made
to establish a baseline.
The vector(s) obtained with DSCPs or IP precedence enabled
can be compared to the undifferentiated response to determine
the effect of differentiating traffic.
Measurement units: Measurement units:
n/a n/a
4. Security Considerations 4. Security Considerations
Documents of this type do not directly effect the security of Documents of this type do not directly affect the security of
the Internet or of corporate networks as long as benchmarking the Internet or of corporate networks as long as benchmarking
is not performed on devices or systems connected to operating is not performed on devices or systems connected to operating
networks. networks.
5. References 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.
[1] Bradner, S., Editor, "Benchmarking Terminology for Network 5. References
Network-layer Traffic Control Mechanisms
Interconnection Devices", RFC 1242, July 1991. [1] Bradner, S., Editor, "Benchmarking Terminology for
Network Interconnection Devices", RFC 1242, July 1991.
[2] Mandeville, R., "Benchmarking Terminology for LAN Switching [2] Mandeville, R., "Benchmarking Terminology for LAN
Devices", RFC 2285, February 1998. Switching Devices", RFC 2285, February 1998.
[3] K. Nichols, S. Blake, F. Baker, D. Black,"Definition of the [3] K. Nichols, S. Blake, F. Baker, D. Black,"Definition of
Differentiated Services Field (DS Field) in the IPv4 and the Differentiated Services Field (DS Field) in the IPv4
IPv6 Headers", RFC 2474, December 1998. and IPv6 Headers", RFC 2474, December 1998.
[4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
Weiss, "An Architecture for Differentiated Services", RFC Weiss, "An Architecture for Differentiated Services", RFC
2475, December 1998. 2475, December 1998.
6. Author's Address Network-layer Traffic Control Mechanisms
6. Authors' Address
Jerry Perser Jerry Perser
Spirent Communications Spirent Communications
26750 Agoura Road 26750 Agoura Road
Calabasas, CA 91302 Calabasas, CA 91302
USA USA
Phone: + 1 818 676 2300 Phone: + 1 818 676 2300
EMail: jerry.perser@spirentcom.com EMail: jerry.perser@spirentcom.com
skipping to change at page 14, line 49 skipping to change at page 21, line 37
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
Shobha Erramilli Shobha Erramilli
Telcordia Technologies QNetworx Inc
331 Newman Springs Road, 1119 Campus Drive West
Navesink, NJ 07701 Morganville NJ 07751
USA USA
Network-layer Traffic Control Mechanisms
Phone: + 1 732 758 5508 Phone:
EMail: shobha@research.telcordia.com EMail: shobha@qnetworx.com
Scott Poretsky Scott Poretsky
Avici Systems Avici Systems
101 Billerica Ave¨Building #6 101 Billerica Ave_Building #6
N. Billerica, MA 01862 N. Billerica, MA 01862
USA USA
Phone: + 1 978 964 2287 Phone: + 1 978 964 2287
EMail: sporetsky@avici.com EMail: sporetsky@avici.com
Network-layer Traffic Control Mechanisms
7. Full Copyright Statement 7. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Copyright (C) The Internet Society (1998). All Rights
Reserved. Reserved.
This document and translations of it may be copied and This document and translations of it may be copied and
furnished to others, and derivative works that comment on or furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above part, without restriction of any kind, provided that the
copyright notice and this paragraph are included on all such above copyright notice and this paragraph are included on all
copies and derivative works. However, this document itself may such copies and derivative works. However, this document
not be modified in any way, such as by removing the copyright itself may not be modified in any way, such as by removing
notice or references to the Internet Society or other Internet the copyright notice or references to the Internet Society or
organizations, except as needed for the purpose of developing other Internet organizations, except as needed for the
Internet standards in which case the procedures for copyrights purpose of developing Internet standards in which case the
defined in the Internet Standards process must be followed, or procedures for copyrights defined in the Internet Standards
as required to translate it into languages other than English. process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is assigns. This document and the information contained herein
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FOR A PARTICULAR PURPOSE. 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/