draft-ietf-ippm-rt-loss-05.txt   rfc6673.txt 
Network Working Group A. Morton Internet Engineering Task Force (IETF) A. Morton
Internet-Draft AT&T Labs Request for Comments: 6673 AT&T Labs
Intended status: Standards Track May 8, 2012 Category: Standards Track August 2012
Expires: November 9, 2012 ISSN: 2070-1721
Round-trip Packet Loss Metrics Round-Trip Packet Loss Metrics
draft-ietf-ippm-rt-loss-05
Abstract Abstract
Many user applications (and the transport protocols that make them Many user applications (and the transport protocols that make them
possible) require two-way communications. To assess this capability, possible) require two-way communications. To assess this capability,
and to achieve test system simplicity, round-trip loss measurements and to achieve test system simplicity, round-trip loss measurements
are frequently conducted in practice. The Two-Way Active Measurement are frequently conducted in practice. The Two-Way Active Measurement
Protocol specified in RFC 5357 establishes a round-trip loss Protocol specified in RFC 5357 establishes a round-trip loss
measurement capability for the Internet. However, there is currently measurement capability for the Internet. However, there is currently
no metric specified according to the RFC 2330 framework. no round-trip packet loss metric specified according to the RFC 2330
framework.
This memo adds round-trip loss to the set of IP Performance Metrics This memo adds round-trip loss to the set of IP Performance Metrics
(IPPM). (IPPM).
Requirements Language Status of This Memo
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 This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 9, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6673.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 19 skipping to change at page 3, line 7
(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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation .................................................4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language ......................................5
3. Common Specifications for Round-trip Metrics . . . . . . . . . 4 2. Scope ...........................................................5
3.1. Name: Type-P-* . . . . . . . . . . . . . . . . . . . . . . 4 3. Common Specifications for Round-Trip Metrics ....................5
3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 5 3.1. Name: Type-P-* .............................................5
3.3. Metric Definition . . . . . . . . . . . . . . . . . . . . 5 3.2. Metric Parameters ..........................................5
3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Metric Definition ..........................................6
4. A Singleton Round-trip Loss Metric . . . . . . . . . . . . . . 6 3.4. Metric Units ...............................................6
4.1. Name: Type-P-Round-trip-Loss . . . . . . . . . . . . . . . 6 4. A Singleton Round-Trip Loss Metric ..............................7
4.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 6 4.1. Name: Type-P-Round-trip-Loss ...............................7
4.3. Definition and Metric Units . . . . . . . . . . . . . . . 6 4.2. Metric Parameters ..........................................7
4.4. Discussion and other details . . . . . . . . . . . . . . . 7 4.3. Definition and Metric Units ................................7
5. A Sample Round-trip Loss Metric . . . . . . . . . . . . . . . 7 4.4. Discussion and Other Details ...............................8
5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream . . . . . . . 8 5. A Sample Round-Trip Loss Metric .................................9
5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 8 5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream ...............9
5.3. Definition and Metric Units . . . . . . . . . . . . . . . 8 5.2. Metric Parameters ..........................................9
5.4. Discussion and other details . . . . . . . . . . . . . . . 8 5.3. Definition and Metric Units ................................9
6. Round-trip Loss Statistic . . . . . . . . . . . . . . . . . . 9 5.4. Discussion and Other Details ..............................10
6.1. Type-P-Round-trip-Loss-<Sample>-Ratio . . . . . . . . . . 9 6. Round-Trip Loss Statistic ......................................10
7. Round-trip Testing and One-way Reporting . . . . . . . . . . . 9 6.1. Type-P-Round-trip-Loss-<Sample>-Ratio .....................10
8. Measurement Considerations and Calibration . . . . . . . . . . 10 7. Round-Trip Testing and One-Way Reporting .......................11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Measurement Considerations and Calibration .....................11
9.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 11 9. Security Considerations ........................................12
9.2. User Data Confidentiality . . . . . . . . . . . . . . . . 11 9.1. Denial-of-Service Attacks .................................12
9.3. Interference with the metrics . . . . . . . . . . . . . . 11 9.2. User Data Confidentiality .................................12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9.3. Interference with the Metrics .............................12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations ...........................................13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements ..............................................13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 12. References ....................................................13
12.2. Informative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References .....................................13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.2. Informative References ...................................14
1. Introduction 1. Introduction
This memo defines a metric to quantify an IP network's ability to This memo defines a metric to quantify an IP network's ability to
transfer packets in both directions from one host to another host. transfer packets in both directions from one host to another host.
Two-way communication is almost always needed, thus failure to Two-way communication is almost always needed; thus, failure to
transfer a packet in either direction constitutes a round-trip packet transfer a packet in either direction constitutes a round-trip packet
loss. loss.
This memo defines a metric for round-trip packet loss on Internet This memo defines a metric for round-trip packet loss on Internet
paths. It builds on the notions and conventions introduced in the IP paths. It builds on the notions and conventions introduced in the IP
Performance Metrics (IPPM) framework [RFC2330]. Also, the Performance Metrics (IPPM) framework [RFC2330]. Also, the
specifications of the One-way Packet Loss Metric for IPPM [RFC2680] specifications of the one-way packet loss metric for IPPM [RFC2680]
and the Round-trip Delay Metric for IPPM [RFC2681] are frequently and the round-trip delay metric for IPPM [RFC2681] are frequently
referenced and modified to match the round-trip circumstances referenced and modified to match the round-trip circumstances
addressed here. However, this memo assumes that the reader is addressed here. However, this memo assumes that the reader is
familiar with the references, and does not repeat material as was familiar with the references; thus, it does not repeat material as
done in [RFC2681]. was done in [RFC2681].
This memo uses the terms "two-way" and "round-trip" synonymously. This memo uses the terms "two-way" and "round-trip" synonymously.
1.1. Motivation 1.1. Motivation
Many user applications and the transport protocols that make them Many user applications and the transport protocols that make them
possible require two-way communications. For example, the TCP SYN->, possible require two-way communications. For example, the TCP SYN->,
<-SYN-ACK, ACK-> three-way handshake attempted billions of times each <-SYN-ACK, ACK-> three-way handshake attempted billions of times each
day cannot be completed without two-way connectivity in a near- day cannot be completed without two-way connectivity in a near-
simultaneous time interval. Thus, measurements of Internet round- simultaneous time interval. Thus, measurements of Internet round-
trip packet loss performance provide a basis to infer application trip packet loss performance provide a basis to infer application
performance more easily. performance more easily.
Measurement system designers have also recognized advantages of Measurement system designers have also recognized advantages of
system simplicity when one host simply echoes or reflects test system simplicity when one host simply echoes or reflects test
packets to the sender. Round-trip packet loss measurements are packets to the sender. Round-trip packet loss measurements are
frequently conducted and reported in practice. The ubiquitous "ping" frequently conducted and reported in practice. The ubiquitous "ping"
tools allow the measurement of round-trip packet loss and delay, but tools allow the measurement of round-trip packet loss and delay but
usually require ICMP Echo-Request/Reply support, and ICMP packets may usually require ICMP Echo-Request/Reply support, and ICMP packets may
encounter exceptional treatment on the measurement path (see Section encounter exceptional treatment on the measurement path (see
2.6 of [RFC2681]). The Two-Way Active Measurement Protocol (TWAMP) Section 2.6 of [RFC2681]). The Two-Way Active Measurement Protocol
specified in [RFC5357] establishes a round-trip packet loss (TWAMP) specified in [RFC5357] establishes a round-trip packet loss
measurement capability for the Internet. However, there is currently measurement capability for the Internet. However, there is currently
no round-trip packet loss metric specified according to the [RFC2330] no round-trip packet loss metric specified according to the [RFC2330]
framework. framework.
[RFC2681] indicates that round-trip measurements may sometimes [RFC2681] indicates that round-trip measurements may sometimes
encounter "asymmetric" paths. When loss is observed using a round- encounter "asymmetric" paths. When loss is observed using a round-
trip measurement, there is often a desire to ascertain which of the trip measurement, there is often a desire to ascertain which of the
two directional paths "lost" the packet. Under some circumstances, two directional paths "lost" the packet. Under some circumstances,
it is possible to make this inference. The round-trip measurement it is possible to make this inference. The round-trip measurement
method raises a few complications when interpreting the embedded one- method raises a few complications when interpreting the embedded one-
skipping to change at page 4, line 17 skipping to change at page 5, line 4
[RFC2681] also points out that loss measurement conducted [RFC2681] also points out that loss measurement conducted
sequentially in both directions of a path and reported as a round- sequentially in both directions of a path and reported as a round-
trip result may be exactly the desired metric. On the other hand, it trip result may be exactly the desired metric. On the other hand, it
may be difficult to derive the state of round-trip packet loss from may be difficult to derive the state of round-trip packet loss from
one-way measurements conducted in each direction unless a method to one-way measurements conducted in each direction unless a method to
match the appropriate one-way measurements has been pre-arranged. match the appropriate one-way measurements has been pre-arranged.
Finally, many measurement systems report statistics on a conditional Finally, many measurement systems report statistics on a conditional
delay distribution, where the condition is packet arrival at the delay distribution, where the condition is packet arrival at the
destination. This condition is encouraged in [RFC3393], [RFC5481], destination. This condition is encouraged in [RFC3393], [RFC5481],
and [draft-ietf-ippm-reporting-metrics]. As a result, lost packets and [RFC6703]. As a result, lost packets need to be reported
need to be reported separately, according to a standardized metric. separately, according to a standardized metric. This memo defines
This memo defines such a metric. such a metric.
See Section 1.1 of[RFC2680] for additional motivation of the packet See Section 1.1 of [RFC2680] for additional motivation of the packet
loss metric. loss metric.
1.2. 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].
2. Scope 2. Scope
This memo defines a round-trip packet loss metric using the This memo defines a round-trip packet loss metric using the
conventions of the IPPM framework [RFC2330]. conventions of the IPPM framework [RFC2330].
The memo defines a singleton metric, a sample metric, and a The memo defines a singleton metric, a sample metric, and a
statistic, as per [RFC2330]. The [RFC2330] framework is for active statistic, as per [RFC2330]. The [RFC2330] framework is for active
measurement methods. Although this metric MAY be applicable in measurement methods. Although this metric MAY be applicable in
passive measurement as well, discussion of additional considerations passive measurement as well, discussion of additional considerations
for the passive scenario are beyond the normative scope of this memo. for the passive scenario are beyond the normative scope of this memo.
The memo also investigates the topic of one-way loss inference from a The memo also investigates the topic of one-way loss inference from a
two-way measurement, and lists some key considerations. two-way measurement and lists some key considerations.
3. Common Specifications for Round-trip Metrics 3. Common Specifications for Round-Trip Metrics
To reduce the redundant information presented in the detailed metrics To reduce the redundant information presented in the detailed metrics
sections that follow, this section presents the specifications that sections that follow, this section presents the specifications that
are common to two or more metrics. The section is organized using are common to two or more metrics. The section is organized using
the same subsections as the individual metrics, to simplify the same subsections as the individual metrics, to simplify
comparisons. comparisons.
3.1. Name: Type-P-* 3.1. Name: Type-P-*
All metrics use the Type-P convention as described in [RFC2330]. The All metrics use the Type-P convention as described in [RFC2330]. The
skipping to change at page 5, line 12 skipping to change at page 6, line 4
All metrics use the Type-P convention as described in [RFC2330]. The All metrics use the Type-P convention as described in [RFC2330]. The
rest of the name is unique to each metric. rest of the name is unique to each metric.
3.2. Metric Parameters 3.2. Metric Parameters
o Src, the IP address of a host o Src, the IP address of a host
o Dst, the IP address of a host o Dst, the IP address of a host
o T, a time (start of test interval) o T, a time (start of test interval)
o Tf, a time (end of test interval) o Tf, a time (end of test interval)
o lambda, a rate in reciprocal seconds (for Poisson Streams) o lambda, a rate in reciprocal seconds (for Poisson Streams)
o incT, the nominal duration of inter-packet interval, first bit to o incT, the nominal duration of inter-packet interval, first bit to
first bit (for Periodic Streams) first bit (for Periodic Streams)
o T0, a time that MUST be selected at random from the interval [T, o T0, a time that MUST be selected at random from the interval
T+dT] to start generating packets and taking measurements (for [T, T+dT] to start generating packets and taking measurements (for
Periodic Streams) Periodic Streams)
o TstampSrc, the wire time of the packet as measured at MP(Src) as o TstampSrc, the wire time of the packet as measured at MP(Src) as
it leaves for Dst. it leaves for Dst.
o TstampDst, the wire time of the packet as measured at MP(Dst), o TstampDst, the wire time of the packet as measured at MP(Dst),
assigned to packets that arrive within a "reasonable" time (less assigned to packets that arrive within a "reasonable" time (less
than Tmax). than Tmax).
o Tmax, a maximum waiting time for packets to arrive at Src, set o Tmax, a maximum waiting time for packets to arrive at Src, set
skipping to change at page 6, line 7 skipping to change at page 6, line 46
This section is specific to each metric. This section is specific to each metric.
3.4. Metric Units 3.4. Metric Units
The metric units are logical (1 or 0) when describing a single The metric units are logical (1 or 0) when describing a single
packet's loss performance, where a 0 indicates successful packet packet's loss performance, where a 0 indicates successful packet
transmission and a 1 indicates packet loss. transmission and a 1 indicates packet loss.
Units of time are as specified in [RFC2330]. Units of time are as specified in [RFC2330].
Other units used are defined in the associated section. Other units used are defined in the associated section where
needed (e.g., Section 6.1 in the case of
Type-P-Round-trip-Loss-<Sample>-Ratio).
4. A Singleton Round-trip Loss Metric 4. A Singleton Round-Trip Loss Metric
4.1. Name: Type-P-Round-trip-Loss 4.1. Name: Type-P-Round-trip-Loss
4.2. Metric Parameters 4.2. Metric Parameters
See section 3.2. See Section 3.2.
4.3. Definition and Metric Units 4.3. Definition and Metric Units
Type-P-Round-trip-Loss SHALL be represented by the binary logical Type-P-Round-trip-Loss SHALL be represented by the binary logical
values (or their equivalents) when the following conditions are met: values (or their equivalents) when the following conditions are met:
Type-P-Round-trip-Loss = 0: Type-P-Round-trip-Loss = 0:
o Src sent the first bit of a Type-P packet to Dst at wire-time o Src sent the first bit of a Type-P packet to Dst at wire-time
TstampSrc, TstampSrc,
skipping to change at page 6, line 44 skipping to change at page 7, line 40
wire-time TstampSrc + Tmax. wire-time TstampSrc + Tmax.
Type-P-Round-trip-Loss = 1: Type-P-Round-trip-Loss = 1:
o Src sent the first bit of a Type-P packet to Dst at wire-time o Src sent the first bit of a Type-P packet to Dst at wire-time
TstampSrc, TstampSrc,
o that Src did not receive the last bit of the reflected packet o that Src did not receive the last bit of the reflected packet
before the waiting time lapsed at TstampSrc + Tmax. before the waiting time lapsed at TstampSrc + Tmax.
Possible causes for the Loss = 1 outcome are: Possible causes for the Loss = 1 outcome are as follows:
o the Dst did not receive that packet, o the Dst did not receive that packet,
o the Dst did not send a Type-P packet back to the Src, or o the Dst did not send a Type-P packet back to the Src, or
o the Src did not receive a reflected Type-P packet sent from the o the Src did not receive a reflected Type-P packet sent from
Dst. the Dst.
Following the precedent of Section 2.4 of[RFC2681], we make the Following the precedent of Section 2.4 of [RFC2681], we make the
simplifying assertion, that Round-trip loss measured between two simplifying assertion that round-trip loss measured between two hosts
hosts is equal regardless of the host that originates the test: is equal regardless of the host that originates the test:
Type-P-Round-trip-Loss(Src->Dst->Src) = Type-P-Round-trip- Type-P-Round-trip-Loss(Src->Dst->Src) =
Loss(Dst->Src->Dst) Type-P-Round-trip-Loss(Dst->Src->Dst)
(and agree with the rationale presented there, that the ambiguity (and agree with the rationale presented there -- that the ambiguity
introduced is a small price to pay for measurement efficiency). introduced is a small price to pay for measurement efficiency).
Therefore, each singleton can be represented by pairs of elements as Therefore, each singleton can be represented by pairs of elements as
follows: follows:
o TstampSrc, the wire time of the packet at the Src (beginning the o TstampSrc, the wire time of the packet at the Src (beginning the
round-trip journey). round-trip journey).
o L, either zero or one (or some logical equivalent), where L=1 o L, either zero or one (or some logical equivalent), where L=1
indicates loss and L=0 indicates successful round-trip arrival indicates loss and L=0 indicates successful round-trip arrival
prior to TstampSrc + Tmax. prior to TstampSrc + Tmax.
4.4. Discussion and other details 4.4. Discussion and Other Details
See [RFC2680] and [RFC2681] for extensive discussion, methods of See [RFC2680] and [RFC2681] for extensive discussion, methods of
measurement, errors and uncertainties, and other fundamental measurement, errors and uncertainties, and other fundamental
considerations that need not be repeated here. considerations that need not be repeated here.
We add the following guidance regarding the responder process to We add the following guidance regarding the responder process to
"send a Type-P packet back to the Src as quickly as possible". "send a Type-P packet back to the Src as quickly as possible".
A response that was not generated within Tmax is inadequate for any A response that was not generated within Tmax is inadequate for any
realistic test, and the Src will discard such responses. A responder realistic test, and the Src will discard such responses. A responder
that serves typical round-trip packet loss testing (which is relevant that serves typical round-trip packet loss testing (which is relevant
to higher-layer application performance) SHOULD produce a response in to higher-layer application performance) SHOULD produce a response in
1 second or less. A responder that is unable to satisfy this 1 second or less. A responder that is unable to satisfy this
requirement SHOULD log the fact so that an operator can adjust the requirement SHOULD log the fact so that an operator can adjust the
load and priorities as necessary. Analysis of responder time-stamps load and priorities as necessary. Analysis of responder timestamps
[RFC5357] that finds responses are not generated in a timely fashion [RFC5357] that finds responses are not generated in a timely fashion
SHOULD result in operator notification, and the operator SHOULD SHOULD result in operator notification, and the operator SHOULD
suspend tests to the responder since it may be overloaded. suspend tests to the responder, since it may be overloaded.
Additional measurement considerations are described in Section 8, Additional measurement considerations are described in Section 8
below. below.
5. A Sample Round-trip Loss Metric 5. A Sample Round-Trip Loss Metric
Given the singleton metric Type-P-Round-trip-Loss, we now define one Given the singleton metric Type-P-Round-trip-Loss, we now define one
particular sample of such singletons. The idea of the sample is to particular sample of such singletons. The idea of the sample is to
select a particular binding of the parameters Src, Dst, and Type-P, select a particular binding of the parameters Src, Dst, and Type-P,
then define a sample of values of parameter TstampSrc. This can be then define a sample of values of parameter TstampSrc. This can be
done in several ways, including: done in several ways, including the following:
1. Poisson: a pseudo-random Poisson process of rate lambda, whose 1. Poisson: a pseudo-random Poisson process of rate lambda, whose
values fall between T and Tf. The time interval between values fall between T and Tf. The time interval between
successive values of TstampSrc will then average 1/lambda, as per successive values of TstampSrc will then average 1/lambda, as per
Section 11.1 of [RFC2330]. Section 11.1.1 of [RFC2330].
2. Periodic: a periodic stream process with pseudo-random start time 2. Periodic: a periodic stream process with pseudo-random start time
T0 between T and dT, and nominal inter-packet interval incT, as T0 between T and dT, and nominal inter-packet interval incT, as
per [RFC3432]. per [RFC3432].
In the metric name, the variable <Sample> SHALL be replaced with the In the metric name, the variable <Sample> SHALL be replaced with the
process used to define the sample, using one of the above processes process used to define the sample, using one of the above processes
(or another sample process meeting the criteria in Section 11.1 of (or another sample process meeting the criteria in Section 11.1 of
[RFC2330], the details of which MUST be reported with the results if [RFC2330], the details of which MUST be reported with the results if
used). used).
5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream 5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream
5.2. Metric Parameters 5.2. Metric Parameters
See section 3.2. See Section 3.2.
5.3. Definition and Metric Units 5.3. Definition and Metric Units
Given one of the methods for defining the test interval, the sample Given one of the methods for defining the test interval -- the sample
of times (TstampSrc) and other metric parameters, we obtain a of times (TstampSrc) and other metric parameters -- we obtain a
sequence of Type-P-Round-trip-Loss singletons as defined in section sequence of Type-P-Round-trip-Loss singletons as defined in
4.3. Section 4.3.
Type-P-Round-trip-Loss-<Sample>-Stream SHALL be a sequence of pairs Type-P-Round-trip-Loss-<Sample>-Stream SHALL be a sequence of pairs
with elements as follows: with elements as follows:
o TstampSrc, as above o TstampSrc, as above
o L, either zero or one (or some logical equivalent), where L=1 o L, either zero or one (or some logical equivalent), where L=1
indicates loss and L=0 indicates successful round-trip arrival indicates loss and L=0 indicates successful round-trip arrival
prior to TstampSrc + Tmax. prior to TstampSrc + Tmax
and where <Sample> SHALL be replaced with "Poisson", "Periodic", or and where <Sample> SHALL be replaced with "Poisson", "Periodic", or
an appropriate term to designate another sample method as described an appropriate term to designate another sample method as described
in Section 5 above. in Section 5 above.
5.4. Discussion and other details 5.4. Discussion and Other Details
See [RFC2680] and [RFC2681] for extensive discussion, methods of See [RFC2680] and [RFC2681] for extensive discussion, methods of
measurement, errors and uncertainties, and other fundamental measurement, errors and uncertainties, and other fundamental
considerations that need not be repeated here. However, when these considerations that need not be repeated here. However, when these
references were approved, the packet reordering metrics in [RFC4737] references were approved, the packet reordering metrics in [RFC4737]
had not yet been defined, nor had reordering been addressed in IPPM had not yet been defined, nor had reordering been addressed in IPPM
methodologies. methodologies.
[RFC4737] defines packets that arrive "late" with respect to their [RFC4737] defines packets that arrive "late" with respect to their
sending order as reordered. For example, when packets arrive with sending order as reordered -- for example, when packets arrive with
sequence numbers 4, 7, 5, 6, then packets 5 and 6 are reordered, and sequence numbers 4, 7, 5, 6, then packets 5 and 6 are reordered, and
they are obviously not lost because they have arrived within some they are obviously not lost because they have arrived within some
reasonable waiting time threshold. The presence of reordering on a reasonable waiting time threshold. The presence of reordering on a
round-trip path has several likely effects on the measurement. round-trip path has several likely effects on the measurement.
1. Methods of measurement should continue to wait the specified time 1. Methods of measurement should continue to wait the specified time
for packets, and avoid prematurely declaring round-trip packet for packets and avoid prematurely declaring round-trip packet
loss when a sequence gap or error is observed. loss when a sequence gap or error is observed.
2. The time distribution of the singletons in the sample has been 2. The time distribution of the singletons in the sample has been
significantly changed. significantly changed.
3. Either the original packet stream or the reflected packet stream 3. Either the original packet stream or the reflected packet stream
experienced path instability, and the original conditions may no experienced path instability, and the original conditions may no
longer be present. longer be present.
Measurement implementations MUST address the possibility for packet Measurement implementations MUST address the possibility of packet
reordering and avoid related errors in their processes. reordering and avoid related errors in their processes.
6. Round-trip Loss Statistic 6. Round-Trip Loss Statistic
This section gives the primary and overall statistic for loss This section gives the primary and overall statistic for loss
performance. Additional statistics and metrics originally prepared performance. Additional statistics and metrics originally prepared
for One-way loss MAY also be applicable. for one-way loss MAY also be applicable.
6.1. Type-P-Round-trip-Loss-<Sample>-Ratio 6.1. Type-P-Round-trip-Loss-<Sample>-Ratio
Given a Type-P-Round-trip-Loss-<Sample>-Stream, the average of all Given a Type-P-Round-trip-Loss-<Sample>-Stream, the average of
the logical values, L, in the Stream is the Type-P-Round-trip-Loss- all the logical values, L, in the stream is the
<Sample>-Ratio. This ratio is in units of lost packets per round- Type-P-Round-trip-Loss-<Sample>-Ratio. This ratio is in units of
trip transmissions actually attempted. lost packets per round-trip transmissions actually attempted.
In addition, the Type-P-Round-trip-Loss-<Sample>-Ratio is undefined In addition, the Type-P-Round-trip-Loss-<Sample>-Ratio is undefined
if the sample is empty. if the sample is empty.
7. Round-trip Testing and One-way Reporting 7. Round-Trip Testing and One-Way Reporting
This section raises considerations for results collected using a This section raises considerations for results collected using a
round-trip measurement architecture, such as in TWAMP [RFC5357]. round-trip measurement architecture, such as in TWAMP [RFC5357].
The sampling process for the reverse path (Dst->Src) is a conditional The sampling process for the reverse path (Dst->Src) is a conditional
process that depends on successful packet arrival at the Dst and process that depends on successful packet arrival at the Dst and
correct operation at the Dst to generate the reflected packet. correct operation at the Dst to generate the reflected packet.
Therefore, the sampling process for the reverse path will be Therefore, the sampling process for the reverse path will be
significantly affected when appreciable loss occurs on the Src->Dst significantly affected when appreciable loss occurs on the Src->Dst
path, making an attempt to assess the reverse path performance path, making an attempt to assess the reverse path performance
invalid (for loss or possibly any metric). invalid (for loss or possibly any metric).
Further, the sampling times for the reverse path (Dst->Src) are a Further, the sampling times for the reverse path (Dst->Src) are a
random process that depends on the original sample times (TstampSrc), random process that depends on the original sample times (TstampSrc),
the one-way-delay for successful packet arrival at the Dst, and time the one-way delay for successful packet arrival at the Dst, and time
taken at the Dst to generate the reflected packet. Therefore, the taken at the Dst to generate the reflected packet. Therefore, the
sampling process for the reverse path will be significantly affected sampling process for the reverse path will be significantly affected
when appreciable delay variation occurs on the Src->Dst path, making when appreciable delay variation occurs on the Src->Dst path, making
an attempt to assess the reverse path performance invalid (for loss an attempt to assess the reverse path performance invalid (for loss
or possibly any metric). or possibly any metric).
As discussed above in Section 5.4, packet reordering is always a As discussed above in Section 5.4, packet reordering is always a
possibility. In addition to the severe delay variation that usually possibility. In addition to the severe delay variation that usually
accompanies it, reordering on the Src->Dst path will cause a mis- accompanies it, reordering on the Src->Dst path will cause a
alignment of sequence numbers applied at the Dst when compared to the misalignment of sequence numbers applied at the Dst when compared to
sender numbers. Measurement implementations MUST address this the sender numbers. Measurement implementations MUST address this
possible outcome. possible outcome.
8. Measurement Considerations and Calibration 8. Measurement Considerations and Calibration
Prior to conducting this measurement, the participating hosts MUST be Prior to conducting this measurement, the participating hosts MUST be
configured to send and receive test packets of the chosen Type-P. configured to send and receive test packets of the chosen Type-P.
Standard measurement protocols are capable of this task [RFC5357], Standard measurement protocols are capable of this task [RFC5357],
but any reliable method is sufficient (e.g., if the issues with ICMP but any reliable method is sufficient (e.g., if the issues with ICMP
discussed in Section 2.6 of[RFC2681] can be alleviated, and the discussed in Section 2.6 of [RFC2681] can be alleviated, and the
requirements of Section 4.3 and Section 4.4 above are met, then ICMP requirements of Sections 4.3 and 4.4 above are met, then ICMP could
could be used). be used).
Two key features of the host that receives test packets and returns Two key features of the host that receives test packets and returns
them to the originating host are described in section 4.2 of them to the originating host are described in Section 4.2 of
[RFC5357] . Every received test packet MUST result in a responding [RFC5357]. Every received test packet MUST result in a responding
packet, and the response MUST be generated as quickly as possible. packet, and the response MUST be generated as quickly as possible.
This implies that interface buffers will be serviced promptly, and This implies that interface buffers will be serviced promptly and
that buffer discards will be extremely rare. These features of the that buffer discards will be extremely rare. These features of the
measurement equipment MUST be calibrated according to Section 3.7.3 measurement equipment MUST be calibrated according to Section 3.7.3
of [RFC2679], when operating under a representative measurement load of [RFC2679] when operating under a representative measurement load
(as defined by the user). Both unexpected test packet discards, and (as defined by the user). Both unexpected test packet discards, and
the systematic and random errors and uncertainties, MUST be recorded. the systematic and random errors and uncertainties, MUST be recorded.
We note that Section 4.2.1 of [RFC5357] specifies a method to collect We note that Section 4.2.1 of [RFC5357] specifies a method to collect
all four significant time-stamps needed to describe a packet's round- all four significant timestamps needed to describe a packet's round-
trip delay [RFC2681] and remove the processing time incurred at the trip delay [RFC2681] and remove the processing time incurred at the
responding host. This information supports the measurement of the responding host. This information supports the measurement of the
corresponding One-way Delays encountered on the round-trip path, corresponding one-way delays encountered on the round-trip path,
which can identify path asymmetry or unexpected processing time at which can identify path asymmetry or unexpected processing time at
the responding host. the responding host.
9. Security Considerations 9. Security Considerations
9.1. Denial of Service Attacks 9.1. Denial-of-Service Attacks
This metric requires a stream of packets sent from one host (source) This metric requires a stream of packets sent from one host (source)
to another host (destination) through intervening networks, and back. to another host (destination) through intervening networks, and back.
This method could be abused for denial of service attacks directed at This method could be abused for denial-of-service attacks directed at
the destination and/or the intervening network(s). the destination and/or the intervening network(s).
Administrators of source, destination, and the intervening network(s) Administrators of source, destination, and intervening network(s)
should establish bilateral or multi-lateral agreements regarding the should establish bilateral or multilateral agreements regarding the
timing, size, and frequency of collection of sample metrics. Use of timing, size, and frequency of collection of sample metrics. Use of
this method in excess of the terms agreed between the participants this method in excess of the terms agreed upon by the participants
may be cause for immediate rejection or discard of packets or other may be cause for immediate rejection or discard of packets, or other
escalation procedures defined between the affected parties. escalation procedures as defined between the affected parties.
9.2. User Data Confidentiality 9.2. User Data Confidentiality
Active use of this method generates packets for a sample, rather than Active use of this method generates packets for a sample, rather than
taking samples based on user data, and does not threaten user data taking samples based on user data, and does not threaten user data
confidentiality. Passive measurement must restrict attention to the confidentiality. Passive measurement must restrict attention to the
headers of interest. Since user payloads may be temporarily stored headers of interest. Since user payloads may be temporarily stored
for length analysis, suitable precautions MUST be taken to keep this for length analysis, suitable precautions MUST be taken to keep this
information safe and confidential. In most cases, a hashing function information safe and confidential. In most cases, a hashing function
will produce a value suitable for payload comparisons. will produce a value suitable for payload comparisons.
9.3. Interference with the metrics 9.3. Interference with the Metrics
It may be possible to identify that a certain packet or stream of It may be possible to identify that a certain packet or stream of
packets is part of a sample. With that knowledge at the destination packets is part of a sample. With that knowledge at the destination
and/or the intervening networks, it is possible to change the and/or the intervening networks, it is possible to change the
processing of the packets (e.g. increasing or decreasing delay) in a processing of the packets (e.g., increasing or decreasing delay) in a
way that may distort the measured performance. It may also be way that may distort the measured performance. It may also be
possible to generate additional packets that appear to be part of the possible to generate additional packets that appear to be part of the
sample metric. These additional packets are likely to perturb the sample metric. These additional packets are likely to perturb the
results of the sample measurement. results of the sample measurement.
Authentication or encryption techniques, such as digital signatures, Authentication or encryption techniques, such as digital signatures,
MAY be used where appropriate to guard against injected traffic MAY be used where appropriate to guard against injected traffic
attacks. [RFC5357] includes both authentication and encryption attacks. [RFC5357] includes both authentication and encryption
features. features.
10. IANA Considerations 10. IANA Considerations
Metrics previously defined in IETF were registered in the IANA IPPM Metrics previously defined in the IETF were registered in the IANA
METRICS REGISTRY, however this process was discontinued when the IPPM Metrics Registry; however, this process was discontinued when
registry structure was found to be inadequate, and the registry was the registry structure was found to be inadequate, and the registry
declared Obsolete [RFC6248]. was declared obsolete [RFC6248].
Although the metrics in this draft may be considered for some form of Although the metrics in this document may be considered for some form
registration in the future, no IANA Action is requested at this time. of registration in the future, no IANA action is requested at this
time.
11. Acknowledgements 11. Acknowledgements
The author thanks Tiziano Ionta for his careful review of this memo, The author thanks Tiziano Ionta for his careful review of this memo,
primarily resulting in the development of measurement considerations primarily resulting in the development of measurement considerations
using TWAMP [RFC5357] as an example method. The reviews of Adrian using TWAMP [RFC5357] as an example method. The reviews of Adrian
Farrel and Benoit Claise also contributed to the clarity of the memo. Farrel and Benoit Claise also contributed to the clarity of the memo.
12. References 12. References
skipping to change at page 13, line 20 skipping to change at page 14, line 30
12.2. Informative References 12.2. Informative References
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, March 2009. Applicability Statement", RFC 5481, March 2009.
[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics
(IPPM) Registry of Metrics Are Obsolete", RFC 6248, (IPPM) Registry of Metrics Are Obsolete", RFC 6248,
April 2011. April 2011.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View",
RFC 6703, August 2012.
Author's Address Author's Address
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192 Fax: +1 732 368 1192
Email: acmorton@att.com EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/ URI: http://home.comcast.net/~acmacm/
 End of changes. 65 change blocks. 
142 lines changed or deleted 146 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/