draft-ietf-ippm-reporting-05.txt   draft-ietf-ippm-reporting-06.txt 
Network Working Group S. Shalunov Network Working Group S. Shalunov
Internet-Draft Internet-Draft
Intended status: Standards Track M. Swany Intended status: Standards Track M. Swany
Expires: January 14, 2011 University of Delaware Expires: September 15, 2011 University of Delaware
July 13, 2010 March 14, 2011
Reporting IP Performance Metrics to Users Reporting IP Performance Metrics to Users
draft-ietf-ippm-reporting-05.txt draft-ietf-ippm-reporting-06.txt
Abstract Abstract
The aim of this document is to define a small set of metrics that are The aim of this document is to define a small set of metrics that are
robust, easy to understand, orthogonal, relevant, and easy to robust, easy to understand, orthogonal, relevant, and easy to
compute. The IPPM WG has defined a large number of richly compute. The IPPM WG has defined a large number of richly
parameterized metrics because network measurement has many purposes. parameterized metrics because network measurement has many purposes.
Often, the ultimate purpose is to report a concise set of metrics Often, the ultimate purpose is to report a concise set of metrics
describing a network's current state to an end user. It is for this describing a network's current state to an end user. It is for this
purpose that the present set of metrics is defined, and the document purpose that the present set of metrics is defined, and the document
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 24 skipping to change at page 3, line 24
4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Duplication . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Sample Source . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 10 5.1. One-Way Active Measurement . . . . . . . . . . . . . . . . 10
5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 11 5.2. Round-Trip Active Measurement . . . . . . . . . . . . . . 11
5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 11 5.3. Passive Measurement . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Internationalization Considerations . . . . . . . . . . . . . 15 9. Internationalization Considerations . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Sample Source Code for Computing the Metrics . . . . 17 Appendix A. Sample Source Code for Computing the Metrics . . . . 17
Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 41 Appendix B. Example Report . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Requirements Notation 1. Requirements Notation
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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 5, line 41 skipping to change at page 5, line 41
choose is ad hoc; some metrics are not statistically robust, some are choose is ad hoc; some metrics are not statistically robust, some are
not relevant, and some are not easy to understand; more important not relevant, and some are not easy to understand; more important
than specific shortcomings, however, is the incompatibility: even if than specific shortcomings, however, is the incompatibility: even if
the sets of metrics were perfect, they would still be all different, the sets of metrics were perfect, they would still be all different,
and, therefore, metrics reported by different tools would not be and, therefore, metrics reported by different tools would not be
comparable. comparable.
The set of metrics of this document is meant for human consumption. The set of metrics of this document is meant for human consumption.
It must therefore be small. A screen full of numbers is likely to be It must therefore be small. A screen full of numbers is likely to be
too confusing. Restricting output to a single number would likewise too confusing. Restricting output to a single number would likewise
not be descriptive enough. (Would you pick loss? delay? throughput? not be descriptive enough. This document aims for a small set of
something else?) In this document we aim for a "handful" of numbers. easily understood numbers.
Each of the metrics must be statistically robust. Intuitively, this Each of the metrics must be statistically robust. Intuitively, this
means that having a small number of bad data points and a small means that having a small number of bad data points and a small
amount of noise must not dramatically change the metric. amount of noise must not dramatically change the metric.
Each metric in the set must have, qualitatively, an immediate Each metric in the set must have, qualitatively, an immediate
intuitive meaning that has to be obvious for an advanced end user intuitive meaning that has to be obvious for an advanced end user
without consulting documentation (that is, it has to be clear what without consulting documentation (that is, it has to be clear what
rough meaning, intuitively, the larger values of a given metric rough meaning, intuitively, the larger values of a given metric
have). have).
skipping to change at page 8, line 5 skipping to change at page 7, line 18
network measurements (seconds or at most minutes) and are targeted network measurements (seconds or at most minutes) and are targeted
for real-time display of such measurements. for real-time display of such measurements.
One consideration that would have to be addressed to make these One consideration that would have to be addressed to make these
metrics suitable for longer-term measurements (hours and days) is metrics suitable for longer-term measurements (hours and days) is
that of network availability: during such long periods of time the that of network availability: during such long periods of time the
network may be completely down for some time and it does not seem to network may be completely down for some time and it does not seem to
make sense to average out the reports in such a way that the network make sense to average out the reports in such a way that the network
being down for 1% of the time becomes 1% packet loss. being down for 1% of the time becomes 1% packet loss.
Long-term reporting considerations are now being developed within the
IPPM working group. See the working group draft
[I-D.ietf-ippm-reporting-metrics] (or future RFC) for details.
4. Reportable Metrics Set 4. Reportable Metrics Set
The following metrics comprise the set: The following metrics comprise the set:
1. median delay; 1. median delay;
2. loss ratio; 2. loss ratio;
3. delay spread; 3. delay spread;
skipping to change at page 9, line 17 skipping to change at page 9, line 17
For more information, refer to section 5.1 (Type-P-One-way-Delay- For more information, refer to section 5.1 (Type-P-One-way-Delay-
Percentile) of RFC 2679 [RFC2679] (A One-way Delay Metric for IPPM), Percentile) of RFC 2679 [RFC2679] (A One-way Delay Metric for IPPM),
and supporting text. The Delay Spread is the 75th Type-P-One-way- and supporting text. The Delay Spread is the 75th Type-P-One-way-
Delay-Percentile minus the 25th Type-P-One-way-Delay-Percentile. Delay-Percentile minus the 25th Type-P-One-way-Delay-Percentile.
4.4. Duplication 4.4. Duplication
Duplication is the fraction of packets sent but not lost for which Duplication is the fraction of packets sent but not lost for which
more than a single copy of the packet was received within the timeout more than a single copy of the packet was received within the timeout
period (ideally using the same timeout as in the definition of loss), period (ideally using the same timeout as in the definition of loss).
expressed in percentage points. It is expressed as a percentage.
Note: while most received packets can be ones previously seen, Note: while most received packets can be ones previously seen,
duplication can never exceed 100%. duplication can never exceed 100%.
For more information, see section 5.2 (Type-P-one-way-replicated- For more information, see section 5.2 (Type-P-one-way-replicated-
packet-rate) of RFC 5560 [RFC5560] (A One-Way Packet Duplication packet-rate) of RFC 5560 [RFC5560] (A One-Way Packet Duplication
Metric). Duplication is Type-P-one-way-replicated-packet-rate Metric). Duplication is Type-P-one-way-replicated-packet-rate
expressed as a percentage. expressed as a percentage.
4.5. Reordering 4.5. Reordering
skipping to change at page 11, line 12 skipping to change at page 11, line 12
a given DSCP) used in the measurement. For the time, the end of the a given DSCP) used in the measurement. For the time, the end of the
measurement interval MUST be reported. measurement interval MUST be reported.
5.2. Round-Trip Active Measurement 5.2. Round-Trip Active Measurement
The same default parameters and characterization apply to round-trip The same default parameters and characterization apply to round-trip
measurement as to one-way measurement (Section 5.1). measurement as to one-way measurement (Section 5.1).
5.3. Passive Measurement 5.3. Passive Measurement
Passive measurement use whatever data it is natural to use. For Passive measurements use whatever data it is natural to use. For
example, an IP telephony application or a networked game would use example, an IP telephony application or a networked game would use
the data that it sends. An analysis of performance of a link might the data that it sends. An analysis of performance of a link might
use all the packets that traversed the link in the measurement use all the packets that traversed the link in the measurement
interval. An analysis of performance of an Internet service interval. An analysis of performance of an Internet service
provider's network might use all the packets that traversed the provider's network might use all the packets that traversed the
network in the measurement interval. An analysis of performance of a network in the measurement interval. An analysis of performance of a
specific service from the point of view of a given site might use an specific service from the point of view of a given site might use an
appropriate filter to select only the relevant packets. In any case, appropriate filter to select only the relevant packets. In any case,
the source needs to be reported. the source needs to be reported.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
This document requires no action from the IANA. This document requires no action from the IANA.
9. Internationalization Considerations 9. Internationalization Considerations
The reported metrics, while they might occasionally be parsed by The reported metrics, while they might occasionally be parsed by
machine, are primarily meant for human consumption. As such, they machine, are primarily meant for human consumption. As such, they
MAY be reported in the language preferred by the user, using an MAY be reported in the language preferred by the user, using an
encoding suitable for the purpose, such as UTF-8. encoding suitable for the purpose, such as UTF-8.
10. Normative References 10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999. Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., and J. Perser, "Packet Reordering Metrics", RFC 4737, S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
November 2006. November 2006.
[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric",
RFC 5560, May 2009. RFC 5560, May 2009.
10.2. Informative References
[I-D.ietf-ippm-reporting-metrics]
Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
Metrics: Different Points of View",
draft-ietf-ippm-reporting-metrics-04 (work in progress),
October 2010.
Appendix A. Sample Source Code for Computing the Metrics Appendix A. Sample Source Code for Computing the Metrics
This appendix only serves for illustrative purposes. This appendix only serves for illustrative purposes.
/* /*
* reporting.c -- performance metrics reporting as in Internet Draft * reporting.c -- performance metrics reporting as in Internet Draft
* draft-ietf-ippm-reporting. * draft-ietf-ippm-reporting.
* *
* Written by Stanislav Shalunov, http://www.internet2.edu/~shalunov/ * Written by Stanislav Shalunov, http://www.internet2.edu/~shalunov/
* Bernhard Lutzmann, belu@users.sf.net * Bernhard Lutzmann, belu@users.sf.net
 End of changes. 11 change blocks. 
12 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/