draft-ietf-ippm-2679-bis-03.txt   draft-ietf-ippm-2679-bis-04.txt 
Network Working Group G. Almes Network Working Group G. Almes
Internet-Draft Texas A&M Internet-Draft Texas A&M
Obsoletes: 2679 (if approved) S. Kalidindi Obsoletes: 2679 (if approved) S. Kalidindi
Intended status: Standards Track Ixia Intended status: Standards Track Ixia
Expires: January 25, 2016 M. Zekauskas Expires: February 13, 2016 M. Zekauskas
Internet2 Internet2
A. Morton, Ed. A. Morton, Ed.
AT&T Labs AT&T Labs
July 24, 2015 August 12, 2015
A One-Way Delay Metric for IPPM A One-Way Delay Metric for IPPM
draft-ietf-ippm-2679-bis-03 draft-ietf-ippm-2679-bis-04
Abstract Abstract
This memo (RFC 2679 bis) defines a metric for one-way delay of This memo (RFC 2679 bis) defines a metric for one-way delay of
packets across Internet paths. It builds on notions introduced and packets across Internet paths. It builds on notions introduced and
discussed in the IPPM Framework document, RFC 2330; the reader is discussed in the IPPM Framework document, RFC 2330; the reader is
assumed to be familiar with that document. This memo makes RFC 2679 assumed to be familiar with that document. This memo makes RFC 2679
obsolete. obsolete.
Status of This Memo Status of This Memo
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 25, 2016. This Internet-Draft will expire on February 13, 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 26 skipping to change at page 2, line 26
3. A Singleton Definition for One-way Delay . . . . . . . . . . 8 3. A Singleton Definition for One-way Delay . . . . . . . . . . 8
3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 8 3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 8
3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 10 3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 10
3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 11 3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 11
3.7.1. Errors or uncertainties related to Clocks . . . . . . 11 3.7.1. Errors or uncertainties related to Clocks . . . . . . 11
3.7.2. Errors or uncertainties related to Wire-time vs Host- 3.7.2. Errors or uncertainties related to Wire-time vs Host-
time . . . . . . . . . . . . . . . . . . . . . . . . 12 time . . . . . . . . . . . . . . . . . . . . . . . . 13
3.7.3. Calibration . . . . . . . . . . . . . . . . . . . . . 13 3.7.3. Calibration . . . . . . . . . . . . . . . . . . . . . 13
3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 15 3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 15
3.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 15 3.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 16
3.8.2. Loss Threshold . . . . . . . . . . . . . . . . . . . 16 3.8.2. Loss Threshold . . . . . . . . . . . . . . . . . . . 16
3.8.3. Calibration Results . . . . . . . . . . . . . . . . . 16 3.8.3. Calibration Results . . . . . . . . . . . . . . . . . 16
3.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 16 3.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 16
4. A Definition for Samples of One-way Delay . . . . . . . . . . 16 4. A Definition for Samples of One-way Delay . . . . . . . . . . 17
4.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 17 4.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 17
4.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 18
4.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 18 4.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 19
4.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 19 4.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 19
4.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 19 4.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 19
5. Some Statistics Definitions for One-way Delay . . . . . . . . 19 5. Some Statistics Definitions for One-way Delay . . . . . . . . 19
5.1. Type-P-One-way-Delay-Percentile . . . . . . . . . . . . . 19 5.1. Type-P-One-way-Delay-Percentile . . . . . . . . . . . . . 20
5.2. Type-P-One-way-Delay-Median . . . . . . . . . . . . . . . 20 5.2. Type-P-One-way-Delay-Median . . . . . . . . . . . . . . . 20
5.3. Type-P-One-way-Delay-Minimum . . . . . . . . . . . . . . 21 5.3. Type-P-One-way-Delay-Minimum . . . . . . . . . . . . . . 21
5.4. Type-P-One-way-Delay-Inverse-Percentile . . . . . . . . . 21 5.4. Type-P-One-way-Delay-Inverse-Percentile . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Changes from RFC 2679 1. Changes from RFC 2679
Note: This section's placement currently preserves minimal Note: This section's placement currently preserves minimal
differencer between this memo and RFC 2679. The RFC Editor should differencer between this memo and RFC 2679. The RFC Editor should
place this section in an appropriate place. place this section in an appropriate place.
The following text constitutes RFC 2769 bis proposed for advancement The following text constitutes RFC 2769 bis proposed for advancement
on the IETF Standards Track. This section tracks the changes from on the IETF Standards Track. This section tracks the changes from
[RFC2679]. [RFC2679].
[RFC6808] provides the test plan and results supporting [RFC2679] [RFC6808] provides the test plan and results supporting [RFC2679]
advancement along the standards track, according to the process in advancement along the standards track, according to the process in
[RFC6576]. The conclusions of [RFC6808] list four minor [RFC6576]. The conclusions of [RFC6808] list four minor
modifications: modifications:
1. Section 6.2.3 of [RFC6808] asserts that the assumption of post- 1. Section 6.2.3 of [RFC6808] asserts that the assumption of post-
processing to enforce a constant waiting time threshold is processing to enforce a constant waiting time threshold is
compliant, and that the text of the RFC should be revised compliant, and that the text of the RFC should be revised
slightly to include this point (see the last list item of section slightly to include this point. The applicability of post-
3.6, below). processing was added in the last list item of section 3.6, below.
2. Section 6.5 of [RFC6808] indicates that Type-P-One-way-Delay- 2. Section 6.5 of [RFC6808] indicates that Type-P-One-way-Delay-
Inverse-Percentile statistic has been ignored in both Inverse-Percentile statistic has been ignored in both
implementations, so it is a candidate for removal or deprecation implementations, so it is a candidate for removal or deprecation
in RFC2679bis (this small discrepancy does not affect candidacy in RFC2679bis (this small discrepancy does not affect candidacy
for advancement) (see section 5.4, below). for advancement). This statistic was deprecated in section 5.4,
below.
3. The IETF has reached consensus on guidance for reporting metrics 3. The IETF has reached consensus on guidance for reporting metrics
in [RFC6703], and this memo should be referenced in RFC2679bis to in [RFC6703], and this memo should be referenced in RFC2679bis to
incorporate recent experience where appropriate (see the last incorporate recent experience where appropriate. This reference
list item of section 3.6, section 3.8, and section 5 below). was added in the last list item of section 3.6, section 3.8, and
in section 5 below.
4. There is currently one erratum with status "Held for document 4. There is currently one erratum with status "Held for document
update" for [RFC2679], and it appears this minor revision and update" for [RFC2679], and this minor revision and additional
additional text should be incorporated in RFC2679bis (see section text was incorporated in RFC2679bis in section 5.1, below.
5.1).
A number of updates to the [RFC2679] text have been implemented in A number of updates to the [RFC2679] text have been implemented in
the text below, to reference key IPPM RFCs that were approved after the text below, to reference key IPPM RFCs that were approved after
[RFC2679], and to address comments on the IPPM mailing list [RFC2679], and to address comments on the IPPM mailing list
describing current conditions and experience. describing current conditions and experience.
1. Near the end of section 2.1, update of a network example using 1. Near the end of section 2.1, update of a network example using
ATM and clarification of TCP's affect on queue occupation and ATM and clarification of TCP's affect on queue occupation and
importance of one-way delay measurement. importance of one-way delay measurement.
skipping to change at page 10, line 10 skipping to change at page 10, line 10
+ If the packet is duplicated along the path (or paths) so that + If the packet is duplicated along the path (or paths) so that
multiple non-corrupt copies arrive at the destination, then the multiple non-corrupt copies arrive at the destination, then the
packet is counted as received, and the first copy to arrive packet is counted as received, and the first copy to arrive
determines the packet's one-way delay. determines the packet's one-way delay.
+ If the packet is fragmented and if, for whatever reason, reassembly + If the packet is fragmented and if, for whatever reason, reassembly
does not occur, then the packet will be deemed lost. does not occur, then the packet will be deemed lost.
+ The packet is standard-formed, the default criteria for all metric + The packet is standard-formed, the default criteria for all metric
definitions defined in Section 15 of [RFC2330], otherwise the packet definitions defined in Section 15 of [RFC2330], otherwise the packet
will be deemed lost. will be deemed lost. Note: At this time, the definition of standard-
formed packets only applies to IPv4, but also see
[I-D.morton-ippm-2330-stdform-typep].
3.6. Methodologies: 3.6. Methodologies:
As with other Type-P-* metrics, the detailed methodology will depend As with other Type-P-* metrics, the detailed methodology will depend
on the Type-P (e.g., protocol number, UDP/TCP port number, size, on the Type-P (e.g., protocol number, UDP/TCP port number, size,
Differentiated Services (DS) Field [RFC2780]). Differentiated Services (DS) Field [RFC2780]).
Generally, for a given Type-P, the methodology would proceed as Generally, for a given Type-P, the methodology would proceed as
follows: follows:
skipping to change at page 15, line 46 skipping to change at page 16, line 7
results. We now present four items to consider: the Type-P of test results. We now present four items to consider: the Type-P of test
packets, the threshold of infinite delay (if any), error calibration, packets, the threshold of infinite delay (if any), error calibration,
and the path traversed by the test packets. This list is not and the path traversed by the test packets. This list is not
exhaustive; any additional information that could be useful in exhaustive; any additional information that could be useful in
interpreting applications of the metrics should also be reported (see interpreting applications of the metrics should also be reported (see
[RFC6703] for extensive discussion of reporting considerations for [RFC6703] for extensive discussion of reporting considerations for
different audiences). different audiences).
3.8.1. Type-P 3.8.1. Type-P
As noted in the Framework document [RFC2330], the value of the metric As noted in the Framework document, section 13 of [RFC2330], the
may depend on the type of IP packets used to make the measurement, or value of the metric may depend on the type of IP packets used to make
"type-P". The value of Type-P-One-way-Delay could change if the the measurement, or "Type-P". The value of Type-P-One-way-Delay
protocol (UDP or TCP), port number, size, or arrangement for special could change if the protocol (UDP or TCP), port number, size, or
treatment (e.g., IP DS Field [RFC2780] or RSVP) changes. The exact arrangement for special treatment (e.g., IP DS Field [RFC2780], ECN
[RFC3168], or RSVP) changes. Additional packet distinctions included
in future extensions of the Type-P definition will apply. The exact
Type-P used to make the measurements MUST be accurately reported. Type-P used to make the measurements MUST be accurately reported.
3.8.2. Loss Threshold 3.8.2. Loss Threshold
In addition, the threshold (or methodology to distinguish) between a In addition, the threshold (or methodology to distinguish) between a
large finite delay and loss MUST be reported. large finite delay and loss MUST be reported.
3.8.3. Calibration Results 3.8.3. Calibration Results
+ If the systematic error can be determined, it SHOULD be removed + If the systematic error can be determined, it SHOULD be removed
skipping to change at page 22, line 38 skipping to change at page 22, line 49
8. Acknowledgements 8. Acknowledgements
For [RFC2679], special thanks are due to Vern Paxson of Lawrence For [RFC2679], special thanks are due to Vern Paxson of Lawrence
Berkeley Labs for his helpful comments on issues of clock uncertainty Berkeley Labs for his helpful comments on issues of clock uncertainty
and statistics. Thanks also to Garry Couch, Will Leland, Andy and statistics. Thanks also to Garry Couch, Will Leland, Andy
Scherrer, Sean Shapira, and Roland Wittig for several useful Scherrer, Sean Shapira, and Roland Wittig for several useful
suggestions. suggestions.
For RFC 2679 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini For RFC 2679 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. Brian Carpenter and
Scott Bradner provided useful feedback at IETF Last Call.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <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
skipping to change at page 23, line 45 skipping to change at page 24, line 12
Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March
2012, <http://www.rfc-editor.org/info/rfc6576>. 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,
DOI 10.17487/RFC7312, August 2014, DOI 10.17487/RFC7312, August 2014,
<http://www.rfc-editor.org/info/rfc7312>. <http://www.rfc-editor.org/info/rfc7312>.
9.2. Informative References 9.2. Informative References
[I-D.morton-ippm-2330-stdform-typep]
Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V.
Hegde, "Updates for IPPM's Active Metric Framework:
Packets of Type-P and Standard-Formed Packets", draft-
morton-ippm-2330-stdform-typep-00 (work in progress),
August 2015.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[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,
DOI 10.17487/RFC4737, November 2006, DOI 10.17487/RFC4737, November 2006,
<http://www.rfc-editor.org/info/rfc4737>. <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,
DOI 10.17487/RFC6390, October 2011, DOI 10.17487/RFC6390, October 2011,
<http://www.rfc-editor.org/info/rfc6390>. <http://www.rfc-editor.org/info/rfc6390>.
 End of changes. 19 change blocks. 
28 lines changed or deleted 46 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/