--- 1/draft-ietf-ippm-2680-bis-00.txt 2015-01-26 14:14:55.470825852 -0800 +++ 2/draft-ietf-ippm-2680-bis-01.txt 2015-01-26 14:14:55.510826823 -0800 @@ -1,114 +1,108 @@ Network Working Group G. Almes Internet-Draft Texas A&M Obsoletes: 2680 (if approved) S. Kalidindi Intended status: Standards Track Ixia -Expires: April 26, 2015 M. Zekauskas +Expires: July 30, 2015 M. Zekauskas Internet2 A. Morton, Ed. AT&T Labs - October 23, 2014 + January 26, 2015 A One-Way Loss Metric for IPPM - draft-ietf-ippm-2680-bis-00 + draft-ietf-ippm-2680-bis-01 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. -Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - 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 April 26, 2015. + This Internet-Draft will expire on July 30, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + 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.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2. General Issues Regarding Time . . . . . . . . . . . . . . 5 + 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: . . . . . . . . . . . . . . . . 9 - 2.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 10 + 2.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 8 + 2.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 9 2.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 10 2.8.2. Loss Threshold . . . . . . . . . . . . . . . . . . . 10 2.8.3. Calibration Results . . . . . . . . . . . . . . . . . 10 2.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3. A Definition for Samples of One-way Packet Loss . . . . . . . 11 + 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: . . . . . . . . . . . . . . . . . . . . . . 12 + 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: . . . . . . . . . . . . . . . . . . 14 + 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 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 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. + with that document, and its recent update [RFC7312]. This memo is intended to be parallel in structure to a companion document for One-way Delay ("A One-way Delay Metric for IPPM") [RFC2679]; the reader is assumed to be familiar with that document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in[RFC2119]. Although [RFC2119] was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure the @@ -312,21 +307,21 @@ multiple non-corrupt copies arrive at the destination, then the packet is counted as received. + If the packet is fragmented and if, for whatever reason, reassembly does not occur, then the packet will be deemed lost. 2.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, - precedence). + Differentiated Services (DS) Field [RFC2780])). Generally, for a given Type-P, one possible methodology would proceed as follows: + Arrange that Src and Dst have clocks that are synchronized with each other. The degree of synchronization is a parameter of the methodology, and depends on the threshold used to determine loss (see below). + At the Src host, select Src and Dst IP addresses, and form a test @@ -431,22 +426,22 @@ applications of the metrics should also be reported (see [RFC6703] for extensive discussion of reporting considerations for different audiences). 2.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 precedence or RSVP) changes. The exact Type-P - used to make the measurements MUST be accurately reported. + treatment (e.g., IP DS Field [RFC2780]) or RSVP) changes. The exact + Type-P used to make the measurements MUST be accurately reported. 2.8.2. Loss Threshold The threshold, Tmax, (or methodology to distinguish) between a large finite delay and loss MUST be reported. 2.8.3. Calibration Results The degree of synchronization between the Src and Dst clocks MUST be reported. If possible, possibility that a test packet that arrives @@ -483,21 +478,21 @@ time Tf, and an average rate lambda, then define a pseudo-random Poisson process of rate lambda, whose values fall between T0 and Tf. The time interval between successive values of T will then average 1/ lambda. Note that Poisson sampling is only one way of defining a sample. Poisson has the advantage of limiting bias, but other methods of sampling will be appropriate for different situations. For example, a truncated Poisson distribution may be needed to avoid reactive network state changes during intervals of inactivity, see section 4.6 - of [RFC7321]. Sometimes, the goal is sampling with a known bias, and + of [RFC7312]. Sometimes, the goal is sampling with a known bias, and [RFC3432] describes a method for periodic sampling with random start times. 3.1. Metric Name: Type-P-One-way-Packet-Loss-Poisson-Stream 3.2. Metric Parameters: + Src, the IP address of a host @@ -552,21 +547,21 @@ Since a pseudo-random number sequence is employed, the sequence of times, and hence the value of the sample, is not fully specified. Pseudo-random number generators of good quality will be needed to achieve the desired qualities. 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 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 [RFC7321] + 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 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 @@ -600,21 +594,21 @@ 3.7. Errors and Uncertainties: In addition to sources of errors and uncertainties associated with methods employed to measure the singleton values that make up the sample, care must be given to analyze the accuracy of the Poisson arrival process of the wire-times of the sending of the test packets. Problems with this process could be caused by several things, including problems with the pseudo-random number techniques used to generate the Poisson arrival process. The Framework document shows - how to use the Anderson-Darling test verify the accuracy of the + how to use the Anderson-Darling test to verify the accuracy of the Poisson process over small time frames. {Comment: The goal is to ensure that the test packets are sent "close enough" to a Poisson schedule, and avoid periodic behavior.} 3.8. Reporting the metric: The calibration and context for the underlying singletons MUST be reported along with the stream. (See "Reporting the metric" for Type-P-One-way-Packet-Loss.) @@ -737,58 +731,62 @@ 4. There are currently two errata with status "Verified" and "Held for document update" for [RFC2680], and it appears these minor revisions should be incorporated in RFC2680bis (see section 1 and section 2.7). A number of updates to the [RFC2680] text have been implemented in the text, to reference key IPPM RFCs that were approved after [RFC2680] (see sections 3 and 3.6, above), and to address comments on the IPPM mailing list describing current conditions and experience. - 1. Near the end of section 1.1, update of a network example using + 1. Add that RFC2330 was updated by RFC7312 in the Introduction + (section 1). + + 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. - 2. Clarification of the definition of "resolution" in section 1.2. + 3. Clarification of the definition of "resolution" in section 1.2. - 3. Explicit inclusion of the maximum waiting time input parameter in - sections 2.2, 2.4, and 3.2, reflecting recognition of this + 4. Explicit inclusion of the maximum waiting time input parameter + in sections 2.2, 2.4, and 3.2, reflecting recognition of this parameter in more recent RFCs and ITU-T Recommendation Y.1540. - 4. Addition of reference to RFC6703 in the discussion of packet life - time and application timeouts in section 2.5. + 5. Addition of reference to RFC 6703 in the discussion of packet + life time and application timeouts in section 2.5. - 5. Added parenthetical guidance on minimizing interval between + 6. Replaced "precedence" with updated terminology (DS Field) in 2.6 + and 2.8.1 (with reference). + + 7. Added parenthetical guidance on minimizing interval between timestamp placement to send time or reception time in section 2.6. Also, the text now recognizes the timestamp acquisition process and that practical systems measure both delay and loss (thus require the max waiting time parameter). - 6. Added reference to RFC 3432 Periodic sampling alongside Poisson + 8. Added reference to RFC 3432 Periodic sampling alongside Poisson sampling in section 3, and also noting that a truncated Poisson distribution may be needed with modern networks as described in - the IPPM Framework update, RFC7312. + the IPPM Framework update, [RFC7312]. - 7. Recognition that Time-slotted links described in [RFC7321] can + 9. Recognition that Time-slotted links described in [RFC7312] can greatly modify the sample characteristics, in section 3.5. - 8. Add reference to RFC 4737 Reordering metric in the related + 10. Add reference to RFC 4737 Reordering metric in the related discussion of section 3.6, Methodologies. - 9. - 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 + 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 @@ -820,57 +818,60 @@ [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. + [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For + Values In the Internet Protocol and Related Headers", BCP + 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. - [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm - Implementation Requirements and Usage Guidance for - Encapsulating Security Payload (ESP) and Authentication - Header (AH)", RFC 7321, August 2014. + [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling + Framework for IP Performance Metrics (IPPM)", RFC 7312, + August 2014. 10.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. [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: galmes@tamu.edu + Email: almes@acm.org Sunil Kalidindi Ixia Email: skalidindi@ixiacom.com Matt Zekauskas Internet2 Email: matt@internet2.edu