summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5560.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5560.txt')
-rw-r--r--doc/rfc/rfc5560.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc5560.txt b/doc/rfc/rfc5560.txt
new file mode 100644
index 0000000..f973b68
--- /dev/null
+++ b/doc/rfc/rfc5560.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group H. Uijterwaal
+Request for Comments: 5560 RIPE NCC
+Category: Standards Track May 2009
+
+
+ A One-Way Packet Duplication Metric
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+Abstract
+
+ When a packet is sent from one host to the other, one normally
+ expects that exactly one copy of the packet that was sent arrives at
+ the destination. It is, however, possible that a packet is either
+ lost or that multiple copies arrive.
+
+ In earlier work, a metric for packet loss was defined. This metric
+ quantifies the case where a packet that is sent does not arrive at
+ its destination within a reasonable time. In this memo, a metric for
+ another case is defined: a packet is sent, but multiple copies
+ arrive. The document also discusses streams and methods to summarize
+ the results of streams.
+
+
+
+
+
+
+
+
+
+
+
+
+Uijterwaal Standards Track [Page 1]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Requirements Notation ......................................3
+ 1.2. Motivation .................................................4
+ 2. A Singleton Definition for One-Way Packet Arrival Count .........4
+ 2.1. Metric Name ................................................4
+ 2.2. Metrics Parameters .........................................4
+ 2.3. Metric Units ...............................................4
+ 2.4. Definition .................................................4
+ 2.5. Discussion .................................................5
+ 2.6. Methodology ................................................6
+ 2.7. Errors and Uncertainties ...................................6
+ 2.8. Reporting the Metric .......................................6
+ 3. A Singleton Definition for One-Way Packet Duplication ...........6
+ 3.1. Metric Name ................................................6
+ 3.2. Metrics Parameters .........................................7
+ 3.3. Metric Units ...............................................7
+ 3.4. Definition .................................................7
+ 3.5. Discussion .................................................7
+ 4. Definition for Samples for One-Way Packet Duplication ...........7
+ 4.1. Poisson Streams ............................................7
+ 4.1.1. Metric Name .........................................7
+ 4.1.2. Metric Parameters ...................................8
+ 4.1.3. Metric Units ........................................8
+ 4.1.4. Definition ..........................................8
+ 4.1.5. Methodology .........................................8
+ 4.1.6. Errors and Uncertainties ............................8
+ 4.1.7. Reporting the Metric ................................8
+ 4.2. Periodic Streams ...........................................9
+ 4.2.1. Metric Name .........................................9
+ 4.2.2. Metric Parameters ...................................9
+ 4.2.3. Metric Units ........................................9
+ 4.2.4. Definition ..........................................9
+ 4.2.5. Methodology .........................................9
+ 4.2.6. Errors and uncertainties ............................9
+ 4.2.7. Reporting the metric ...............................10
+ 5. Some Statistics Definitions for One-Way Duplication ............10
+ 5.1. Type-P-one-way-packet-duplication-fraction ................10
+ 5.2. Type-P-one-way-replicated-packet-rate .....................10
+ 5.3. Examples ..................................................11
+ 6. Security Considerations ........................................12
+ 7. IANA Considerations ............................................12
+ 8. Acknowledgements ...............................................13
+ 9. References .....................................................13
+ 9.1. Normative References ......................................13
+ 9.2. Informative References ....................................13
+
+
+
+
+Uijterwaal Standards Track [Page 2]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+1. Introduction
+
+ This document defines a metric for one-way packet duplication across
+ Internet paths. It builds on the IP Performance Metrics (IPPM)
+ Framework document [RFC2330]; the reader is assumed to be familiar
+ with that document.
+
+ This document follows the same structure as the document for one-way
+ packet loss [RFC2680]; the reader is assumed to be familiar with that
+ document as well.
+
+ The structure of this memo is as follows:
+
+ o First, a singleton metric, called Type-P-one-way-packet-arrival-
+ count, is introduced to measure the number of arriving packets for
+ each packet sent.
+
+ o Then, a singleton metric, called Type-P-one-way-packet-
+ duplication, is defined to describe a single instance of packet
+ duplication.
+
+ o Next, this singleton metric is used to define samples, Type-P-one-
+ way-Packet-Duplication-Poisson-Stream and Type-P-one-way-Packet-
+ Duplication-Periodic-Stream. These are introduced to measure
+ duplication in a series of packets sent with either Poisson-
+ distributed [RFC2680] or periodic [RFC3432] intervals between the
+ packets.
+
+ o Finally, statistics that summarize the properties of these samples
+ are introduced.
+
+1.1. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ Although RFC 2119 was written with protocols in mind, the key words
+ are used in this document for similar reasons. They are used to
+ ensure the results of measurements from two different implementations
+ are comparable and to note instances when an implementation could
+ perturb the network.
+
+
+
+
+
+
+
+
+
+Uijterwaal Standards Track [Page 3]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+1.2. Motivation
+
+ When a packet is sent from one host to the other, one normally
+ expects that exactly one copy of the packet that was sent arrives at
+ the destination. It is, however, possible that a packet is either
+ lost or that multiple copies arrive.
+
+ In earlier work, a metric for packet loss was defined [RFC2680].
+ This metric distinguishes between cases where the packet arrives and
+ where the packet does not arrive within a reasonable time. In this
+ memo, a metric for a third outcome is defined: a single packet is
+ sent, but multiple copies arrive.
+
+ As this document describes a case similar to the one discussed in
+ [RFC2680], all considerations from that document on timing and
+ accuracy apply.
+
+2. A Singleton Definition for One-Way Packet Arrival Count
+
+2.1. Metric Name
+
+ Type-P-one-way-packet-arrival-count
+
+2.2. Metrics Parameters
+
+ o src, the IP address of a host
+
+ o dst, the IP address of a host
+
+ o T, the wire time of a packet at the source
+
+ o T0, the maximum waiting time for a packet to arrive at the
+ destination.
+
+2.3. Metric Units
+
+ An integer number.
+
+2.4. Definition
+
+ Two packets are considered identical if and only if:
+
+ o Both contain identical information fields (see Section 2.5). The
+ recipient thus could take either packet and use the data in an
+ application. The other packet does not contain any additional
+ information.
+
+
+
+
+
+Uijterwaal Standards Track [Page 4]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+ o Both packets appear to have been sent by one and the same host, to
+ one and the same destination. Hosts are identified by their IP
+ addresses.
+
+ The value of a Type-P-one-way-packet-arrival-count is a positive
+ integer number indicating the number of (uncorrupted and identical)
+ copies received by dst in the interval [T, T+T0] for a packet sent by
+ src at time T.
+
+ If a packet is sent, but it is lost or does not arrive in the
+ interval [T, T+T0], then the metric is undefined. Applications MAY
+ report an "impossible" value (for example, -1) to indicate this
+ condition instead of undefined.
+
+ If a packet is fragmented during transport and if, for whatever
+ reason, reassembly does not occur, then the packet will be deemed
+ lost. It is thus not included in the Type-P-one-way-packet-arrival-
+ count.
+
+2.5. Discussion
+
+ This metric counts the number of packets arriving for each packet
+ sent. The time-out value T0 SHOULD be set to a value when the
+ application could potentially still use the packet and would not
+ discard it automatically.
+
+ If this metric is used in parallel with the Packet Loss Metric
+ [RFC2680], the value of T0 MUST be the same for both cases in order
+ to keep the results comparable.
+
+ The metric only counts packets that are not corrupted during
+ transmission and may have been resent automatically by lower layers
+ or intermediate devices. Packets that were corrupted during
+ transmission but, nevertheless, still arrived at dst are not counted.
+
+ Clocks do have to be synchronized between src and dst such that it is
+ possible to uniquely and accurately determine the interval [T, T+T0]
+ at both sides.
+
+ If this metric is used in an active measurement system, the system
+ MUST NOT send multiple packets with identical information fields in
+ order to avoid that all packets will be declared duplicates. This
+ metric can be used inside a passive measurement system as well, using
+ packets generated by another source. However, if the source can send
+ two identical packets within the interval [T, T+T0], this will be
+ incorrectly labeled as a duplicate, resulting in a false positive.
+ It is up to the implementor to estimate if this scenario is likely to
+ happen and the rate of false positives that is acceptable.
+
+
+
+Uijterwaal Standards Track [Page 5]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+ The definition of identical information fields is such that two
+ packets are considered to be identical if they are sent from the same
+ source and contain the same information. This does not necessarily
+ mean that all bits in the packet are the same. For example, when a
+ packet is replicated and the copies are transferred along different
+ paths, the Time to Live (TTL) may be different. The implementation
+ MUST specify which fields are compared when deciding whether or not
+ two packets are identical.
+
+ In the case of IPv4, these will usually be: version, ihl,
+ identification, src, dst, protocol, some or all upper-layer protocol
+ data.
+
+ In IPv6, these will usually be: version, next header, source,
+ destination, some or all upper-layer protocol data
+
+ Note that the use of the identification field is not present in non-
+ fragmented IPv6 packets and may not be sufficient to distinguish
+ packets from each even in IPv4, particularly at higher transmission
+ speeds
+
+2.6. Methodology
+
+ The basic technique to measure this metric follows the methodology
+ described in Section 2.6 of [RFC2680] with one exception.
+
+ [RFC2680] does not specify that the receiving host should be able to
+ receive multiple copies of a single packet, as it only needs one copy
+ to determine the metrics. Implementations for this metric should
+ obviously be capable of receiving multiple copies.
+
+2.7. Errors and Uncertainties
+
+ Refer to Section 2.7 of [RFC2680].
+
+2.8. Reporting the Metric
+
+ Refer to Section 2.8 of [RFC2680].
+
+3. A Singleton Definition for One-Way Packet Duplication
+
+3.1. Metric Name
+
+ Type-P-one-way-packet-duplication
+
+
+
+
+
+
+
+Uijterwaal Standards Track [Page 6]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+3.2. Metrics Parameters
+
+ o src, the IP address of a host
+
+ o dst, the IP address of a host
+
+ o T, the wire time of a packet at the source
+
+ o T0, the maximum waiting time for a packet to arrive at the
+ destination.
+
+3.3. Metric Units
+
+ An integer number.
+
+3.4. Definition
+
+ The value of a Type-P-one-way-packet-duplication is a positive
+ integer number indicating the number of (uncorrupted and identical)
+ additional copies of an individual packet received by dst in the
+ interval [T, T+T0] as sent by src at time T.
+
+ If a packet is sent and only one copy arrives in the interval [T,
+ T+T0], then the metric is 0. If no copy arrives in this interval,
+ then the metric is undefined. Applications MAY report an
+ "impossible" value (for example, -1) to indicate this condition.
+
+3.5. Discussion
+
+ This metric is equal to:
+
+ Type-P-one-way-packet-arrival-count - 1
+
+ This metric is expected to be used for applications that need to know
+ duplication for an individual packet. All considerations regarding
+ methodology, errors, and reporting from the previous section apply.
+
+4. Definition for Samples for One-Way Packet Duplication
+
+4.1. Poisson Streams
+
+4.1.1. Metric Name
+
+ Type-P-one-way-Packet-Duplication-Poisson-Stream
+
+
+
+
+
+
+
+Uijterwaal Standards Track [Page 7]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+4.1.2. Metric Parameters
+
+ o src, the IP address of a host.
+
+ o dst, the IP address of a host.
+
+ o Ts, a time.
+
+ o Tf, a time. Ts and Tf specify the time interval when packets can
+ be sent for this stream.
+
+ o T0, the maximum waiting time for a packet to arrive at the
+ destination.
+
+ o lambda, a rate in reciprocal seconds.
+
+4.1.3. Metric Units
+
+ A sequence of pairs; the elements of each pair are:
+
+ o T, a time
+
+ o Type-P-one-way-packet-arrival-count for the packet sent at T.
+
+4.1.4. Definition
+
+ Given Ts, Tf, and lambda, we compute a pseudo-random Poisson process
+ beginning at or before Ts, with average-rate lambda, and ending at or
+ after Tf. Those time values greater than or equal to Ts, and less
+ than or equal to Tf are then selected. At each of the times in this
+ process, we obtain the value of Type-P-one-way-packet-arrival-count.
+ The value of the sample is the sequence made up of the resulting
+ {time, duplication} pairs. If there are no such pairs, the sequence
+ is of length zero, and the sample is said to be empty.
+
+4.1.5. Methodology
+
+ Refer to Section 3.6 of [RFC2680].
+
+4.1.6. Errors and Uncertainties
+
+ Refer to Section 3.7 of [RFC2680].
+
+4.1.7. Reporting the Metric
+
+ Refer to Section 3.8 of [RFC2680].
+
+
+
+
+
+Uijterwaal Standards Track [Page 8]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+4.2. Periodic Streams
+
+4.2.1. Metric Name
+
+ Type-P-one-way-Packet-Duplication-Periodic-Stream
+
+4.2.2. Metric Parameters
+
+ o src, the IP address of a host.
+
+ o dst, the IP address of a host.
+
+ o Ts, a time.
+
+ o Tf, a time. Ts and Tf specify the time interval when packets can
+ be sent for this stream.
+
+ o T0, the maximum waiting time for a packet to arrive at the
+ destination.
+
+ o lambda, a rate in reciprocal seconds.
+
+4.2.3. Metric Units
+
+ A sequence of pairs; the elements of each pair are:
+
+ o T, a time
+
+ o Type-P-one-way-packet-arrival-count for the packet sent at T.
+
+4.2.4. Definition
+
+ At time Ts, we start sending packets with a constant-rate lambda,
+ until time Tf. For each packet sent, we obtain the value of Type-P-
+ one-way-packet-arrival-count. The value of the sample is the
+ sequence made up of the resulting {time, duplication} pairs. If
+ there are no such pairs, the sequence is of length zero and the
+ sample is said to be empty.
+
+4.2.5. Methodology
+
+ Refer to Section 4.5 of [RFC3432].
+
+4.2.6. Errors and uncertainties
+
+ Refer to Section 4.6 of [RFC3432].
+
+
+
+
+
+Uijterwaal Standards Track [Page 9]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+4.2.7. Reporting the metric
+
+ Refer to Section 4.7 of [RFC3432].
+
+5. Some Statistics Definitions for One-Way Duplication
+
+ Note: the statistics described in this section can be used for both
+ Type-P-one-way-Packet-Duplication-Poisson-Stream and Type-P-one-way-
+ Packet-Duplication-Periodic-Stream. The application SHOULD report
+ which sample was used as input.
+
+5.1. Type-P-one-way-packet-duplication-fraction
+
+ This statistic gives the fraction of additional packets that arrived
+ in a stream.
+
+ Given a Type-P-one-way-Packet-Duplication-Poisson-Stream, one first
+ removes all values of Type-P-one-way-Packet-Duplication that are
+ undefined. For the remaining pairs in the stream, one calculates:
+ (Sum Type-P-one-way-packet-arrival-count/Number of pairs left) - 1
+ (In other words, (number of packets received)/(number of packets sent
+ and not lost).)
+
+ The number can be expressed as a percentage.
+
+ Note: this statistic is the equivalent to the Y.1540 IPDR [Y1540].
+
+5.2. Type-P-one-way-replicated-packet-rate
+
+ This statistic gives the fraction of packets that was duplicated (one
+ or more times) in a stream.
+
+ Given a Type-P-one-way-Packet-Duplication-Poisson-Stream, one first
+ removes all values of Type-P-one-way-packet-arrival-count that are
+ undefined. For the remaining pairs in the stream, one counts the
+ number of pairs with Type-P-one-way-packet-arrival-count greater than
+ 1. Then, one calculates the fraction of packets that meet this
+ criterion as a fraction of the total. (In other words: (number of
+ duplicated packets)/(number of packets sent and not lost).)
+
+ The number can be expressed as a percentage.
+
+ Note: this statistic is the equivalent of the Y.1540 RIPR [Y1540].
+
+
+
+
+
+
+
+
+Uijterwaal Standards Track [Page 10]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+5.3. Examples
+
+ Consider a stream of 4 packets, sent as:
+
+ (1, 2, 3, 4)
+
+ and arriving as:
+
+ o Case 1: (1, 2, 3, 4)
+
+ o Case 2: (1, 1, 2, 2, 3, 3, 4, 4)
+
+ o Case 3: (1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 4)
+
+ o Case 4: (1, 1, 1, 2, 3, 3, 3, 4)
+
+ Case 1: No packets are duplicated in a stream, and both the Type-P-
+ one-way-packet-duplication-fraction and the Type-P-one-way-packet-
+ replicated-packet-rate are 0.
+
+ Case 2: Every packet is duplicated once, and the Type-P-one-way-
+ packet-duplication-fraction is 100%. The Type-P-one-way-replicated-
+ packet-rate is 100%, too.
+
+ Case 3: Every packet is duplicated twice, so the Type-P-one-way-
+ packet-duplication-fraction is 200%. The Type-P-one-way-replicated-
+ packet-rate is still 100%.
+
+ Case 4: Half the packets are duplicated twice and the other half are
+ not duplicated. The Type-P-one-way-packet-duplication-fraction is
+ again 100%, and this number does not show the difference with case 2.
+ However, the Type-P-one-way-packet-replicated-packet-rate is 50% in
+ this case and 100% in case 2.
+
+ However, the Type-P-one-way-packet-duplication-rate will not show the
+ difference between cases 2 and 3. For this, one has to look at the
+ Type-P-one-way-packet-duplication-fraction.
+
+ Finally, note that the order in which the packets arrived does not
+ affect the results. For example, these variations of case 2:
+
+ o Case 2a: (1, 1, 2, 2, 3, 3, 4, 4)
+
+ o Case 2b: (1, 2, 3, 4, 1, 2, 3, 4)
+
+ o Case 2c: (1, 2, 3, 4, 4, 3, 2, 1)
+
+
+
+
+
+Uijterwaal Standards Track [Page 11]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+ (as well as any other permutation) all yield the same results for
+ Type-P-one-way-packet-duplication-fraction and the Type-P-one-way-
+ replicated-packet-rate.
+
+6. Security Considerations
+
+ Conducting Internet measurements raises both security and privacy
+ concerns. This memo does not specify an implementation of the
+ metrics, so it does not directly affect the security of the Internet
+ nor of applications that run on the Internet. However,
+ implementations of these metrics must be mindful of security and
+ privacy concerns.
+
+ There are two types of security concerns: potential harm caused by
+ the measurements and potential harm to the measurements. The
+ measurements could cause harm because they are active, and they
+ inject packets into the network. The measurement parameters MUST be
+ carefully selected so that the measurements inject trivial amounts of
+ additional traffic into the networks they measure. If they inject
+ "too much" traffic, they can skew the results of the measurement, and
+ in extreme cases, cause congestion and denial of service.
+
+ The measurements themselves could be harmed by routers giving
+ measurement traffic a different priority than "normal" traffic or by
+ an attacker injecting artificial measurement traffic. If routers can
+ recognize measurement traffic and treat it separately, the
+ measurements will not reflect actual user traffic. If an attacker
+ injects artificial traffic that is accepted as legitimate, the loss
+ rate will be artificially lowered. Therefore, the measurement
+ methodologies SHOULD include appropriate techniques to reduce the
+ probability that measurement traffic can be distinguished from
+ "normal" traffic. Authentication techniques, such as digital
+ signatures, may be used where appropriate to guard against injected
+ traffic attacks.
+
+ The privacy concerns of network measurement are limited by the active
+ measurements described in this memo. Unlike passive measurements,
+ there can be no release of existing user data.
+
+7. IANA Considerations
+
+ IANA has registered the metrics defined in this document in the IP
+ Performance Metrics (IPPM) Metrics Registry, see [RFC4148].
+
+
+
+
+
+
+
+
+Uijterwaal Standards Track [Page 12]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+8. Acknowledgements
+
+ The idea to write this document came up in a meeting with Al Morton,
+ Stanislav Shalunov, Emile Stephan, and the author on the IPPM
+ reporting document.
+
+ This document relies heavily on [RFC2680], and the author would like
+ to thank the authors of that document for writing it.
+
+ Finally, thanks are due to Lars Eggert, Al Morton, Martin Swany, and
+ Matt Zekauskas for their comments.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+ Packet Loss Metric for IPPM", RFC 2680, September 1999.
+
+ [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
+ performance measurement with periodic streams", RFC 3432,
+ November 2002.
+
+9.2. Informative References
+
+ [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+ "Framework for IP Performance Metrics", RFC 2330,
+ May 1998.
+
+ [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
+ Registry", BCP 108, RFC 4148, August 2005.
+
+ [Y1540] "Y.1540 ITU-T Recommendation Y.1540 (2007), Internet
+ protocol data communication service IP packet transfer and
+ availability performance parameters.", 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Uijterwaal Standards Track [Page 13]
+
+RFC 5560 Packet Duplication Metric May 2009
+
+
+Author's Address
+
+ Henk Uijterwaal
+ RIPE NCC
+ Singel 258
+ 1016 AB Amsterdam
+ The Netherlands
+
+ Phone: +31 20 535 4444
+ EMail: henk@ripe.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Uijterwaal Standards Track [Page 14]
+