draft-ietf-ippm-2679-bis-02.txt   draft-ietf-ippm-2679-bis-03.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: December 22, 2015 M. Zekauskas Expires: January 25, 2016 M. Zekauskas
Internet2 Internet2
A. Morton, Ed. A. Morton, Ed.
AT&T Labs AT&T Labs
June 20, 2015 July 24, 2015
A One-Way Delay Metric for IPPM A One-Way Delay Metric for IPPM
draft-ietf-ippm-2679-bis-02 draft-ietf-ippm-2679-bis-03
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 December 22, 2015. This Internet-Draft will expire on January 25, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. RFC 2679 bis . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Changes from RFC 2679 . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. General Issues Regarding Time . . . . . . . . . . . . . . 7 2.2. General Issues Regarding Time . . . . . . . . . . . . . . 7
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
skipping to change at page 3, line 5 skipping to change at page 3, line 5
5.1. Type-P-One-way-Delay-Percentile . . . . . . . . . . . . . 19 5.1. Type-P-One-way-Delay-Percentile . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. RFC 2679 bis 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 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:
skipping to change at page 3, line 45 skipping to change at page 3, line 49
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 it appears this minor revision and
additional text should be incorporated in RFC2679bis (see section additional text should be incorporated in RFC2679bis (see section
5.1). 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. Add that RFC2330 was updated by RFC7312 in the Introduction 1. Near the end of section 2.1, update of a network example using
(section 2).
2. 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.
3. Explicit inclusion of the maximum waiting time input parameter 2. Explicit inclusion of the maximum waiting time input parameter
in section 3.2 and 4.2, reflecting recognition of this parameter in section 3.2 and 4.2, reflecting recognition of this parameter
in more recent RFCs and ITU-T Recommendation Y.1540. in more recent RFCs and ITU-T Recommendation Y.1540.
4. Addition of reference to RFC6703 in the discussion of packet 3. Addition of reference to RFC6703 in the discussion of packet
life time and application timeouts in section 3.5. life time and application timeouts in section 3.5.
5. Addition of reference to the default requirement (that packets 4. Addition of reference to the default requirement (that packets
be standard-formed) from RFC2330 as a new list item in section be standard-formed) from RFC2330 as a new list item in section
3.5. 3.5.
6. GPS-based NTP experience replaces "to be tested" in section 3.5. 5. GPS-based NTP experience replaces "to be tested" in section 3.5.
7. Replaced "precedence" with updated terminology (DS Field) in 3.6 6. Replaced "precedence" with updated terminology (DS Field) in 3.6
and 3.8.1 (with reference). and 3.8.1 (with reference).
8. Added parenthetical guidance on minimizing interval between 7. Added parenthetical guidance on minimizing interval between
timestamp placement to send time in section 3.6. timestamp placement to send time in section 3.6.
9. Added text recognizing the impending deployment of transport 8. Added text recognizing the impending deployment of transport
layer encryption in section 3.6. layer encryption in section 3.6.
10. Section 3.7.2 notes that some current systems perform host time 9. Section 3.7.2 notes that some current systems perform host time
stamping on the network interface hardware. stamping on the network interface hardware.
11. "instrument" replaced by the defined term "host" in sections 10. "instrument" replaced by the defined term "host" in sections
3.7.3 and 3.8.3. 3.7.3 and 3.8.3.
12. Added reference to RFC 3432 Periodic sampling alongside Poisson 11. Added reference to RFC 3432 Periodic sampling alongside Poisson
sampling in section 4, and also noting that a truncated Poisson sampling in section 4, and also noting that a truncated Poisson
distribution may be needed with modern networks as described in distribution may be needed with modern networks as described in
the IPPM Framework update, RFC7312. the IPPM Framework update, RFC7312.
13. Add reference to RFC 4737 Reordering metric in the related 12. Add reference to RFC 4737 Reordering metric in the related
discussion of section 4.6, Methodologies. discussion of section 4.6, Methodologies.
14. Formatting of Example in section 5.1 modified to match the 13. Formatting of Example in section 5.1 modified to match the
original (issue with conversion to XML in bis version). original (issue with conversion to XML in bis version).
15. Clarifying the conclusions on two related points on harm to 14. Clarifying the conclusions on two related points on harm to
measurements (recognition of measurement traffic for unexpected measurements (recognition of measurement traffic for unexpected
priority treatment and attacker traffic which emulates priority treatment and attacker traffic which emulates
measurement) in section 6, Security Considerations. measurement) in section 6, Security Considerations.
Section 5.4.4 of [RFC6390] suggests a common template for performance Section 5.4.4 of [RFC6390] suggests a common template for performance
metrics partially derived from previous IPPM and BMWG RFCs, but also metrics partially derived from previous IPPM and BMWG RFCs, but also
contains some new items. All of the [RFC6390] Normative points are contains some new items. All of the [RFC6390] Normative points are
covered, but not quite in the same section names or orientation. covered, but not quite in the same section names or orientation.
Several of the Informative points are covered. Maintaining the Several of the Informative points are covered. Maintaining the
skipping to change at page 6, line 48 skipping to change at page 6, line 48
performance difference between the two paths which may traverse performance difference between the two paths which may traverse
different Internet service providers, and even radically different different Internet service providers, and even radically different
types of networks (for example, research versus commodity networks, types of networks (for example, research versus commodity networks,
or networks with asymmetric link capacities, or wireless vs. wireline or networks with asymmetric link capacities, or wireless vs. wireline
access). access).
+ Even when the two paths are symmetric, they may have radically + Even when the two paths are symmetric, they may have radically
different performance characteristics due to asymmetric queueing. different performance characteristics due to asymmetric queueing.
+ Performance of an application may depend mostly on the performance + Performance of an application may depend mostly on the performance
in one direction. For example, a TCP-based communication may in one direction. For example, a TCP-based communication will
experience reduced throughput if congestion occurs in one direction experience reduced throughput if congestion occurs in one direction
of its communication. Trouble shooting may be simplified if the of its communication. Trouble shooting may be simplified if the
congested direction of TCP transmission can be identified. congested direction of TCP transmission can be identified.
+ In quality-of-service (QoS) enabled networks, provisioning in one + In quality-of-service (QoS) enabled networks, provisioning in one
direction may be radically different than provisioning in the reverse direction may be radically different than provisioning in the reverse
direction, and thus the QoS guarantees differ. Measuring the paths direction, and thus the QoS guarantees differ. Measuring the paths
independently allows the verification of both guarantees. independently allows the verification of both guarantees.
It is outside the scope of this document to say precisely how delay It is outside the scope of this document to say precisely how delay
skipping to change at page 10, line 32 skipping to change at page 10, line 32
clocks that are very closely synchronized with each other and each clocks that are very closely synchronized with each other and each
fairly close to the actual time. fairly close to the actual time.
+ At the Src host, select Src and Dst IP addresses, and form a test + 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 of Type-P with these addresses. Any 'padding' portion of the
packet needed only to make the test packet a given size should be packet needed only to make the test packet a given size should be
filled with randomized bits to avoid a situation in which the filled with randomized bits to avoid a situation in which the
measured delay is lower than it would otherwise be due to compression measured delay is lower than it would otherwise be due to compression
techniques along the path. Note that use of transport layer techniques along the path. Note that use of transport layer
encryption will counteract the deployment of network-based analysis encryption will counteract the deployment of network-based analysis
and may reduce the adoption of payload optimizations like and may reduce the adoption of network-based payload optimizations
compression. like compression.
+ At the Dst host, arrange to receive the packet. + At the Dst host, arrange to receive the packet.
+ At the Src host, place a timestamp in the prepared Type-P packet, + At the Src host, place a timestamp in the prepared Type-P packet,
and send it towards Dst (ideally minimizing time before sending). and send it towards Dst (ideally minimizing time before sending).
+ If the packet arrives within a reasonable period of time, take a + If the packet arrives within a reasonable period of time, take a
timestamp as soon as possible upon the receipt of the packet. By timestamp as soon as possible upon the receipt of the packet. By
subtracting the two timestamps, an estimate of one-way delay can be subtracting the two timestamps, an estimate of one-way delay can be
computed. Error analysis of a given implementation of the method computed. Error analysis of a given implementation of the method
skipping to change at page 22, line 44 skipping to change at page 22, line 44
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.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
1981. DOI 10.17487/RFC0791, September 1981,
<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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May "Framework for IP Performance Metrics", RFC 2330,
1998. DOI 10.17487/RFC2330, May 1998,
<http://www.rfc-editor.org/info/rfc2330>.
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999. Connectivity", RFC 2678, DOI 10.17487/RFC2678, September
1999, <http://www.rfc-editor.org/info/rfc2678>.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679,
September 1999, <http://www.rfc-editor.org/info/rfc2679>.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999. Packet Loss Metric for IPPM", RFC 2680,
DOI 10.17487/RFC2680, September 1999,
<http://www.rfc-editor.org/info/rfc2680>.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP Values In the Internet Protocol and Related Headers",
37, RFC 2780, March 2000. BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
<http://www.rfc-editor.org/info/rfc2780>.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
November 2002. DOI 10.17487/RFC3432, November 2002,
<http://www.rfc-editor.org/info/rfc3432>.
[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP [RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz,
Performance Metrics (IPPM) Standard Advancement Testing", "IP Performance Metrics (IPPM) Standard Advancement
BCP 176, RFC 6576, March 2012. Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March
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,
August 2014. DOI 10.17487/RFC7312, August 2014,
<http://www.rfc-editor.org/info/rfc7312>.
9.2. Informative References 9.2. Informative References
[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,
November 2006. DOI 10.17487/RFC4737, November 2006,
<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,
October 2011. DOI 10.17487/RFC6390, October 2011,
<http://www.rfc-editor.org/info/rfc6390>.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View", IP Network Performance Metrics: Different Points of View",
RFC 6703, August 2012. RFC 6703, DOI 10.17487/RFC6703, August 2012,
<http://www.rfc-editor.org/info/rfc6703>.
[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test [RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test
Plan and Results Supporting Advancement of RFC 2679 on the Plan and Results Supporting Advancement of RFC 2679 on the
Standards Track", RFC 6808, December 2012. Standards Track", RFC 6808, DOI 10.17487/RFC6808, December
2012, <http://www.rfc-editor.org/info/rfc6808>.
Authors' Addresses Authors' Addresses
Guy Almes Guy Almes
Texas A&M Texas A&M
Email: almes@acm.org Email: almes@acm.org
Sunil Kalidindi Sunil Kalidindi
Ixia Ixia
Email: skalidindi@ixiacom.com Email: skalidindi@ixiacom.com
 End of changes. 38 change blocks. 
46 lines changed or deleted 64 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/