draft-ietf-ippm-duplicate-00.txt   draft-ietf-ippm-duplicate-01.txt 
Network Working Group H. Uijterwaal Network Working Group H. Uijterwaal
Internet-Draft RIPE NCC Internet-Draft RIPE NCC
Intended status: Standards Track April 17, 2007
Expires: October 19, 2007 Expires: October 3, 2007
A One-Way Packet Duplication Metric for IPPM A One-Way Packet Duplication Metric for IPPM
draft-ietf-ippm-duplicate-00.txt draft-ietf-ippm-duplicate-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 19, 2007. This Internet-Draft will expire on October 3, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The IETF IPPM working group has defined a metric for packet loss. The IETF IPPM working group has defined a metric for packet loss.
The packet loss metric quantifies the case where a packet that is The packet loss metric quantifies the case where a packet that is
sent, never arrives at its destination. However, the opposite is sent, never arrives at its destination. However, the opposite is
also possible: a packet is sent and arrives more than once. This also possible: a packet is sent and arrives more than once. This
document defines a metric to quantify these kinds of events. document defines a metric to quantify these kinds of events.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Singleton Definition for One-Way Packet Duplication . . . . . 3 2. A Singleton Definition for One-Way Packet Duplication . . . . 3
2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 4 2.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 4
2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4 2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6. Methodology . . . . . . . . . . . . . . . . . . . . . . . . 4 2.6. Methodology . . . . . . . . . . . . . . . . . . . . . . . 4
2.7. Errors and uncertainties . . . . . . . . . . . . . . . . . 4 2.7. Errors and uncertainties . . . . . . . . . . . . . . . . . 4
2.8. Reporting the metric . . . . . . . . . . . . . . . . . . . 5 2.8. Reporting the metric . . . . . . . . . . . . . . . . . . . 5
3. A definition for Samples of One-way Packet Duplication . . . . 5 3. A definition for Samples of One-way Packet Duplication . . . . 5
3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . . 5 3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 5
3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Methodology . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. Methodology . . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Errors and uncertainties . . . . . . . . . . . . . . . . . 5 3.6. Errors and uncertainties . . . . . . . . . . . . . . . . . 5
3.7. Reporting the metric . . . . . . . . . . . . . . . . . . . 6 3.7. Reporting the metric . . . . . . . . . . . . . . . . . . . 6
4. Some statistics definitions for One-way Duplication . . . . . . 6 4. Some statistics definitions for One-way Duplication . . . . . 6
4.1. Type-P-one-way-packet-duplication-average . . . . . . . . . 6 4.1. Type-P-one-way-packet-duplication-average . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4.2. Type-P-one-way-packet-duplication-rate . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Relation with Y.1540 . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
This document defines a metric for one-way packet duplication across This document defines a metric for one-way packet duplication across
Internet paths. It builds on the IPPM Framework document [RFC2330]; Internet paths. It builds on the IPPM Framework document [RFC2330];
the reader is assumed to be familiar with that document. the reader is assumed to be familiar with that document.
This document follows the same structure as the document for One-way This document follows the same structure as the document for One-way
Packet Loss [RFC2680]; the reader is assumed to be familiar with that Packet Loss [RFC2680]; the reader is assumed to be familiar with that
document as well. document as well.
skipping to change at page 6, line 14 skipping to change at page 6, line 14
3.7. Reporting the metric 3.7. Reporting the metric
Refer to [RFC2680] Refer to [RFC2680]
4. Some statistics definitions for One-way Duplication 4. Some statistics definitions for One-way Duplication
4.1. Type-P-one-way-packet-duplication-average 4.1. Type-P-one-way-packet-duplication-average
This statistics gives an estimate of the fraction of additional This statistics gives an estimate of the fraction of additional
packets that arrives for every packet that was sent. packets that arrived in a stream.
Given a Type-P-One-way-Packet-Duplication-Poisson-Stream, one first Given a Type-P-One-way-Packet-Duplication-Poisson-Stream, one first
removes all values of Type-P-One-way-Packet-Duplication which are removes all values of Type-P-One-way-Packet-Duplication which are
undefined. For the remaining pairs in the stream, one calculates: undefined. For the remaining pairs in the stream, one calculates:
(Sum Type-P-One-Way-Packet-Duplication/Number of pairs left) - 1 (In (Sum Type-P-One-Way-Packet-Duplication/Number of pairs left) - 1 (In
other words, #packets received/(#sent and not lost).) other words, #packets received/(#sent and not lost).)
The number can be expressed as a percentage. The number can be expressed as a percentage.
For example, 0% indicates that no duplication occurred in the sample. Note: this statistics is the equivalent of the Y.1540 IPDR [Y1540]
A value of 100% indicates that every packet was duplicated once, a
value of 200% indicates that every packet was duplicated twice. Note 4.2. Type-P-one-way-packet-duplication-rate
that a value of 100% can also be obtained if half the packets are
duplicated twice and the other half not. The statistics cannot show This statistics gives an estimate of the fraction of packets that was
this difference, if it is relevant for the application, one will have duplicated (one or more times) in a stream.
to examine the sample.
Given a Type-P-One-way-Packet-Duplication-Poisson-Stream, one first
removes all values of Type-P-One-way-Packet-Duplication which are
undefined. For the remaining pairs in the stream, one counts the
number of pairs with Type-P-One-Way-Packet-Duplication greater than
1. Then one calculates the fraction of packets that meet this
criterium as a fraction of the total. (In other words: # with
duplication/(#sent and not lost).).
The number can be expressed as a percentage.
Note: this statistics is the equivalent of the Y.1540 RIPR [Y1540]
4.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-average and the type-P-one-way-packet-
duplication-rate are 0.
Case 2: Every packet is duplicated once and the Type-P-one-way-
packet-duplication-average is 100%. The type-P-one-way-packet-
duplication-rate is 100% too.
Case 3: Every packet is duplicated twice, so the Type-P-one-way-
packet-duplication-average is 200%. The type-P-one-way-packet-
duplication-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-average is
again 100% and this number does not show the difference with case 2.
However, the type-P-one-way-packet-duplication-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 case 2 and 3. For this, one has to look at the
Type-P-one-way-packet-duplication-average.
5. Security Considerations 5. Security Considerations
Conducting Internet measurements raises both security and privacy Conducting Internet measurements raises both security and privacy
concerns. This memo does not specify an implementation of the concerns. This memo does not specify an implementation of the
metrics, so it does not directly affect the security of the Internet metrics, so it does not directly affect the security of the Internet
nor of applications which run on the Internet. However, nor of applications which run on the Internet. However,
implementations of these metrics must be mindful of security and implementations of these metrics must be mindful of security and
privacy concerns. privacy concerns.
skipping to change at page 7, line 19 skipping to change at page 8, line 18
rate will be artificially lowered. Therefore, the measurement rate will be artificially lowered. Therefore, the measurement
methodologies SHOULD include appropriate techniques to reduce the methodologies SHOULD include appropriate techniques to reduce the
probability measurement traffic can be distinguished from "normal" probability measurement traffic can be distinguished from "normal"
traffic. Authentication techniques, such as digital signatures, may traffic. Authentication techniques, such as digital signatures, may
be used where appropriate to guard against injected traffic attacks. be used where appropriate to guard against injected traffic attacks.
The privacy concerns of network measurement are limited by the active The privacy concerns of network measurement are limited by the active
measurements described in this memo. Unlike passive measurements, measurements described in this memo. Unlike passive measurements,
there can be no release of existing user data. there can be no release of existing user data.
6. IANA Considerations 6. Relation with Y.1540
Do we need this?
7. IANA Considerations
This document makes no requests from the IANA. This section can be This document makes no requests from the IANA. This section can be
removed upon publication as a RFC. removed upon publication as a RFC.
7. Acknowledgements 8. Acknowledgements
The idea to write this draft came up in a meeting with Al Morton, The idea to write this draft came up in a meeting with Al Morton,
Stanislav Shalunov, Emile Stephan and the author. Stanislav Shalunov, Emile Stephan and the author.
This document relies heavily on [RFC2680] and the author likes to This document relies heavily on [RFC2680] and the author likes to
thank the authors of that document for writing it. thank the authors of that document for writing it.
Finally, thanks are due to ... for their comments. Finally, thanks are due to ... for their comments.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 9.2. Informative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
May 1998. May 1998.
[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.
[Y1540] A. Morton, "Y.1540", July 2003.
Author's Address Author's Address
Henk Uijterwaal Henk Uijterwaal
RIPE NCC RIPE NCC
Singel 258 Singel 258
1016 AB Amsterdam 1016 AB Amsterdam
The Netherlands The Netherlands
Phone: +31 20 535 4444 Phone: +31 20 535 4444
Email: henk@ripe.net Email: henk@ripe.net
 End of changes. 17 change blocks. 
34 lines changed or deleted 89 lines changed or added

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