draft-ietf-ippm-2680-bis-02.txt   draft-ietf-ippm-2680-bis-03.txt 
Network Working Group G. Almes Network Working Group G. Almes
Internet-Draft Texas A&M Internet-Draft Texas A&M
Obsoletes: 2680 (if approved) S. Kalidindi Obsoletes: 2680 (if approved) S. Kalidindi
Intended status: Standards Track Ixia Intended status: Standards Track Ixia
Expires: December 22, 2015 M. Zekauskas Expires: January 25, 2016 M. Zekauskas
Internet2 Internet2
A. Morton, Ed. A. Morton, Ed.
AT&T Labs AT&T Labs
June 20, 2015 July 24, 2015
A One-Way Loss Metric for IPPM A One-Way Loss Metric for IPPM
draft-ietf-ippm-2680-bis-02 draft-ietf-ippm-2680-bis-03
Abstract Abstract
This memo (RFC 2680 bis) defines a metric for one-way loss of packets This memo (RFC 2680 bis) defines a metric for one-way loss of packets
across Internet paths. It builds on notions introduced and discussed across Internet paths. It builds on notions introduced and discussed
in the IPPM Framework document, RFC 2330; the reader is assumed to be in the IPPM Framework document, RFC 2330; the reader is assumed to be
familiar with that document. This memo makes RFC 2680 obsolete. familiar with that document. This memo makes RFC 2680 obsolete.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 December 22, 2015. This Internet-Draft will expire on January 25, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
2.8.3. Calibration Results . . . . . . . . . . . . . . . . . 10 2.8.3. Calibration Results . . . . . . . . . . . . . . . . . 10
2.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 10 2.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 10
3. A Definition for Samples of One-way Packet Loss . . . . . . . 10 3. A Definition for Samples of One-way Packet Loss . . . . . . . 10
3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 11 3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 11
3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 13 3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 13
3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 13 3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 13
3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 13 3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 14
4. Some Statistics Definitions for One-way Packet Loss . . . . . 14 4. Some Statistics Definitions for One-way Packet Loss . . . . . 14
4.1. Type-P-One-way-Packet Loss-Ratio . . . . . . . . . . . . 14 4.1. Type-P-One-way-Packet Loss-Ratio . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7. RFC 2680 bis . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Changes from RFC 2680 . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This memo defines a metric for one-way packet loss across Internet This memo defines a metric for one-way packet loss across Internet
paths. It builds on notions introduced and discussed in the IPPM paths. It builds on notions introduced and discussed in the IPPM
Framework document, [RFC2330]; the reader is assumed to be familiar Framework document, [RFC2330]; the reader is assumed to be familiar
with that document, and its recent update [RFC7312]. with that document, and its recent update [RFC7312].
This memo is intended to be parallel in structure to a companion This memo is intended to be parallel in structure to a companion
skipping to change at page 4, line 31 skipping to change at page 4, line 31
performance difference between the two paths which may traverse performance difference between the two paths which may traverse
different Internet service providers, and even radically different different Internet service providers, and even radically different
types of networks (for example, research versus commodity networks, types of networks (for example, research versus commodity networks,
or networks with asymmetric link capacities, or wireless vs. wireline or networks with asymmetric link capacities, or wireless vs. wireline
access). access).
+ Even when the two paths are symmetric, they may have radically + Even when the two paths are symmetric, they may have radically
different performance characteristics due to asymmetric queueing. different performance characteristics due to asymmetric queueing.
+ Performance of an application may depend mostly on the performance + Performance of an application may depend mostly on the performance
in one direction. For example, a TCP-based communication may in one direction. For example, a TCP-based communication will
experience reduced throughput if congestion occurs in one direction experience reduced throughput if congestion occurs in one direction
of its communication. Trouble shooting may be simplified if the of its communication. Trouble shooting may be simplified if the
congested direction of TCP transmission can be identified. congested direction of TCP transmission can be identified.
+ In quality-of-service (QoS) enabled networks, provisioning in one + In quality-of-service (QoS) enabled networks, provisioning in one
direction may be radically different than provisioning in the reverse direction may be radically different than provisioning in the reverse
direction, and thus the QoS guarantees differ. Measuring the paths direction, and thus the QoS guarantees differ. Measuring the paths
independently allows the verification of both guarantees. independently allows the verification of both guarantees.
It is outside the scope of this document to say precisely how loss It is outside the scope of this document to say precisely how loss
skipping to change at page 12, line 40 skipping to change at page 12, line 40
Since a pseudo-random number sequence is employed, the sequence of Since a pseudo-random number sequence is employed, the sequence of
times, and hence the value of the sample, is not fully specified. times, and hence the value of the sample, is not fully specified.
Pseudo-random number generators of good quality will be needed to Pseudo-random number generators of good quality will be needed to
achieve the desired qualities. achieve the desired qualities.
The sample is defined in terms of a Poisson process both to avoid the The sample is defined in terms of a Poisson process both to avoid the
effects of self-synchronization and also capture a sample that is effects of self-synchronization and also capture a sample that is
statistically as unbiased as possible. The Poisson process is used statistically as unbiased as possible. The Poisson process is used
to schedule the loss measurements. The test packets will generally to schedule the loss measurements. The test packets will generally
not arrive at Dst according to a Poisson distribution, since they are not arrive at Dst according to a Poisson distribution, since they are
influenced by the network. Time-slotted links described in [RFC7312] influenced by the network. Time-slotted links described in section
can greatly modify the sample characteristics. 3.4 [RFC7312] can greatly modify the sample characteristics. The
main concern is that un-biased packet streams with randomized inter-
packet time intervals will be converted to some new distribution
after encountering a time-slotted links, possibly with strong
periodic characteristics instead.
{Comment: there is, of course, no claim that real Internet traffic {Comment: there is, of course, no claim that real Internet traffic
arrives according to a Poisson arrival process. arrives according to a Poisson arrival process.
It is important to note that, in contrast to this metric, loss ratios It is important to note that, in contrast to this metric, loss ratios
observed by transport connections do not reflect unbiased samples. observed by transport connections do not reflect unbiased samples.
For example, TCP transmissions both (1) occur in bursts, which can For example, TCP transmissions both (1) occur in bursts, which can
induce loss due to the burst volume that would not otherwise have induce loss due to the burst volume that would not otherwise have
been observed, and (2) adapt their transmission rate in an attempt to been observed, and (2) adapt their transmission rate in an attempt to
minimize the loss ratio observed by the connection.} minimize the loss ratio observed by the connection.}
skipping to change at page 16, line 5 skipping to change at page 16, line 9
For [RFC2680], thanks are due to Matt Mathis for encouraging this For [RFC2680], thanks are due to Matt Mathis for encouraging this
work and for calling attention on so many occasions to the work and for calling attention on so many occasions to the
significance of packet loss. Thanks are due also to Vern Paxson for significance of packet loss. Thanks are due also to Vern Paxson for
his valuable comments on early drafts, and to Garry Couch and Will his valuable comments on early drafts, and to Garry Couch and Will
Leland for several useful suggestions. Leland for several useful suggestions.
For RFC 2680 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini For RFC 2680 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini
Elkins, and Barry Constantine for sharing their measurement Elkins, and Barry Constantine for sharing their measurement
experience as part of their careful reviews. experience as part of their careful reviews.
7. RFC 2680 bis 7. Changes from RFC 2680
Note: This section's placement currently preserves minimal
differencer between this memo and RFC 2680. The RFC Editor should
place this section in an appropriate place.
The text above constitutes RFC 2680 bis proposed for advancement on The text above constitutes RFC 2680 bis proposed for advancement on
the IETF Standards Track. the IETF Standards Track.
[RFC7290] provides the test plan and results supporting [RFC2680] [RFC7290] provides the test plan and results supporting [RFC2680]
advancement along the standards track, according to the process in advancement along the standards track, according to the process in
[RFC6576]. The conclusions of [RFC7290] list four minor [RFC6576]. The conclusions of [RFC7290] list four minor
modifications for inclusion: modifications for inclusion:
1. Section 6.2.3 of [RFC7290] asserts that the assumption of post- 1. Section 6.2.3 of [RFC7290] asserts that the assumption of post-
skipping to change at page 16, line 41 skipping to change at page 16, line 49
4. There are currently two errata with status "Verified" and "Held 4. There are currently two errata with status "Verified" and "Held
for document update" for [RFC2680], and it appears these minor for document update" for [RFC2680], and it appears these minor
revisions should be incorporated in RFC2680bis (see section 1 and revisions should be incorporated in RFC2680bis (see section 1 and
section 2.7). section 2.7).
A number of updates to the [RFC2680] text have been implemented in A number of updates to the [RFC2680] text have been implemented in
the text, to reference key IPPM RFCs that were approved after the text, to reference key IPPM RFCs that were approved after
[RFC2680] (see sections 3 and 3.6, above), and to address comments on [RFC2680] (see sections 3 and 3.6, above), and to address comments on
the IPPM mailing list describing current conditions and experience. the IPPM mailing list describing current conditions and experience.
1. Add that RFC2330 was updated by RFC7312 in the Introduction 1. Near the end of section 1.1, update of a network example using
(section 1). ATM and clarification of TCP's affect on queue occupation and
importance of one-way delay measurement.
2. Near the end of section 1.1, update of a network example using
ATM and clarification of TCP's affect on queue occupation and
importance of one-way delay measurement.
3. Clarification of the definition of "resolution" in section 1.2. 2. Clarification of the definition of "resolution" in section 1.2.
4. Explicit inclusion of the maximum waiting time input parameter 3. Explicit inclusion of the maximum waiting time input parameter in
in sections 2.2, 2.4, and 3.2, reflecting recognition of this sections 2.2, 2.4, and 3.2, reflecting recognition of this
parameter in more recent RFCs and ITU-T Recommendation Y.1540. parameter in more recent RFCs and ITU-T Recommendation Y.1540.
5. Addition of reference to RFC 6703 in the discussion of packet 4. Addition of reference to RFC 6703 in the discussion of packet
life time and application timeouts in section 2.5. life time and application timeouts in section 2.5.
6. Replaced "precedence" with updated terminology (DS Field) in 2.6 5. Replaced "precedence" with updated terminology (DS Field) in 2.6
and 2.8.1 (with reference). and 2.8.1 (with reference).
7. Added parenthetical guidance on minimizing interval between 6. Added parenthetical guidance on minimizing interval between
timestamp placement to send time or reception time in section timestamp placement to send time or reception time in section
2.6. Also, the text now recognizes the timestamp acquisition 2.6. Also, the text now recognizes the timestamp acquisition
process and that practical systems measure both delay and loss process and that practical systems measure both delay and loss
(thus require the max waiting time parameter). (thus require the max waiting time parameter).
8. Added reference to RFC 3432 Periodic sampling alongside Poisson 7. Added reference to RFC 3432 Periodic sampling alongside Poisson
sampling in section 3, and also noting that a truncated Poisson sampling in section 3, and also noting that a truncated Poisson
distribution may be needed with modern networks as described in distribution may be needed with modern networks as described in
the IPPM Framework update, [RFC7312]. the IPPM Framework update, [RFC7312].
9. Recognition that Time-slotted links described in [RFC7312] can 8. Recognition that Time-slotted links described in [RFC7312] can
greatly modify the sample characteristics, in section 3.5. greatly modify the sample characteristics, in section 3.5.
10. Add reference to RFC 4737 Reordering metric in the related 9. Add reference to RFC 4737 Reordering metric in the related
discussion of section 3.6, Methodologies. discussion of section 3.6, Methodologies.
Section 5.4.4 of [RFC6390] suggests a common template for performance Section 5.4.4 of [RFC6390] suggests a common template for performance
metrics partially derived from previous IPPM and BMWG RFCs, but also metrics partially derived from previous IPPM and BMWG RFCs, but also
contains some new items. All of the [RFC6390] Normative points are contains some new items. All of the [RFC6390] Normative points are
covered, but not quite in the same section names or orientation. covered, but not quite in the same section names or orientation.
Several of the Informative points are covered. Maintaining the Several of the Informative points are covered. Maintaining the
familiar outline of IPPM literature has value and minimizes familiar outline of IPPM literature has value and minimizes
unnecessary differences between this revised RFC and current/future unnecessary differences between this revised RFC and current/future
IPPM RFCs. IPPM RFCs.
skipping to change at page 17, line 42 skipping to change at page 18, line 4
Several of the Informative points are covered. Maintaining the Several of the Informative points are covered. Maintaining the
familiar outline of IPPM literature has value and minimizes familiar outline of IPPM literature has value and minimizes
unnecessary differences between this revised RFC and current/future unnecessary differences between this revised RFC and current/future
IPPM RFCs. IPPM RFCs.
8. IANA Considerations 8. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
1981. DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May "Framework for IP Performance Metrics", RFC 2330,
1998. DOI 10.17487/RFC2330, May 1998,
<http://www.rfc-editor.org/info/rfc2330>.
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999. Connectivity", RFC 2678, DOI 10.17487/RFC2678, September
1999, <http://www.rfc-editor.org/info/rfc2678>.
[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, DOI 10.17487/RFC2679,
September 1999, <http://www.rfc-editor.org/info/rfc2679>.
[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,
DOI 10.17487/RFC2680, September 1999,
<http://www.rfc-editor.org/info/rfc2680>.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP Values In the Internet Protocol and Related Headers",
37, RFC 2780, March 2000. BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
<http://www.rfc-editor.org/info/rfc2780>.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
November 2002. DOI 10.17487/RFC3432, November 2002,
<http://www.rfc-editor.org/info/rfc3432>.
[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP [RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz,
Performance Metrics (IPPM) Standard Advancement Testing", "IP Performance Metrics (IPPM) Standard Advancement
BCP 176, RFC 6576, March 2012. Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March
2012, <http://www.rfc-editor.org/info/rfc6576>.
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Framework for IP Performance Metrics (IPPM)", RFC 7312, Framework for IP Performance Metrics (IPPM)", RFC 7312,
August 2014. DOI 10.17487/RFC7312, August 2014,
<http://www.rfc-editor.org/info/rfc7312>.
9.2. Informative References 9.2. Informative References
[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. DOI 10.17487/RFC4737, November 2006,
<http://www.rfc-editor.org/info/rfc4737>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
October 2011. DOI 10.17487/RFC6390, October 2011,
<http://www.rfc-editor.org/info/rfc6390>.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View", IP Network Performance Metrics: Different Points of View",
RFC 6703, August 2012. RFC 6703, DOI 10.17487/RFC6703, August 2012,
<http://www.rfc-editor.org/info/rfc6703>.
[RFC7290] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test [RFC7290] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test
Plan and Results for Advancing RFC 2680 on the Standards Plan and Results for Advancing RFC 2680 on the Standards
Track", RFC 7290, July 2014. Track", RFC 7290, DOI 10.17487/RFC7290, July 2014,
<http://www.rfc-editor.org/info/rfc7290>.
Authors' Addresses Authors' Addresses
Guy Almes Guy Almes
Texas A&M Texas A&M
Email: almes@acm.org Email: almes@acm.org
Sunil Kalidindi Sunil Kalidindi
Ixia Ixia
 End of changes. 34 change blocks. 
59 lines changed or deleted 79 lines changed or added

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