--- 1/draft-ietf-ippm-2679-bis-03.txt 2015-08-12 12:15:02.376183328 -0700 +++ 2/draft-ietf-ippm-2679-bis-04.txt 2015-08-12 12:15:02.428184584 -0700 @@ -1,23 +1,23 @@ Network Working Group G. Almes Internet-Draft Texas A&M Obsoletes: 2679 (if approved) S. Kalidindi Intended status: Standards Track Ixia -Expires: January 25, 2016 M. Zekauskas +Expires: February 13, 2016 M. Zekauskas Internet2 A. Morton, Ed. AT&T Labs - July 24, 2015 + August 12, 2015 A One-Way Delay Metric for IPPM - draft-ietf-ippm-2679-bis-03 + draft-ietf-ippm-2679-bis-04 Abstract This memo (RFC 2679 bis) defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2679 obsolete. Status of This Memo @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on January 25, 2016. + This Internet-Draft will expire on February 13, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -61,85 +61,86 @@ 3. A Singleton Definition for One-way Delay . . . . . . . . . . 8 3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 8 3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 10 3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 11 3.7.1. Errors or uncertainties related to Clocks . . . . . . 11 3.7.2. Errors or uncertainties related to Wire-time vs Host- - time . . . . . . . . . . . . . . . . . . . . . . . . 12 + time . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7.3. Calibration . . . . . . . . . . . . . . . . . . . . . 13 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.3. Calibration Results . . . . . . . . . . . . . . . . . 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.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 17 4.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 17 - 4.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 18 - 4.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 18 + 4.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 19 4.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 19 4.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 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.3. Type-P-One-way-Delay-Minimum . . . . . . . . . . . . . . 21 5.4. Type-P-One-way-Delay-Inverse-Percentile . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 - 9.2. Informative References . . . . . . . . . . . . . . . . . 23 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 9.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Changes from RFC 2679 Note: This section's placement currently preserves minimal differencer between this memo and RFC 2679. The RFC Editor should place this section in an appropriate place. The following text constitutes RFC 2769 bis proposed for advancement on the IETF Standards Track. This section tracks the changes from [RFC2679]. [RFC6808] provides the test plan and results supporting [RFC2679] advancement along the standards track, according to the process in [RFC6576]. The conclusions of [RFC6808] list four minor modifications: 1. Section 6.2.3 of [RFC6808] asserts that the assumption of post- processing to enforce a constant waiting time threshold is compliant, and that the text of the RFC should be revised - slightly to include this point (see the last list item of section - 3.6, below). + slightly to include this point. The applicability of post- + 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- Inverse-Percentile statistic has been ignored in both implementations, so it is a candidate for removal or deprecation 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 in [RFC6703], and this memo should be referenced in RFC2679bis to - incorporate recent experience where appropriate (see the last - list item of section 3.6, section 3.8, and section 5 below). + incorporate recent experience where appropriate. This reference + 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 - update" for [RFC2679], and it appears this minor revision and - additional text should be incorporated in RFC2679bis (see section - 5.1). + update" for [RFC2679], and this minor revision and additional + text was incorporated in RFC2679bis in section 5.1, below. A number of updates to the [RFC2679] text have been implemented in the text below, to reference key IPPM RFCs that were approved after [RFC2679], and to address comments on the IPPM mailing list describing current conditions and experience. 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 importance of one-way delay measurement. @@ -428,21 +427,23 @@ + If the packet is duplicated along the path (or paths) so that multiple non-corrupt copies arrive at the destination, then the packet is counted as received, and the first copy to arrive determines the packet's one-way delay. + If the packet is fragmented and if, for whatever reason, reassembly does not occur, then the packet will be deemed lost. + The packet is standard-formed, the default criteria for all metric 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: As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, Differentiated Services (DS) Field [RFC2780]). Generally, for a given Type-P, the methodology would proceed as follows: @@ -704,25 +705,27 @@ results. We now present four items to consider: the Type-P of test packets, the threshold of infinite delay (if any), error calibration, and the path traversed by the test packets. This list is not exhaustive; any additional information that could be useful in interpreting applications of the metrics should also be reported (see [RFC6703] for extensive discussion of reporting considerations for different audiences). 3.8.1. Type-P - As noted in the Framework document [RFC2330], the value of the metric - may depend on the type of IP packets used to make the measurement, or - "type-P". The value of Type-P-One-way-Delay could change if the - protocol (UDP or TCP), port number, size, or arrangement for special - treatment (e.g., IP DS Field [RFC2780] or RSVP) changes. The exact + As noted in the Framework document, section 13 of [RFC2330], the + value of the metric may depend on the type of IP packets used to make + the measurement, or "Type-P". The value of Type-P-One-way-Delay + could change if the protocol (UDP or TCP), port number, size, or + 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. 3.8.2. Loss Threshold In addition, the threshold (or methodology to distinguish) between a large finite delay and loss MUST be reported. 3.8.3. Calibration Results + If the systematic error can be determined, it SHOULD be removed @@ -1032,21 +1036,22 @@ 8. Acknowledgements For [RFC2679], special thanks are due to Vern Paxson of Lawrence Berkeley Labs for his helpful comments on issues of clock uncertainty and statistics. Thanks also to Garry Couch, Will Leland, Andy Scherrer, Sean Shapira, and Roland Wittig for several useful suggestions. For RFC 2679 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini 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.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -1087,20 +1092,32 @@ Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March 2012, . [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, . 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, + . + [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, . [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, .