--- 1/draft-ietf-ippm-2680-bis-01.txt 2015-06-22 06:14:59.875563542 -0700 +++ 2/draft-ietf-ippm-2680-bis-02.txt 2015-06-22 06:14:59.919564633 -0700 @@ -1,66 +1,66 @@ Network Working Group G. Almes Internet-Draft Texas A&M Obsoletes: 2680 (if approved) S. Kalidindi Intended status: Standards Track Ixia -Expires: July 30, 2015 M. Zekauskas +Expires: December 22, 2015 M. Zekauskas Internet2 A. Morton, Ed. AT&T Labs - January 26, 2015 + June 20, 2015 A One-Way Loss Metric for IPPM - draft-ietf-ippm-2680-bis-01 + draft-ietf-ippm-2680-bis-02 Abstract This memo (RFC 2680 bis) defines a metric for one-way loss 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. + familiar with that document. This memo makes RFC 2680 obsolete. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 July 30, 2015. + This Internet-Draft will expire on December 22, 2015. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. General Issues Regarding Time . . . . . . . . . . . . . . 4 2. A Singleton Definition for One-way Packet Loss . . . . . . . 6 2.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 6 2.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 7 2.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 8 @@ -72,29 +72,28 @@ 3. A Definition for Samples of One-way Packet Loss . . . . . . . 10 3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 11 3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 12 3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 13 3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 13 3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 13 4. Some Statistics Definitions for One-way Packet Loss . . . . . 14 - 4.1. Type-P-One-way-Packet Loss-Average . . . . . . . . . . . 14 + 4.1. Type-P-One-way-Packet Loss-Ratio . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. RFC 2680 bis . . . . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 10.2. Informative References . . . . . . . . . . . . . . . . . 19 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction This memo defines a metric for one-way packet loss across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, [RFC2330]; the reader is assumed to be familiar with that document, and its recent update [RFC7312]. This memo is intended to be parallel in structure to a companion @@ -457,23 +456,24 @@ includes the record route (or loose-source route) option in the IP header, and the path is short enough, and all routers* on the path support record (or loose-source) route, then the path will be precisely recorded. This is impractical because the route must be short enough, many routers do not support (or are not configured for) record route, and use of this feature would often artificially worsen the performance observed by removing the packet from common-case processing. However, partial information is still valuable context. For example, if a host can choose between two links* (and hence two separate routes from Src to Dst), then the initial link used is - valuable context. {Comment: For example, with Merit's NetNow setup, a - Src on one NAP can reach a Dst on another NAP by either of several - different backbone networks.} + valuable context. {Comment: Backbone path selection services come and + go. A historical example was Merit's NetNow setup, where a Src on + one NAP can reach a Dst on another NAP by either of several different + backbone networks.} 3. A Definition for Samples of One-way Packet Loss Given the singleton metric Type-P-One-way-Packet-Loss, we now define one particular sample of such singletons. The idea of the sample is to select a particular binding of the parameters Src, Dst, and Type- P, then define a sample of values of parameter T. The means for defining the values of T is to select a beginning time T0, a final time Tf, and an average rate lambda, then define a pseudo-random Poisson process of rate lambda, whose values fall between T0 and Tf. @@ -553,26 +553,26 @@ effects of self-synchronization and also capture a sample that is statistically as unbiased as possible. The Poisson process is used to schedule the loss measurements. The test packets will generally not arrive at Dst according to a Poisson distribution, since they are influenced by the network. Time-slotted links described in [RFC7312] can greatly modify the sample characteristics. {Comment: there is, of course, no claim that real Internet traffic arrives according to a Poisson arrival process. - It is important to note that, in contrast to this metric, loss rates + It is important to note that, in contrast to this metric, loss ratios observed by transport connections do not reflect unbiased samples. For example, TCP transmissions both (1) occur in bursts, which can induce loss due to the burst volume that would not otherwise have been observed, and (2) adapt their transmission rate in an attempt to - minimize the loss rate observed by the connection.} + minimize the loss ratio observed by the connection.} All the singleton Type-P-One-way-Packet-Loss metrics in the sequence will have the same values of Src, Dst, and Type-P. Note also that, given one sample that runs from T0 to Tf, and given new time values T0' and Tf' such that T0 <= T0' <= Tf' <= Tf, the subsequence of the given sample whose time values fall between T0' and Tf' are also a valid Type-P-One-way-Packet-Loss-Poisson-Stream sample. 3.6. Methodologies: @@ -613,57 +613,58 @@ Type-P-One-way-Packet-Loss.) 4. Some Statistics Definitions for One-way Packet Loss Given the sample metric Type-P-One-way-Packet-Loss-Poisson-Stream, we now offer several statistics of that sample. These statistics are offered mostly to be illustrative of what could be done. See [RFC6703] for additional discussion of statistics that are relevant to different audiences. -4.1. Type-P-One-way-Packet Loss-Average +4.1. Type-P-One-way-Packet Loss-Ratio Given a Type-P-One-way-Packet-Loss-Poisson-Stream, the average of all - the L values in the Stream. In addition, the Type-P-One-way-Packet- - Loss-Average is undefined if the sample is empty. + the L values in the Stream is the ratio of losses to total packets in + the stream. In addition, the Type-P-One-way-Packet-Loss-Ratio is + undefined if the sample is empty. Example: suppose we take a sample and the results are: Stream1 = < > - Then the average would be 0.2. + Then the average of loss results would be 0.2, the loss ratio. Note that, since healthy Internet paths should be operating at loss - rates below 1% (particularly if high delay-bandwidth products are to + ratios below 1% (particularly if high delay-bandwidth products are to be sustained), the sample sizes needed might be larger than one would like. Thus, for example, if one wants to discriminate between various fractions of 1% over one-minute periods, then several hundred samples per minute might be needed. This would result in larger values of lambda than one would ordinarily want. Note that although the loss threshold should be set such that any errors in loss are not significant, if the possibility that a packet which arrived is counted as lost due to resource exhaustion is - significant compared to the loss rate of interest, Type-P-One-way- - Packet-Loss-Average will be meaningless. + significant compared to the loss ratio of interest, Type-P-One-way- + Packet-Loss-Ratio will be meaningless. 5. Security Considerations Conducting Internet measurements raises both security and privacy concerns. This memo does not specify an implementation of the metrics, so it does not directly affect the security of the Internet nor of applications which run on the Internet. However, implementations of these metrics must be mindful of security and privacy concerns. @@ -675,39 +676,41 @@ additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement, and in extreme cases cause congestion and denial of service. The measurements themselves could be harmed by routers giving measurement traffic a different priority than "normal" traffic, or by an attacker injecting artificial measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements will not reflect actual user traffic. If an attacker injects artificial traffic that is accepted as legitimate, the loss - rate will be artificially lowered. Therefore, the measurement + ratio will be artificially lowered. Therefore, the measurement methodologies SHOULD include appropriate techniques to reduce the probability measurement traffic can be distinguished from "normal" traffic. 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. 6. Acknowledgements - Thanks are due to Matt Mathis for encouraging this work and for - calling attention on so many occasions to the significance of packet - loss. + For [RFC2680], thanks are due to Matt Mathis for encouraging this + work and for calling attention on so many occasions to the + significance of packet loss. Thanks are due also to Vern Paxson for + his valuable comments on early drafts, and to Garry Couch and Will + Leland for several useful suggestions. - Thanks are due also to Vern Paxson for his valuable comments on early - drafts, and to Garry Couch and Will Leland for several useful - suggestions. + For RFC 2680 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini + Elkins, and Barry Constantine for sharing their measurement + experience as part of their careful reviews. 7. RFC 2680 bis The text above constitutes RFC 2680 bis proposed for advancement on the IETF Standards Track. [RFC7290] provides the test plan and results supporting [RFC2680] advancement along the standards track, according to the process in [RFC6576]. The conclusions of [RFC7290] list four minor modifications for inclusion: @@ -780,42 +783,27 @@ 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 value and minimizes unnecessary differences between this revised RFC and current/future IPPM RFCs. 8. IANA Considerations This memo makes no requests of IANA. -9. Acknowledgements - - For [RFC2680], 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 2680 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini - Elkins, and Barry Constantine for sharing their measurement - experience as part of their careful reviews. - -10. References +9. References -10.1. Normative References +9.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9, RFC 2026, October 1996. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. @@ -830,38 +818,38 @@ 37, RFC 2780, March 2000. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. [RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP Performance Metrics (IPPM) Standard Advancement Testing", BCP 176, RFC 6576, March 2012. - [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting - IP Network Performance Metrics: Different Points of View", - RFC 6703, August 2012. - [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, August 2014. -10.2. Informative References +9.2. Informative References [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006. [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011. + [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting + IP Network Performance Metrics: Different Points of View", + RFC 6703, August 2012. + [RFC7290] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test Plan and Results for Advancing RFC 2680 on the Standards Track", RFC 7290, July 2014. Authors' Addresses Guy Almes Texas A&M Email: almes@acm.org