draft-ietf-bmwg-dsmterm-10.txt   draft-ietf-bmwg-dsmterm-11.txt 
Network Working Group Jerry Perser Network Working Group Jerry Perser
INTERNET-DRAFT INTERNET-DRAFT
Expires in: October 2005 Scott Poretsky Expires in: January 2006 Scott Poretsky
Quarry Technologies Reef Point Systems
Shobha Erramilli Shobha Erramilli
Qnetworx Qnetworx
Sumit Khurana Sumit Khurana
Telcordia Telcordia
February 2005 July 2005
Terminology for Benchmarking Network-layer Terminology for Benchmarking Network-layer
Traffic Control Mechanisms Traffic Control Mechanisms
<draft-ietf-bmwg-dsmterm-10.txt> <draft-ietf-bmwg-dsmterm-11.txt>
Intellectual Property Rights (IPR) statement: Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, or applicable patent or other IPR claims of which he or she is aware
will be disclosed, and any of which I become aware will be disclosed, have been or will be disclosed, and any of which he or she becomes
in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
This document is an Internet-Draft and is in full conformance with patent or other IPR claims of which I am aware have been disclosed,
all provisions of Section 10 of RFC2026. and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document describes terminology for the benchmarking of This document describes terminology for the benchmarking of
devices that implement traffic control based on IP precedence or devices that implement traffic control based on IP precedence or
diff-serv code point criteria. The terminology is to be applied diff-serv code point criteria. The terminology is to be applied
to measurements made on the data plane to evaluate IP traffic to measurements made on the data plane to evaluate IP traffic
control meachanisms. control mechanisms.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
Table of Contents Table of Contents
1. Introduction .............................................. 3 1. Introduction .............................................. 3
2. Existing definitions ...................................... 3 2. Existing definitions ...................................... 3
3. Term definitions............................................4 3. Term definitions............................................4
3.1 Configuration Terms 3.1 Configuration Terms
3.1.1 Classification.........................................4 3.1.1 Classification.........................................4
3.1.2 Codepoint Set..........................................4 3.1.2 Codepoint Set..........................................4
skipping to change at page 2, line 55 skipping to change at page 2, line 55
3.4.4.1 Forwarding Vector.................................23 3.4.4.1 Forwarding Vector.................................23
3.4.4.2 Loss Vector.......................................24 3.4.4.2 Loss Vector.......................................24
3.4.4.3 Sequence Vector...................................24 3.4.4.3 Sequence Vector...................................24
3.4.4.4 Instantaneous Delay Vector........................25 3.4.4.4 Instantaneous Delay Vector........................25
3.4.4.5 Average Delay Vector..............................26 3.4.4.5 Average Delay Vector..............................26
3.4.4.6 Maximum Delay Vector..............................27 3.4.4.6 Maximum Delay Vector..............................27
3.4.4.7 Minimum Delay Vector..............................28 3.4.4.7 Minimum Delay Vector..............................28
3.4.4.8 Instantaneous Jitter Vector.......................28 3.4.4.8 Instantaneous Jitter Vector.......................28
3.4.4.9 Average Jitter Vector.............................29 3.4.4.9 Average Jitter Vector.............................29
3.4.4.10 Peak-to-peak Jitter Vector.......................30 3.4.4.10 Peak-to-peak Jitter Vector.......................30
4. Acknowledgments............................................31 4. IANA Considerations........................................31
5. Security Considerations....................................31 5. Security Considerations....................................31
6. Normative References.......................................31 6. Acknowledgments............................................31
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
7. Informative References.....................................32 7. References.................................................32
8. Author's Address...........................................33 8. Author's Address...........................................33
9. Full Copyright Statement...................................34 9. Full Copyright Statement...................................34
1. Introduction 1. Introduction
New terminology is needed because most existing measurements New terminology is needed because most existing measurements
assume the absence of congestion and only a single per-hop- assume the absence of congestion and only a single per-hop-
behavior. This document introduces several new terms that will behavior. This document introduces several new terms that will
allow measurements to be taken during periods of congestion. allow measurements to be taken during periods of congestion.
skipping to change at page 11, line 26 skipping to change at page 11, line 26
delay of two consecutive received packets belonging to the delay of two consecutive received packets belonging to the
same stream. same stream.
Discussion: Discussion:
The delay fluctuation between two consecutive received The delay fluctuation between two consecutive received
packets in a stream is reported as the jitter. Jitter can be packets in a stream is reported as the jitter. Jitter can be
expressed as |D(i) - D(i-1)| where D equals the delay and i expressed as |D(i) - D(i-1)| where D equals the delay and i
is the order the packets were received. is the order the packets were received.
Under loss, jitter can be measured between non-consecutive Under loss, jitter can be measured between non-consecutive
test sequence numbers. When Traffic Control Mechanisms are test sequence numbers. When IP Traffic Control Mechanisms are
losing packets, the Forwarding Delay may fluctuate as a dropping packets, fluctuating Forwarding Delay may be observed.
response. Jitter MUST be able to benchmark the delay Jitter MUST be able to benchmark the delay variation
variation with or with out loss. independent of packet loss.
Jitter is related to the ipdv [De02] (IP Delay Variation) by Jitter is related to the ipdv [De02] (IP Delay Variation) by
taking the absolute value of the ipdv. The two metrics will taking the absolute value of the ipdv. The two metrics will
produce different mean values. Mean Jitter will produce a produce different mean values. Mean Jitter will produce a
positive value, where the mean ipdv is typically zero. positive value, where the mean ipdv is typically zero.
Measurement units: Measurement units:
Seconds Seconds
See Also: See Also:
Forwarding Delay Forwarding Delay
Jitter variation [Ja99] Jitter variation [Ja99]
ipdv [De02] ipdv [De02]
interarrival jitter [Sc96] interarrival jitter [Sc96]
3.2.6 Undifferentiated Response 3.2.6 Undifferentiated Response
Definition: Definition:
The vector(s) obtained when mechanisms used to support diff- The vector(s) obtained when mechanisms used to support
serv or IP precedence are disabled. diff-serv or IP precedence are disabled.
Discussion: Discussion:
Enabling diff-serv or IP precedence mechanisms may impose Enabling diff-serv or IP precedence mechanisms may impose
additional processing overhead for packets. This overhead additional processing overhead for packets. This overhead
may degrade performance even when traffic belonging to only may degrade performance even when traffic belonging to only
one class, the best-effort class, is offered to the device. one class, the best-effort class, is offered to the device.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
Measurements with "undifferentiated response" SHOULD be made Measurements with "undifferentiated response" SHOULD be made
skipping to change at page 15, line 23 skipping to change at page 15, line 23
Discussion: Discussion:
The traffic generator sets the test sequence number value and The traffic generator sets the test sequence number value and
the traffic receiver checks the value upon receipt of the the traffic receiver checks the value upon receipt of the
packet. The traffic generator changes the value on each packet. The traffic generator changes the value on each
packet transmitted based on an algorithm agreed to by the packet transmitted based on an algorithm agreed to by the
traffic receiver. traffic receiver.
The traffic receiver keeps track of the sequence numbers on a The traffic receiver keeps track of the sequence numbers on a
per stream basis. In addition to number of received packets, per stream basis. In addition to number of received packets,
the traffic receiver may also report number of in-sequence the traffic receiver may also report number of in-sequence
packets, number of out-of-sequence packets, number of duplicate packets, number of out-of-sequence packets, number of
packets, and number of reordered packets. duplicate packets, and number of reordered packets.
The RECOMMENDED algorithm to use to change the sequence The RECOMMENDED algorithm to use to change the sequence
number on sequential packets is an incrementing value. number on sequential packets is an incrementing value.
Measurement units: Measurement units:
n/a n/a
See Also: See Also:
Stream Stream
skipping to change at page 31, line 6 skipping to change at page 31, line 6
See Also: See Also:
Jitter Jitter
Forwarding Vector Forwarding Vector
Stream Stream
Expected Vectors Expected Vectors
Average Jitter Vector Average Jitter Vector
Peak-to-peak Jitter Vector Peak-to-peak Jitter Vector
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
4. Acknowledgments 4. IANA Considerations
The authors gratefully acknowledge the contributions of the This document requires no IANA considerations.
IETF's benchmarking working group members in reviewing this
document. The authors would like to express our thanks to
David Newman for his consistent and valuable assistance
throughout the development of this document. The following
individuals also made noteworthy contributions to the
editors' understanding of the subject matter: John Dawson,
Kevin Dubray, and Kathleen Nichols.
5. Security Considerations 5. Security Considerations
Documents of this type do not directly affect the security of Documents of this type do not directly affect the security of
the Internet or of corporate networks as long as benchmarking the Internet or of corporate networks as long as benchmarking
is not performed on devices or systems connected to is not performed on devices or systems connected to
production networks. production networks.
Packets with unintended and/or unauthorized DSCP or IP Packets with unintended and/or unauthorized DSCP or IP
precedence values may present security issues. Determining precedence values may present security issues. Determining
the security consequences of such packets is out of scope for the security consequences of such packets is out of scope for
this document. this document.
6. Normative References 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.
7. References
7.1 Normative References
[Br91] Bradner, S., "Benchmarking Terminology for Network [Br91] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991. Interconnection Devices", RFC 1242, July 1991.
[Br97] Bradner, S., "Key words for use in RFCs to Indicate [Br97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997 Requirement Levels", RFC 2119, March 1997
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN [Ma98] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998. Switching Devices", RFC 2285, July 1998.
[Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition [Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition
of the Differentiated Services Field (DS Field) in the of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers", RFC 2474, December 1998. IPv4 and IPv6 Headers", RFC 2474, December 1998.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
7. Informative References 7.2 Informative References
[Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay [Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay
Metric for IPPM", RFC 2679, September 1999 Metric for IPPM", RFC 2679, September 1999
[Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
Weiss, W., "An Architecture for Differentiated Services", Weiss, W., "An Architecture for Differentiated Services",
RFC 2475, December 1998. RFC 2475, December 1998.
[Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for [Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999 Network Interconnect Devices", RFC 2544, March 1999
skipping to change at page 33, line 9 skipping to change at page 33, line 9
January 1999. January 1999.
[Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996 RFC 1889, January 1996
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
8. Authors' Addresses 8. Authors' Addresses
Jerry Perser Jerry Perser
USA USA
Phone:
EMail: jerry@perser.org EMail: jerry@perser.org
Scott Poretsky Scott Poretsky
Quarry Technologies Reef Point Systems
8 New England Executive Park 8 New England Executive Park
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: + 1 508 439 9008 Phone: + 1 508 439 9008
EMail: sporetsky@quarrytech.com EMail: sporetsky@reefpoint.com
Shobha Erramilli Shobha Erramilli
QNetworx Inc QNetworx Inc
1119 Campus Drive West 1119 Campus Drive West
Morganville, NJ 07751 Morganville, NJ 07751
USA USA
Phone:
EMail: shobha@qnetworx.com EMail: shobha@qnetworx.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
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
Intellectual Property Statement Full Copyright Statement
The IETF takes no position regarding the validity or scope of any Intel-
lectual Property Rights or other rights that might be claimed to pertain
to the implementation or use of the technology described in this docu-
ment 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 Copyright (C) The Internet Society (2005).
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this stan-
dard. Please address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Warranty 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Intellectual Property
Copyright (C) The Internet Society (2005). This document is subject to The IETF takes no position regarding the validity or scope of any
the rights, licenses and restrictions contained in BCP 78, and except as Intellectual Property Rights or other rights that might be claimed to
set forth therein, the authors retain all their rights. 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.
 End of changes. 

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