--- 1/draft-ietf-ippm-2679-bis-04.txt 2015-08-20 12:15:03.189026359 -0700 +++ 2/draft-ietf-ippm-2679-bis-05.txt 2015-08-20 12:15:03.241027621 -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: February 13, 2016 M. Zekauskas +Expires: February 21, 2016 M. Zekauskas Internet2 A. Morton, Ed. AT&T Labs - August 12, 2015 + August 20, 2015 A One-Way Delay Metric for IPPM - draft-ietf-ippm-2679-bis-04 + draft-ietf-ippm-2679-bis-05 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 February 13, 2016. + This Internet-Draft will expire on February 21, 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,54 +61,54 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 + time . . . . . . . . . . . . . . . . . . . . . . . . 12 3.7.3. Calibration . . . . . . . . . . . . . . . . . . . . . 13 3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 15 - 3.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 16 + 3.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . 17 + 4. A Definition for Samples of One-way Delay . . . . . . . . . . 16 4.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 17 4.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 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 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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. + differences between this memo and RFC 2679. The RFC Editor should + place this section in an appropriate place, and remove this note. 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: @@ -156,45 +156,46 @@ 3.5. 5. GPS-based NTP experience replaces "to be tested" in section 3.5. 6. Replaced "precedence" with updated terminology (DS Field) in 3.6 and 3.8.1 (with reference). 7. Added parenthetical guidance on minimizing interval between timestamp placement to send time in section 3.6. - 8. Added text recognizing the impending deployment of transport - layer encryption in section 3.6. - - 9. Section 3.7.2 notes that some current systems perform host time + 8. Section 3.7.2 notes that some current systems perform host time stamping on the network interface hardware. - 10. "instrument" replaced by the defined term "host" in sections + 9. "instrument" replaced by the defined term "host" in sections 3.7.3 and 3.8.3. - 11. Added reference to RFC 3432 Periodic sampling alongside Poisson + 10. Added reference to RFC 3432 Periodic sampling alongside Poisson sampling in section 4, and also noting that a truncated Poisson distribution may be needed with modern networks as described in the IPPM Framework update, RFC7312. - 12. Add reference to RFC 4737 Reordering metric in the related + 11. Add reference to RFC 4737 Reordering metric in the related discussion of section 4.6, Methodologies. - 13. Formatting of Example in section 5.1 modified to match the + 12. Formatting of Example in section 5.1 modified to match the original (issue with conversion to XML in bis version). - 14. Clarifying the conclusions on two related points on harm to + 13. Clarifying the conclusions on two related points on harm to measurements (recognition of measurement traffic for unexpected priority treatment and attacker traffic which emulates measurement) in section 6, Security Considerations. + 14. Expanded and updated the material on Privacy, and added cautions + on use of measurements for reconnaissance in section 6, Security + Considerations. + Section 5.4.4 of [RFC6390] suggests a common template for performance metrics partially derived from previous IPPM and BMWG RFCs, but also contains some new items. All of the [RFC6390] Normative points are covered, but not quite in the same section names or orientation. Several of the Informative points are covered. Maintaining the familiar outline of IPPM literature has both value and minimizes unnecessary differences between this revised RFC and current/future IPPM RFCs. The publication of RFC 6921 suggested an area where this memo might @@ -408,21 +409,21 @@ of some GPS-based NTP servers and a conservatively designed and deployed set of other NTP servers should yield good results. This was tested in [RFC6808], where a GPS measurement system's results compared well with a GPS-based NTP synchronized system for the same intercontinental path. + A given methodology will have to include a way to determine whether a delay value is infinite or whether it is merely very large (and the packet is yet to arrive at Dst). As noted by Mahdavi and Paxson [RFC2678], simple upper bounds (such as the 255 seconds theoretical - upper bound on the lifetimes of IP packets [RFC0791]) could be used, + upper bound on the lifetimes of IP packets [RFC0791]) could be used; but good engineering, including an understanding of packet lifetimes, will be needed in practice. {Comment: Note that, for many applications of these metrics, the harm in treating a large delay as infinite might be zero or very small. A TCP data packet, for example, that arrives only after several multiples of the RTT may as well have been lost. See section 4.1.1 of [RFC6703] for examination of unusual packet delays and application performance estimation.} + If the packet is duplicated along the path (or paths) so that multiple non-corrupt copies arrive at the destination, then the @@ -448,25 +449,23 @@ follows: + Arrange that Src and Dst are synchronized; that is, that they have clocks that are very closely synchronized with each other and each fairly close to the actual time. + At the Src host, select Src and Dst IP addresses, and form a test packet of Type-P with these addresses. Any 'padding' portion of the packet needed only to make the test packet a given size should be filled with randomized bits to avoid a situation in which the - measured delay is lower than it would otherwise be due to compression - techniques along the path. Note that use of transport layer - encryption will counteract the deployment of network-based analysis - and may reduce the adoption of network-based payload optimizations - like compression. + measured delay is lower than it would otherwise be, due to + compression techniques along the path. Also see section 3.1.2 of + [RFC7312]. + At the Dst host, arrange to receive the packet. + At the Src host, place a timestamp in the prepared Type-P packet, and send it towards Dst (ideally minimizing time before sending). + If the packet arrives within a reasonable period of time, take a timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of one-way delay can be computed. Error analysis of a given implementation of the method @@ -580,21 +579,21 @@ just prior to sending the test packet and when Dst grabs a timestamp just after having received the test packet, and we refer to these two points as "host times". We note that some systems perform host time stamping on the network interface hardware, in an attempt to minimize the difference from wire times. To the extent that the difference between wire time and host time is accurately known, this knowledge can be used to correct for host time - measurements and the corrected value more accurately estimates the + measurements, and the corrected value more accurately estimates the desired (wire time) metric. To the extent, however, that the difference between wire time and host time is uncertain, this uncertainty must be accounted for in an analysis of a given measurement method. We denote by Hsource an upper bound on the uncertainty in the difference between wire time and host time on the Src host, and similarly define Hdest for the Dst host. We then note that these problems introduce a total uncertainty of Hsource+Hdest. This estimate of total wire-vs-host uncertainty should be included in the error/uncertainty analysis of any @@ -710,23 +709,24 @@ [RFC6703] for extensive discussion of reporting considerations for different audiences). 3.8.1. Type-P 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. + [RFC3168], or RSVP) changes. Additional packet distinctions + identified 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 from the measured values. @@ -1018,23 +1017,37 @@ measurement methodologies SHOULD include appropriate techniques to reduce the probability measurement traffic can be distinguished from "normal" traffic. If an attacker injects packets emulating traffic that are accepted as legitimate, the loss ratio or other measured values could be corrupted. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks. - The privacy concerns of network measurement are limited by the active - measurements described in this memo. Unlike passive measurements, - there can be no release of existing user data. + When considering privacy of those involved in measurement or those + whose traffic is measured, the sensitive information available to + potential observers is greatly reduced when using active techniques + which are within this scope of work. Passive observations of user + traffic for measurement purposes raise many privacy issues. We refer + the reader to the privacy considerations described in the Large Scale + Measurement of Broadband Performance (LMAP) Framework + [I-D.ietf-lmap-framework], which covers active and passive + techniques. + + Collecting measurements or using measurement results for + reconnaissance to assist in subsequent system attacks is quite + common. Access to measurement results, or control of the measurement + systems to perform reconnaissance should be guarded against. See + Section 7 of [I-D.ietf-lmap-framework] (security considerations of + the LMAP Framework) for system requirements that help to avoid + measurement system compromise. 7. IANA Considerations This memo makes no requests of IANA. 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 @@ -1092,20 +1105,26 @@ 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.ietf-lmap-framework] + Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., + Aitken, P., and A. Akhter, "A framework for Large-Scale + Measurement of Broadband Performance (LMAP)", draft-ietf- + lmap-framework-14 (work in progress), April 2015. + [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,