draft-ietf-ippm-2679-bis-00.txt   draft-ietf-ippm-2679-bis-01.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: April 26, 2015 M. Zekauskas Expires: July 30, 2015 M. Zekauskas
Internet2 Internet2
A. Morton, Ed. A. Morton, Ed.
AT&T Labs AT&T Labs
October 23, 2014 January 26, 2015
A One-Way Delay Metric for IPPM A One-Way Delay Metric for IPPM
draft-ietf-ippm-2679-bis-00 draft-ietf-ippm-2679-bis-01
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. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 26, 2015. This Internet-Draft will expire on July 30, 2015.
Copyright Notice 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. 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
skipping to change at page 3, line 14 skipping to change at page 3, line 4
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. RFC 2679 bis
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
skipping to change at page 4, line 4 skipping to change at page 3, line 42
incorporate recent experience where appropriate (see the last incorporate recent experience where appropriate (see the last
list item of section 3.6, section 3.8, and section 5 below). list item of section 3.6, section 3.8, and section 5 below).
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. Near the end of section 2.1, update of a network example using 1. Add that RFC2330 was updated by RFC7312 in the Introduction
(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.
2. Explicit inclusion of the maximum waiting time input parameter 3. 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.
3. Addition of reference to RFC6703 in the discussion of packet 4. 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.
4. Addition of reference to the default requirement (that packets 5. 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.
5. GPS-based NTP experience replaces "to be tested" in section 3.5. 6. GPS-based NTP experience replaces "to be tested" in section 3.5.
6. Added parenthetical guidance on minimizing interval between 7. Replaced "precedence" with updated terminology (DS Field) in 3.6
and 3.8.1 (with reference).
8. 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.
7. Added text recognizing the impending deployment of transport 9. Added text recognizing the impending deployment of transport
layer encryption in section 3.6. layer encryption in section 3.6.
8. Section 3.7.2 notes that some current systems perform host time 10. Section 3.7.2 notes that some current systems perform host time
stamping on the network interface hardware. stamping on the network interface hardware.
9. "instrument" replaced by the defined term "host" in sections 11. "instrument" replaced by the defined term "host" in sections
3.7.3 and 3.8.3. 3.7.3 and 3.8.3.
10. Added reference to RFC 3432 Periodic sampling alongside Poisson 12. 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.
11. Add reference to RFC 4737 Reordering metric in the related 13. Add reference to RFC 4737 Reordering metric in the related
discussion of section 4.6, Methodologies. discussion of section 4.6, Methodologies.
12. Clarifying the conclusions on two related points on harm to 14. Formatting of Example in section 5.1 modified to match the
original (issue with conversion to XML in bis version).
15. 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
familiar outline of IPPM literature has both value and minimizes familiar outline of IPPM literature has both value and minimizes
unnecessary differences between this revised RFC and current/future unnecessary differences between this revised RFC and current/future
IPPM RFCs. IPPM RFCs.
The publication of RFC 6921 suggested an area where this memo might The publication of RFC 6921 suggested an area where this memo might
need updating. Packet transfer on Faster-Than-Light (FTL) networks need updating. Packet transfer on Faster-Than-Light (FTL) networks
could result in negative delays and packet reordering, however both could result in negative delays and packet reordering, however both
are covered as possibilities in the current text and no revisions are are covered as possibilities in the current text and no revisions are
deemed necessary (we also note that this is an April 1st RFC). deemed necessary (we also note that this is an April 1st RFC).
skipping to change at page 5, line 21 skipping to change at page 5, line 21
need updating. Packet transfer on Faster-Than-Light (FTL) networks need updating. Packet transfer on Faster-Than-Light (FTL) networks
could result in negative delays and packet reordering, however both could result in negative delays and packet reordering, however both
are covered as possibilities in the current text and no revisions are are covered as possibilities in the current text and no revisions are
deemed necessary (we also note that this is an April 1st RFC). deemed necessary (we also note that this is an April 1st RFC).
2. Introduction 2. Introduction
This memo defines a metric for one-way delay of packets across This memo defines a metric for one-way delay of packets across
Internet paths. It builds on notions introduced and discussed in the Internet paths. It builds on notions introduced and discussed in the
IPPM Framework document, [RFC2330]; the reader is assumed to be IPPM Framework document, [RFC2330]; the reader is assumed to be
familiar with that document. familiar with that document, and its recent update [RFC7312].
This memo is intended to be parallel in structure to a companion This memo is intended to be parallel in structure to a companion
document for Packet Loss ("A One-way Packet Loss Metric for IPPM") document for Packet Loss ("A One-way Packet Loss Metric for IPPM")
[RFC2680]. [RFC2680].
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].
Although [RFC2119] was written with protocols in mind, the key words Although [RFC2119] was written with protocols in mind, the key words
are used in this document for similar reasons. They are used to are used in this document for similar reasons. They are used to
ensure the results of measurements from two different implementations ensure the results of measurements from two different implementations
are comparable, and to note instances when an implementation could are comparable, and to note instances when an implementation could
perturb the network. perturb the network.
The structure of the memo is as follows: The structure of the memo is as follows:
+ A 'singleton' analytic metric, called Type-P-One-way-Delay, will be + A 'singleton' analytic metric, called Type-P-One-way-Delay, will be
introduced to measure a single observation of one-way delay. introduced to measure a single observation of one-way delay.
skipping to change at page 10, line 16 skipping to change at page 10, line 16
does not occur, then the packet will be deemed lost. does not occur, then the packet will be deemed lost.
+ The packet is standard-formed, the default criteria for all metric + The packet is standard-formed, the default criteria for all metric
definitions defined in Section 15 of [RFC2330], otherwise the packet definitions defined in Section 15 of [RFC2330], otherwise the packet
will be deemed lost. will be deemed lost.
3.6. Methodologies: 3.6. Methodologies:
As with other Type-P-* metrics, the detailed methodology will depend As with other Type-P-* metrics, the detailed methodology will depend
on the Type-P (e.g., protocol number, UDP/TCP port number, size, 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, the methodology would proceed as Generally, for a given Type-P, the methodology would proceed as
follows: follows:
+ Arrange that Src and Dst are synchronized; that is, that they have + Arrange that Src and Dst are synchronized; that is, that they have
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
skipping to change at page 15, line 50 skipping to change at page 15, line 50
interpreting applications of the metrics should also be reported (see interpreting applications of the metrics should also be reported (see
[RFC6703] for extensive discussion of reporting considerations for [RFC6703] for extensive discussion of reporting considerations for
different audiences). different audiences).
3.8.1. Type-P 3.8.1. Type-P
As noted in the Framework document [RFC2330], the value of the metric 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 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 "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 protocol (UDP or TCP), port number, size, or arrangement for special
treatment (e.g., IP precedence or RSVP) changes. The exact Type-P treatment (e.g., IP DS Field [RFC2780] or RSVP) changes. The exact
used to make the measurements MUST be accurately reported. Type-P used to make the measurements MUST be accurately reported.
3.8.2. Loss Threshold 3.8.2. Loss Threshold
In addition, the threshold (or methodology to distinguish) between a In addition, the threshold (or methodology to distinguish) between a
large finite delay and loss MUST be reported. large finite delay and loss MUST be reported.
3.8.3. Calibration Results 3.8.3. Calibration Results
+ If the systematic error can be determined, it SHOULD be removed + If the systematic error can be determined, it SHOULD be removed
from the measured values. from the measured values.
skipping to change at page 17, line 13 skipping to change at page 17, line 13
Poisson process of rate lambda, whose values fall between T0 and Tf. Poisson process of rate lambda, whose values fall between T0 and Tf.
The time interval between successive values of T will then average 1/ The time interval between successive values of T will then average 1/
lambda. lambda.
Note that Poisson sampling is only one way of defining a sample. Note that Poisson sampling is only one way of defining a sample.
Poisson has the advantage of limiting bias, but other methods of Poisson has the advantage of limiting bias, but other methods of
sampling will be appropriate for different situations. For example, sampling will be appropriate for different situations. For example,
a truncated Poisson distribution may be needed to avoid reactive a truncated Poisson distribution may be needed to avoid reactive
network state changes during intervals of inactivity, see section 4.6 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 [RFC3432] describes a method for periodic sampling with random start
times. times.
4.1. Metric Name: 4.1. Metric Name:
Type-P-One-way-Delay-Poisson-Stream Type-P-One-way-Delay-Poisson-Stream
4.2. Metric Parameters: 4.2. Metric Parameters:
+ Src, the IP address of a host + Src, the IP address of a host
skipping to change at page 20, line 43 skipping to change at page 20, line 43
treated as infinitely large. As with Type-P-One-way-Delay- treated as infinitely large. As with Type-P-One-way-Delay-
Percentile, Type-P-One-way-Delay-Median is undefined if the sample is Percentile, Type-P-One-way-Delay-Median is undefined if the sample is
empty. empty.
As noted in the Framework document, the median differs from the 50th As noted in the Framework document, the median differs from the 50th
percentile only when the sample contains an even number of values, in percentile only when the sample contains an even number of values, in
which case the mean of the two central values is used. which case the mean of the two central values is used.
Example: suppose we take a sample and the results are: Example: suppose we take a sample and the results are:
Stream2 = < <T1, 100 msec> <T2, 110 msec> <T3, undefined> <T4, 90 Stream2 = <
msec> >
<T1, 100 msec>
<T2, 110 msec>
<T3, undefined>
<T4, 90 msec>
>
Then the median would be 105 msec, the mean of 100 msec and 110 msec, Then the median would be 105 msec, the mean of 100 msec and 110 msec,
the two central values. the two central values.
5.3. Type-P-One-way-Delay-Minimum 5.3. Type-P-One-way-Delay-Minimum
Given a Type-P-One-way-Delay-Poisson-Stream, the minimum of all the Given a Type-P-One-way-Delay-Poisson-Stream, the minimum of all the
dT values in the Stream. In computing this, undefined values are dT values in the Stream. In computing this, undefined values are
treated as infinitely large. Note that this means that the minimum treated as infinitely large. Note that this means that the minimum
could thus be undefined (informally, infinite) if all the dT values could thus be undefined (informally, infinite) if all the dT values
skipping to change at page 23, line 14 skipping to change at page 23, line 18
[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, September 1999.
[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, September 1999.
[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, 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 [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. November 2002.
[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP [RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP
Performance Metrics (IPPM) Standard Advancement Testing", Performance Metrics (IPPM) Standard Advancement Testing",
BCP 176, RFC 6576, March 2012. BCP 176, RFC 6576, March 2012.
[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, August 2012.
[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Implementation Requirements and Usage Guidance for Framework for IP Performance Metrics (IPPM)", RFC 7312,
Encapsulating Security Payload (ESP) and Authentication August 2014.
Header (AH)", RFC 7321, August 2014.
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. November 2006.
[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. October 2011.
[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, December 2012.
Authors' Addresses Authors' Addresses
Guy Almes Guy Almes
Texas A&M Texas A&M
Email: galmes@tamu.edu Email: almes@acm.org
Sunil Kalidindi Sunil Kalidindi
Ixia Ixia
Email: skalidindi@ixiacom.com Email: skalidindi@ixiacom.com
Matt Zekauskas Matt Zekauskas
Internet2 Internet2
Email: matt@internet2.edu Email: matt@internet2.edu
 End of changes. 30 change blocks. 
37 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/