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