draft-ietf-bmwg-dsmterm-00.txt   draft-ietf-bmwg-dsmterm-01.txt 
Network Working Group Jerry Perser Network Working Group Jerry Perser
INTERNET-DRAFT Spirent INTERNET-DRAFT Spirent
Expires in: August 2001 David Newman Expires in: December 2001 David Newman
Network Test Network Test
Sumit Khurana Sumit Khurana
Telcordia Telcordia
Shobha Erramilli Shobha Erramilli
Telcordia Telcordia
Scott Poretsky Scott Poretsky
Avici Avici Systems
February 2001 June 2001
Terminology for Benchmarking Network-layer Terminology for Benchmarking Network-layer
Traffic Control Mechanisms Traffic Control Mechanisms
<draft-ietf-bmwg-dsmterm-00.txt> <draft-ietf-bmwg-dsmterm-01.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.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 Channel Capacity ..........................................3
3.2 Classification ............................................4 3.2 Classification ............................................4
3.3 Code Point Forwarding Rate ................................4 3.3 Codepoint Set.............................................4
3.4 Conforming ................................................5 3.4 Conforming ................................................5
3.5 Congestion ................................................5 3.5 Congestion ................................................5
3.6 Congestion Management .....................................6 3.6 Congestion Management .....................................6
3.7 Delay .....................................................6 3.7 Delay.....................................................7
3.8 Expected Output Vector ....................................7 3.8 Expected Vector...........................................7
Network-layer Traffic Control Mechanisms
3.9 Flow ......................................................8 3.9 Flow ......................................................8
3.10 Jitter ...................................................8 3.10 Forwarding Vector .......................................9
3.11 Nonconforming ............................................9 3.11 Jitter...................................................9
3.12 Offered Load Vector .....................................10 3.12 Nonconforming...........................................10
3.13 Policy ..................................................10 3.13 Offered Vector..........................................11
3.14 Provision ...............................................11 3.14 Stream..................................................11
3.15 Sequence number .........................................11 3.15 Tail dropping...........................................12
3.16 Shaping .................................................12 3.16 Test Sequence number....................................12
3.17 Stream ..................................................12 3.17 Unburdened Response.....................................13
3.18 Tail dropping ...........................................13 4. Security Considerations.....................................13
3.19 Unburdened Response .....................................14
4. Security Considerations .....................................14
5. References ..................................................14 5. References ..................................................14
6. Author's Address ............................................15 6. Author's Address............................................14
7. Full Copyright Statement ....................................16 7. Full Copyright Statement....................................15
1. Introduction 1. Introduction
Driven by Internet economics, service providers and enterprises Driven by Internet economics, service providers and enterprises
alike have shown strong interest in adding traffic-control alike have shown strong interest in adding traffic-control
capabilities to network devices. These capabilities would enable capabilities to network devices. These capabilities would enable
network operators to define and deliver minimum or maximum levels of network operators to define and deliver minimum or maximum levels of
bandwidth, delay, and jitter for multiple classes of traffic. bandwidth, delay, and jitter for multiple classes of traffic.
Perhaps more importantly, network operators would be able to set Perhaps more importantly, network operators would be able to set
pricing according to the level of service delivered. pricing according to the level of service delivered.
Networking device manufacturers have responded with a bewildering Networking device manufacturers have responded with a wide variety
array of mechanisms for controlling network traffic. While there are of approaches for controlling network traffic. While there are
numerous _policy management_ and _quality of service_ frameworks, numerous ˘policy management÷ and ˘quality of service÷ frameworks,
many of them rely on one of two network-layer mechanisms for the many of them rely on one of two network-layer mechanisms for the
actual control of forwarding rate, delay, and jitter. These two actual control of forwarding rate, delay, and jitter. These two
mechanisms are the IP precedence setting in the IP header and the mechanisms are the IP precedence setting in the IP header and the
diff-serve code point (DSCP) defined in [3]. diff-serv code point (DSCP) defined in [3].
This document describes the various terms to be used in benchmarking This document describes the various terms to be used in benchmarking
devices that implement traffic control based on IP precedence or devices that implement traffic control based on IP precedence or
DSCP criteria. This document is narrowly focused, in that it DSCP criteria. This document is narrowly focused, in that it
describes only terms for measuring behavior of a device or a group describes only terms for measuring behavior of a device or a group
of devices using one of these two mechanisms. End-to-end and of devices using one of these two mechanisms. End-to-end and
service-level measurements are beyond the scope of this document. service-level measurements are beyond the scope of this document.
This document introduces several new terms that will allow This document introduces several new terms that will allow
measurements to be taken during periods of congestion. New measurements to be taken during periods of congestion. New
terminology is needed because most existing benchmarking terms terminology is needed because most existing benchmarking terms
assume the absence of congestion. For example, throughput is one of assume the absence of congestion. For example, throughput is one of
the most widely used measurements _- yet RFC 1242 defines throughput 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 as a rate in the absence of loss. As a result, throughput is not a
meaningful measurement where congestion exists. meaningful measurement where congestion exists.
Another key difference from existing benchmarking terminology is the Another key difference from existing benchmarking terminology is the
definition of measurements as observed on egress as well as ingress definition of measurements as observed on egress as well as ingress
of a device/system under test. Again, the existence of congestion of a device/system under test. Again, the existence of congestion
requires the addition of egress measurements as well as those taken requires the addition of egress measurements as well as those taken
Network-layer Traffic Control Mechanisms
on ingress; without observing traffic leaving a device it is not on ingress; without observing traffic leaving a device it is not
possible to say whether traffic-control mechanisms effectively dealt possible to say whether traffic-control mechanisms effectively dealt
with congestion. with congestion.
The principal measurements introduced in this document are The principal measurements introduced in this document are rate
forwarding rate, latency, and jitter, all of which can be observed vectors, delay, and jitter, all of which can be observed with or
with or without congestion of the DUT/SUT. 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 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 document. should be consulted before attempting to make use of this document.
RFC 2474 " Definition of the Differentiated Services Field (DS RFC 2474 "Definition of the Differentiated Services Field (DS Field)
Field) in the IPv4 and IPv6 Headers" section 2, contains discussions in the IPv4 and IPv6 Headers" section 2, contains discussions of a
of a number of terms relevant to network-layer traffic control number of terms relevant to network-layer traffic control mechanisms
mechanisms and should also be consulted. 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 template
for definitions set out in Section 2 of RFC 1242. Definitions are for definitions set out in Section 2 of RFC 1242. Definitions are
indexed and grouped together in sections for ease of reference. indexed and grouped together in sections for ease of reference.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
3. Term definitions 3. Term definitions
skipping to change at page 4, line 5 skipping to change at page 4, line 5
interface(s) of the DUT/SUT. interface(s) of the DUT/SUT.
Ingress-based measurements do not account for congestion of the Ingress-based measurements do not account for congestion of the
DUT/SUT. Channel capacity, as an egress measurement, does take DUT/SUT. Channel capacity, as an egress measurement, does take
congestion into account. congestion into account.
Understanding channel capacity is a necessary precursor to any Understanding channel capacity is a necessary precursor to any
measurement involving congestion. Throughput numbers can be measurement involving congestion. Throughput numbers can be
higher than channel capacity because of queueing. higher than channel capacity because of queueing.
Network-layer Traffic Control Mechanisms
Measurement units: Measurement units:
N-octet packets per second N-octet packets per second
Issues: Issues:
See Also: See Also:
Throughput [1] Throughput [1]
3.2 Classification 3.2 Classification
Definition: Definition:
Local mapping of Policies to the IP Precedence or DSCP value in Selection of packets based on the contents of packet header
each frame. according to defined rules.
Discussion: Discussion:
Could be based on the DS field or IP Precedence in the packet Packets can be selected based on the DS field or IP Precedence
header. Could be based on MF criteria such as IP Source and in the packet header. Classification can also be based on
destination addresses, protocol and port number. Multi-Field (MF) criteria such as IP Source and destination
addresses, protocol and port number.
Covers reclassification. A Hop does not know if a previous Hop
classified the packets. Since the scope of the document is a
per-hop-behavior, we avoid end-to-end discussions.
Classification should cover all cases defined in policy. This Classification determines the per-hop behaviors and traffic
may include rules mandating packet drops, not just forwarded conditioning functions such as shaping and dropping that are to
packets. be applied to the packet.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Rules
3.3 Code Point Forwarding Rate 3.3 Codepoint Set
Definition: Definition:
The number of packets per second in for all packets containing The set of all DS Code-points or IP precedence values used
a single DSCP (or IP precedence) that a device can be observed during the test duration.
to successfully transmit to the correct destination interface
in response to a specified offered load.
Discussion: Discussion:
- CP based, not port nor IP stream based. Describes all the code-point markings associated with packets
- Per-hop measurement. A DUT may change the DSCP for a that are input to the DUT/SUT. For each entry in the codepoint
multiple-hop measurement. set, there are associated vectors describing the rate of
traffic containing that particular DSCP or IP precedence value.
Measurement units: The treatment that a packet belonging to a particular code-
point gets is subject to the DUT classifying packets to map to
Network-layer Traffic Control Mechanisms
N-octet packets per second the correct PHB. Moreover, the forwarding treatment in general
is also dependent on the complete set of offered vectors.
Issues: Measurement Units:
n/a
See Also: See Also:
3.4 Conforming 3.4 Conforming
Definition: Definition:
A packet meeting a certain policy. Packets that lie within the bounds specified by a traffic
profile.
Discussion: Discussion:
Consider a policy that allows a given application to consume Rules may be configured that allow a given traffic class to
only X bit/s of channel capacity and no more. consume only X bit/s of channel capacity and no more. All
additional packets are dropped. All packets that constitute
In a congestion scenario, some individual packets will be the first X bits/s measured over a period of time specified by
conforming and others will not. the traffic profile, are then said to be conforming whereas
those exceeding the bound are non conforming.
It cannot be said that an entire stream or flow is conforming, In particular in a congestion scenario, some individual packets
since an offered load that exceeds policy boundaries will will be conforming and others will not.
necessarily carry some nonconforming traffic.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Expected Vector
Forwarding Vector
Offered Vector
3.5 Congestion 3.5 Congestion
Definition: Definition:
A condition in which one or more egress interfaces are offered A condition in which one or more egress interfaces are offered
more packets than can be forwarded at any given instant. more packets than can be forwarded at any given instant.
Discussion: Discussion:
This condition is a superset of the overload definition [2]. This condition is a superset of the overload definition [2].
That definition assumes the overload is introduced by strictly That definition assumes the overload is introduced strictly by
by the tester on ingress of a DUT/SUT. That may or may not be the tester on ingress of a DUT/SUT. That may or may not be the
the case here. case here.
Network-layer Traffic Control Mechanisms
Another difference is that with multiple-DUT measurements, Another difference is that with multiple-DUT measurements,
congestion may occur at multiple points. For example, multiple congestion may occur at multiple points. For example, multiple
edge devices collectively may congest a core device. In edge devices collectively may congest a core device. In
contrast, overload [1] deals only with overload on ingress. contrast, overload [1] deals only with overload on ingress.
Ingress observations alone are not sufficient to cover all Ingress observations alone are not sufficient to cover all
cases in which congestion may occur. A device with an infinite cases in which congestion may occur. A device with an infinite
amount of memory could buffer an infinite amount of packets, amount of memory could buffer an infinite amount of packets,
and eventually forward all of them. However, these packets may and eventually forward all of them. However, these packets may
skipping to change at page 6, line 35 skipping to change at page 6, line 42
3.6 Congestion Management 3.6 Congestion Management
Definition: Definition:
An implementation of one or more per-hop-behaviors to avoid or An implementation of one or more per-hop-behaviors to avoid or
minimize the condition of congestion. minimize the condition of congestion.
Discussion: Discussion:
Congestion management may seek either to control congestion or Congestion management may seek either to control congestion or
avoid it altogether. Such mechanisms classify packets based avoid it altogether. Such mechanisms classify packets based
upon IP Precedence or DSCP settings in a packet's IP header. upon IP Precedence or DSCP settings in a packetĂs IP 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 gives one or more service classes Congestion control mechanisms gives one or more service classes
preferential treatment over other classes during periods of preferential treatment over other classes during periods of
congestion. congestion.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Network-layer Traffic Control Mechanisms
3.7 Delay 3.7 Delay
Definition: Definition:
The time interval starting when the last bit of the input IP
The time interval starting when the last bit of the input frame packets reaches the input port of the DUT/SUT and ending when
reaches the input port of the DUT/SUT and ending when the last the last bit of the output IP packets is seen on the output
bit of the output frame is seen on the output port of the port of the DUT/SUT.
DUT/SUT.
Discussion: Discussion:
Delay measurement is measured the same regardless of the type Delay is measured the same regardless of the type of DUT/SUT.
of DUT/SUT. Latency [1] require some knowledge of whether the Latency [1] require some knowledge of whether the DUT/SUT is a
DUT/SUT is a "store and forward" or a "bit forwarding" device. "store and forward" or a "bit forwarding" device. The fact
The fact that a DUT/SUT's technology has a lower delay than that a DUT/SUT's technology has a lower delay than another
another technology should be visible in the measurement. technology should be visible.
The measurement point of the last bit is more like the way an The measurement point at the end is more like the way an
IP datagram is processed. A datagram is not passed up or down internet datagram is processed. An internet datagram is not
the stack unless it is complete. Competition happens at the passed up or down the stack unless it is complete. Completion
last bit of the datagram. occurs once the last bit of the IP packet has been received.
Delay can be run at any offered load. Recommend at or below Delay can be run at any offered load. Recommend at or below
the channel capacity for non-congested delay. For congested the channel capacity for non-congested delay. For congested
delay, run the offered load above the channel capacity. delay, run the offered load above the channel capacity.
Measurement units: Measurement units:
Seconds. Seconds.
Issues: Issues:
See Also: See Also:
3.8 Expected Output Vector 3.8 Expected Vector
Definition: Definition:
A vector describing the expected output rate of packets having A vector describing the expected output rate of packets having
a specific code-point for each code-point in the code-point set a specific code-point. The value is dependent on the set of
depending on the offered load vector and device PHB offered vectors and configuration of the DUT.
configurations of the DUT/SUT.
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
discrimination happens for behavior aggregates when a specific discrimination happens for behavior aggregates when a specific
traffic mix consisting of multiple behavior aggregates is traffic mix consisting of multiple behavior aggregates is
applied. This term attempts to capture the expected behavior applied. This term attempts to capture the expected behavior,
for which the device is configured given a certain load. for which the device is configured, when subjected to a certain
offered load.
Network-layer Traffic Control Mechanisms
The actual algorithms or mechanism, that the DUT uses to The actual algorithms or mechanism, that the DUT uses to
achieve service discrimination, is not important in describing achieve service discrimination, is not important in describing
the expected output vector. the expected vector.
Measurement units: Measurement units:
bits per second N-octets packets per second
N-octets per second
See Also: See Also:
Offered Load Vector Forwarding Vector
Offered Vector
Codepoint Set
3.9 Flow 3.9 Flow
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 which interface they ingress and egress Packets are groups by the ingress and egress interfaces they
the 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 on destination IP addresses. All packets in a flow must enter on
the same ingress interface and exit on the same egress 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 [3] are a subset of flows. As defined in [3], Microflows [3] are a subset of flows. As defined in [3],
microflows require application-to-application measurement. In microflows require application-to-application measurement. In
contrast, flows use lower-layer classification criteria. Since contrast, flows use lower-layer classification criteria. Since
this document focuses on network-layer classification criteria, this document focuses on network-layer classification criteria,
we concentrate here on the use of network-layer identifiers in we concentrate here on the use of network-layer identifiers in
describing a flow. Flow identifiers also may reside at the describing a flow. Flow identifiers also may reside at the
data-link, transport, or application layers of the ISO model. data-link, transport, or application layers of the ISO model.
However, identifiers other than those at the network layer are However, identifiers other than those at the network layer are
out of scope for this document. out of scope for this document.
A flow may contain a single code point/IP precedence or may A flow may contain a single code point/IP precedence value or
contain multiple values destined for a single egress interface. may contain multiple values destined for a single egress
This is determined by the test methodology. interface. This is determined by the test methodology.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Microflow [3] Microflow [3]
Network-layer Traffic Control Mechanisms
Streams Streams
3.10 Jitter 3.10 Forwarding Vector
Definition: Definition:
Variation in delay. The number of packets per second for all packets containing a
single DSCP (or IP precedence) that a device can be observed to
successfully transmit to the correct destination interface in
response to an offered vector.
Discussion: Discussion:
Forwarding Vector is expressed as pair of numbers. Both the
codepoint (or IP precedence) value AND the packets per second
value combine to make a vector.
Jitter as the absolute value of the difference between the The forwarding vector represents packet rate based on their
delay measurement of two adjacent packets |D(i) - D(i+1)|. The codepoint or IP precedence value. It is not necessary based on
jitter between two packets is reported as the "instantaneous stream or flow. The forwarding vector may be expresses as ˘per
jitter". Packets lost are not counted in the jitter port÷ or ˘of the DUT/SUT÷.
measurement.
Average Jitter is the average of the instantaneous jitter
measured during the test duration.
Peak-to-peak jitter is the maximum delay minus the minimum
delay of the packets forwarded by the DUT/SUT.
Measurement units:
Seconds (instantaneous)
Seconds P-P (peak to peak)
Seconds avg (average)
Issues:
See Also:
3.11 Nonconforming
Definition:
A packet in violation of a given policy.
Discussion:
A packet can be said to be nonconforming when it violates the
terms of a given policy. For example, a policy may set an upper
bound on bandwidth for a given class of traffic. When a DUT/SUT
is offered packets of that class in excess of the terms allowed
by the policy, the DUT/SUT must discard some packets of that
class. The discarded packets are nonconforming to policy.
Note that the decision to drop or forward packets is Forwarding Vector is a per-hop measurement. The DUT/SUT may
essentially time-based. Even though two packets may share a change the codepoint or IP precedence value for a multiple-hop
common DSCP or IP precedence value, one may be forwarded and measurement.
one may be dropped depending on when the packets are offered to
the DUT. It is the combination of classification and policy
that determines whether packets are conforming or
nonconforming.
Measurement units: Measurement units:
n/a N-octet packets per second
Issues: Issues:
See Also: See Also:
Codepoint Set
Expected Vector
Offered Vector.
3.12 Offered Load Vector 3.11 Jitter
Definition: Definition:
A vector describing the rate at which packets having a specific Variation in a stream's delay.
code-point are offered to the DUT/SUT, for each code-point in a
code-point set.
Discussion: Discussion:
Offered loads across the different code-point classes, Jitter is the absolute value of the difference between the
constituting a code-point set, determine the metrics associated delay measurement of two packets belonging to the same stream.
with a specific code-point traffic class.
Measurement Units:
bits per second
N-octets per second
Issues:
Packet size.
Traffic descriptors such as peak rate, average rate etc.
See Also:
Expected output vector
3.13 Policy The jitter between two consecutive packets in a stream is
reported as the "instantaneous jitter". Instantaneous jitter
can be expressed as |D(i) ű D(i+1)| where D equals the delay
and i is the test sequence number. Packets lost are not
counted in the jitter measurement.
Definition: Network-layer Traffic Control Mechanisms
A rule or set of rules used to classify packets.
Discussion: Average Jitter is the average of the instantaneous jitter
In the context of data networking, policies consist of one or measured during the test duration.
(usually) more rules to administer, manage, and control access
to network resources. These resources include applications,
devices, bandwidth, and any other elements attached to a common
network.
In the context of network devices, PHBs are the mechanisms by Peak-to-peak jitter is the maximum delay minus the minimum
which a policy may be enforced. Packets offered to a DUT/SUT delay of the packets forwarded by the DUT/SUT.
may be conforming or nonconforming to a given policy. A PHB may
cause some packets to be dropped or forwarded based on the
rules laid down by a given policy.
Measurement units: Measurement units:
n/a Seconds (instantaneous)
Seconds P-P (peak to peak)
Seconds avg (average)
Issues: Issues:
Mean
Standard Deviation
Median
90th percentile
Inter Quartile Range
See Also: See Also:
Stream
Conforming 3.12 Nonconforming
Nonconforming
PHB
3.14 Provision
Definition: Definition:
Configuration of the DUT/SUT to match a specified rule or rules Packets that lie outside the parameter bounds of a given
in the policy. traffic profile.
Discussion: Discussion:
A DUT/SUT must be configured in accordance with the rules of a Rules may be configured for a given traffic class based on
policy for that policy's rules to be enforced. Provision may be parameters, such as an upper bound on the rate of packet
done on a dynamic or a static basis. arrivals. All packets that lie outside the bounds specified by
the traffic profile, measured over a period of time specified
in the traffic profile, are said to be nonconforming.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Conforming Conforming
Nonconforming
PHB
Policy
3.15 Sequence number 3.13 Offered Vector
Definition: 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 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 and number of duplicate
packets.
The recommended algorithm to use to change the sequence number
on sequential packets is an incrementing value.
Measurement units: Network-layer Traffic Control Mechanisms
n/a
Issues:
See Also:
Stream
3.16 Shaping
Definition: A vector describing the rate at which packets having a specific
DUT/SUT control of code point forwarding rate so that a flow or code-point are offered to the DUT/SUT.
stream does not exceed or drop below a specified rate set in
the policy.
Discussion: Discussion:
[3] defines a behavior aggregate in which a DUT/SUT performs a Offered loads across the different code-point classes,
specific forwarding treatment on a group of packets. Shaping is constituting a code-point set, determine the metrics associated
one such treatment: A device may drop or forward packets within with a specific code-point traffic class.
a stream or flow depending on whether the packets are in or out
of the terms of the policy.
Measurement units:
n/a Measurement Units:
N-octets packets per second
Issues: Issues:
Packet size.
See Also: See Also:
Conforming Expected Vector
Nonconforming Forwarding Vector
Policy Codepoint Set
3.17 Stream 3.14 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 shares a common content such as type (IP, receiver. A stream shares a common content such as type (IP,
UDP), frame size, or payload. UDP), frame size, or payload.
Discussion: Discussion:
Streams are tracked by "sequence number" or "unique signature Streams are tracked by "sequence number" or "unique signature
field" (RFC 2889). Streams define how individual packet's field" (RFC 2889). Streams define how individual packet's
statistics are grouped together to form an intelligible statistics are grouped together to form an intelligible
summary. summary.
Common stream groupings would be by egress interface, Common stream groupings would be by egress interface,
destination address, source address, DCSP, or IP precedence. A destination address, source address, DSCP, or IP precedence. A
stream using sequence numbers can track the ordering of packets stream using sequence numbers can track the ordering of packets
as they transverse the DUT/SUT. as they transverse the DUT/SUT.
Streams are not restricted to a pair of source and destination Streams are not restricted to a pair of source and destination
interfaces as long as all packets are tracked as a single interfaces as long as all packets are tracked as a single
entity. A mulitcast stream can be forward to multiple entity. A mulitcast stream can be forward to multiple
destination interfaces. destination interfaces.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Flow Flow
MicroFlow [3] MicroFlow [3]
Sequence number Network-layer Traffic Control Mechanisms
3.18 Tail dropping Test sequence number
3.15 Tail dropping
Definition: Definition:
The condition in which a DUT/SUT discards newly arriving The condition in which a congested DUT/SUT discards newly
packets. arriving packets.
Discussion: Discussion:
Every DUT/SUT has a finite amount of traffic it can forward, Every DUT/SUT has a finite amount of traffic it can forward,
beyond which congestion occurs. Once the offered load crosses beyond which congestion occurs. Once the offered load crosses
the congestion threshold, the device may discard any additional the congestion threshold, the device may discard any additional
traffic that arrives until congestion clears. traffic that arrives until congestion clears.
Tail dropping is typically a function of offered load exceeding Tail dropping is typically a function of offered load exceeding
a DUT/SUT's buffer capacity, but other factors internal to the a DUT/SUTĂs buffer capacity, but other factors internal to the
DUT/SUT may also come into play. In terms of what is externally DUT/SUT may also come into play. In terms of what is externally
observable, tail dropping can be said to occur only when observable, tail dropping can be said to occur only when
offered load exceeds channel capacity. Since a DUT/SUT may offered load exceeds channel capacity. Since a DUT/SUT may
buffer traffic on ingress, the actual threshold for tail buffer traffic on ingress, the actual threshold for tail
dropping may be higher than channel capacity. dropping may be higher than channel capacity.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
Some congestion management mechanisms seek to avoid tail dropping by Some congestion management mechanisms seek to avoid tail
discarding packets before offered load exceeds channel capacity. In dropping by discarding packets before offered load exceeds
the presence of such mechanisms, neither congestion nor tail channel capacity. In the presence of such mechanisms, neither
dropping should occur. congestion nor tail dropping should occur.
See Also: See Also:
Channel capacity Channel capacity
Congestion Congestion
3.19 Unburdened Response
3.16 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 sequence number value and the
traffic receiver checks the value upon receipt of the packet.
The traffic generator changes the value on each packet
transmitted based on an algorithm agreed to by the traffic
receiver.
Network-layer Traffic Control Mechanisms
The traffic receiver keeps track of the sequence numbers on a
per stream basis. In addition to number of received packets,
the traffic receiver may also report number of in-sequence
packets, number of out-sequence packets and number of duplicate
packets.
The recommended algorithm to use to change the sequence number
on sequential packets is an incrementing value.
Measurement units:
n/a
Issues:
See Also:
Stream
3.17 Unburdened Response
Definition: Definition:
A performance measure obtained when mechanisms used to support A performance measure obtained when mechanisms used to support
DiffServ are disabled. IP precedence and DiffServ are disabled.
Discussion: Discussion:
Enabling Diffserv mechanisms such as scheduling algorithms may Enabling Diffserv mechanisms such as scheduling algorithms may
impose an additional processing overhead for packets, which may impose an additional processing overhead for packets, which may
cause the aggregate response to suffer even when traffic cause the aggregate response to suffer even when traffic
belonging to only one class, the best effort class, is offered belonging to only one class, the best effort class, is offered
to the device. Comparisons with "unburdened performance" may to the device. Comparisons with "unburdened performance" may
thus be in order when obtaining metrics to ensure that enabling thus be in order when obtaining metrics to ensure that enabling
Diffserv mechanisms doesn't impose an excessive performance Diffserv mechanisms doesn't impose an excessive performance
penalty. penalty.
Measurement units: Measurement units:
TBD.
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 effect 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 5. References
[1] Bradner, S., Editor, "Benchmarking Terminology for Network [1] Bradner, S., Editor, "Benchmarking Terminology for Network
Network-layer Traffic Control Mechanisms
Interconnection Devices", RFC 1242, July 1991. Interconnection Devices", RFC 1242, July 1991.
[2] Mandeville, R., "Benchmarking Terminology for LAN Switching [2] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998. 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 the
Differentiated Services Field (DS Field) in the IPv4 and Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998. 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.
skipping to change at page 15, line 18 skipping to change at page 14, line 32
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
David Newman David Newman
Network Test Network Test
321 Newark St., Suite 301 31324 Via Colinas, Suite 113
Hoboken, NJ 07030 Westlake Village, CA 91362
USA USA
Phone: + 1 201 798 9999 Phone: + 1 818 889 0011, x10
EMail: dnewman@networktest.com EMail: dnewman@networktest.com
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 Telcordia Technologies
331 Newman Springs Road, 331 Newman Springs Road,
Navesink, NJ 07701 Navesink, NJ 07701
USA USA
Network-layer Traffic Control Mechanisms
Phone: + 1 732 758 5508 Phone: + 1 732 758 5508
EMail: shobha@research.telcordia.com EMail: shobha@research.telcordia.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
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 above
 End of changes. 

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