draft-ietf-ippm-2680-bis-00.txt   draft-ietf-ippm-2680-bis-01.txt 
Network Working Group G. Almes Network Working Group G. Almes
Internet-Draft Texas A&M Internet-Draft Texas A&M
Obsoletes: 2680 (if approved) S. Kalidindi Obsoletes: 2680 (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 Loss Metric for IPPM A One-Way Loss Metric for IPPM
draft-ietf-ippm-2680-bis-00 draft-ietf-ippm-2680-bis-01
Abstract Abstract
This memo (RFC 2680 bis) defines a metric for one-way loss of packets This memo (RFC 2680 bis) defines a metric for one-way loss of packets
across Internet paths. It builds on notions introduced and discussed across Internet paths. It builds on notions introduced and discussed
in the IPPM Framework document, RFC 2330; the reader is assumed to be in the IPPM Framework document, RFC 2330; the reader is assumed to be
familiar with that document. 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. General Issues Regarding Time . . . . . . . . . . . . . . 5 1.2. General Issues Regarding Time . . . . . . . . . . . . . . 4
2. A Singleton Definition for One-way Packet Loss . . . . . . . 6 2. A Singleton Definition for One-way Packet Loss . . . . . . . 6
2.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 6 2.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 6
2.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 7 2.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 7
2.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 9 2.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 8
2.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 10 2.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 9
2.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 10 2.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 10
2.8.2. Loss Threshold . . . . . . . . . . . . . . . . . . . 10 2.8.2. Loss Threshold . . . . . . . . . . . . . . . . . . . 10
2.8.3. Calibration Results . . . . . . . . . . . . . . . . . 10 2.8.3. Calibration Results . . . . . . . . . . . . . . . . . 10
2.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 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.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 11 3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 11
3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 13 3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 13
3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 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. 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-Average . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7. RFC 2680 bis . . . . . . . . . . . . . . . . . . . . . . . . 16 7. RFC 2680 bis . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This memo defines a metric for one-way packet loss across Internet This memo defines a metric for one-way packet loss across Internet
paths. It builds on notions introduced and discussed in the IPPM paths. It builds on notions introduced and discussed in the IPPM
Framework document, [RFC2330]; the reader is assumed to be familiar 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 This memo is intended to be parallel in structure to a companion
document for One-way Delay ("A One-way Delay Metric for IPPM") document for One-way Delay ("A One-way Delay Metric for IPPM")
[RFC2679]; the reader is assumed to be familiar with that document. [RFC2679]; the reader is assumed to be familiar with that document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in[RFC2119]. Although document are to be interpreted as described in[RFC2119]. Although
[RFC2119] was written with protocols in mind, the key words are used [RFC2119] was written with protocols in mind, the key words are used
in this document for similar reasons. They are used to ensure the in this document for similar reasons. They are used to ensure the
skipping to change at page 7, line 44 skipping to change at page 7, line 34
multiple non-corrupt copies arrive at the destination, then the multiple non-corrupt copies arrive at the destination, then the
packet is counted as received. packet is counted as received.
+ If the packet is fragmented and if, for whatever reason, reassembly + If the packet is fragmented and if, for whatever reason, reassembly
does not occur, then the packet will be deemed lost. does not occur, then the packet will be deemed lost.
2.6. Methodologies: 2.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, one possible methodology would proceed Generally, for a given Type-P, one possible methodology would proceed
as follows: as follows:
+ Arrange that Src and Dst have clocks that are synchronized with + Arrange that Src and Dst have clocks that are synchronized with
each other. The degree of synchronization is a parameter of the each other. The degree of synchronization is a parameter of the
methodology, and depends on the threshold used to determine loss (see methodology, and depends on the threshold used to determine loss (see
below). below).
+ 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
skipping to change at page 10, line 23 skipping to change at page 10, line 11
applications of the metrics should also be reported (see [RFC6703] applications of the metrics should also be reported (see [RFC6703]
for extensive discussion of reporting considerations for different for extensive discussion of reporting considerations for different
audiences). audiences).
2.8.1. Type-P 2.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.
2.8.2. Loss Threshold 2.8.2. Loss Threshold
The threshold, Tmax, (or methodology to distinguish) between a large The threshold, Tmax, (or methodology to distinguish) between a large
finite delay and loss MUST be reported. finite delay and loss MUST be reported.
2.8.3. Calibration Results 2.8.3. Calibration Results
The degree of synchronization between the Src and Dst clocks MUST be The degree of synchronization between the Src and Dst clocks MUST be
reported. If possible, possibility that a test packet that arrives reported. If possible, possibility that a test packet that arrives
skipping to change at page 11, line 26 skipping to change at page 11, line 14
time Tf, and an average rate lambda, then define a pseudo-random time Tf, and an average rate lambda, then define a pseudo-random
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.
3.1. Metric Name: 3.1. Metric Name:
Type-P-One-way-Packet-Loss-Poisson-Stream Type-P-One-way-Packet-Loss-Poisson-Stream
3.2. Metric Parameters: 3.2. Metric Parameters:
+ Src, the IP address of a host + Src, the IP address of a host
skipping to change at page 13, line 4 skipping to change at page 12, line 40
Since a pseudo-random number sequence is employed, the sequence of Since a pseudo-random number sequence is employed, the sequence of
times, and hence the value of the sample, is not fully specified. times, and hence the value of the sample, is not fully specified.
Pseudo-random number generators of good quality will be needed to Pseudo-random number generators of good quality will be needed to
achieve the desired qualities. achieve the desired qualities.
The sample is defined in terms of a Poisson process both to avoid the 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 effects of self-synchronization and also capture a sample that is
statistically as unbiased as possible. The Poisson process is used statistically as unbiased as possible. The Poisson process is used
to schedule the loss measurements. The test packets will generally to schedule the loss measurements. The test packets will generally
not arrive at Dst according to a Poisson distribution, since they are 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. can greatly modify the sample characteristics.
{Comment: there is, of course, no claim that real Internet traffic {Comment: there is, of course, no claim that real Internet traffic
arrives according to a Poisson arrival process. 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 rates
observed by transport connections do not reflect unbiased samples. observed by transport connections do not reflect unbiased samples.
For example, TCP transmissions both (1) occur in bursts, which can For example, TCP transmissions both (1) occur in bursts, which can
induce loss due to the burst volume that would not otherwise have induce loss due to the burst volume that would not otherwise have
been observed, and (2) adapt their transmission rate in an attempt to been observed, and (2) adapt their transmission rate in an attempt to
skipping to change at page 14, line 4 skipping to change at page 13, line 39
3.7. Errors and Uncertainties: 3.7. Errors and Uncertainties:
In addition to sources of errors and uncertainties associated with In addition to sources of errors and uncertainties associated with
methods employed to measure the singleton values that make up the methods employed to measure the singleton values that make up the
sample, care must be given to analyze the accuracy of the Poisson 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. arrival process of the wire-times of the sending of the test packets.
Problems with this process could be caused by several things, Problems with this process could be caused by several things,
including problems with the pseudo-random number techniques used to including problems with the pseudo-random number techniques used to
generate the Poisson arrival process. The Framework document shows 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 Poisson process over small time frames. {Comment: The goal is to
ensure that the test packets are sent "close enough" to a Poisson ensure that the test packets are sent "close enough" to a Poisson
schedule, and avoid periodic behavior.} schedule, and avoid periodic behavior.}
3.8. Reporting the metric: 3.8. Reporting the metric:
The calibration and context for the underlying singletons MUST be The calibration and context for the underlying singletons MUST be
reported along with the stream. (See "Reporting the metric" for reported along with the stream. (See "Reporting the metric" for
Type-P-One-way-Packet-Loss.) Type-P-One-way-Packet-Loss.)
skipping to change at page 16, line 45 skipping to change at page 16, line 41
4. There are currently two errata with status "Verified" and "Held 4. There are currently two errata with status "Verified" and "Held
for document update" for [RFC2680], and it appears these minor for document update" for [RFC2680], and it appears these minor
revisions should be incorporated in RFC2680bis (see section 1 and revisions should be incorporated in RFC2680bis (see section 1 and
section 2.7). section 2.7).
A number of updates to the [RFC2680] text have been implemented in A number of updates to the [RFC2680] text have been implemented in
the text, to reference key IPPM RFCs that were approved after the text, to reference key IPPM RFCs that were approved after
[RFC2680] (see sections 3 and 3.6, above), and to address comments on [RFC2680] (see sections 3 and 3.6, above), and to address comments on
the IPPM mailing list describing current conditions and experience. 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
ATM and clarification of TCP's affect on queue occupation and (section 1).
importance of one-way delay measurement.
2. Clarification of the definition of "resolution" in section 1.2. 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.
3. Explicit inclusion of the maximum waiting time input parameter in 3. Clarification of the definition of "resolution" in section 1.2.
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 4. Explicit inclusion of the maximum waiting time input parameter
time and application timeouts in section 2.5. in sections 2.2, 2.4, and 3.2, reflecting recognition of this
parameter in more recent RFCs and ITU-T Recommendation Y.1540.
5. Added parenthetical guidance on minimizing interval between 5. Addition of reference to RFC 6703 in the discussion of packet
timestamp placement to send time or reception time in section life time and application timeouts in section 2.5.
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 6. Replaced "precedence" with updated terminology (DS Field) in 2.6
sampling in section 3, and also noting that a truncated Poisson and 2.8.1 (with reference).
distribution may be needed with modern networks as described in
the IPPM Framework update, RFC7312.
7. Recognition that Time-slotted links described in [RFC7321] can 7. Added parenthetical guidance on minimizing interval between
greatly modify the sample characteristics, in section 3.5. 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).
8. Add reference to RFC 4737 Reordering metric in the related 8. Added reference to RFC 3432 Periodic sampling alongside Poisson
discussion of section 3.6, Methodologies. 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].
9. 9. Recognition that Time-slotted links described in [RFC7312] can
greatly modify the sample characteristics, in section 3.5.
10. Add reference to RFC 4737 Reordering metric in the related
discussion of section 3.6, Methodologies.
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 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.
8. IANA Considerations 8. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
9. Acknowledgements 9. Acknowledgements
For [RFC2680], special thanks are due to Vern Paxson of Lawrence For [RFC2680], special thanks are due to Vern Paxson of Lawrence
skipping to change at page 18, line 35 skipping to change at page 18, line 31
[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.
10.2. Informative References 10.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.
[RFC7290] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test [RFC7290] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test
Plan and Results for Advancing RFC 2680 on the Standards Plan and Results for Advancing RFC 2680 on the Standards
Track", RFC 7290, July 2014. Track", RFC 7290, July 2014.
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. 
54 lines changed or deleted 55 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/