--- 1/draft-ietf-ippm-duplicate-04.txt 2008-10-07 11:12:23.000000000 +0200 +++ 2/draft-ietf-ippm-duplicate-05.txt 2008-10-07 11:12:23.000000000 +0200 @@ -1,18 +1,18 @@ Network Working Group H. Uijterwaal Internet-Draft RIPE NCC - -Expires: January 2, 2009 +Intended status: Standards Track October 7, 2008 +Expires: April 10, 2009 A One-Way Packet Duplication Metric - draft-ietf-ippm-duplicate-04.txt + draft-ietf-ippm-duplicate-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -23,21 +23,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 2, 2009. + This Internet-Draft will expire on April 10, 2009. 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 has been defined. This metric quantifies the case where a packet that is sent, does not @@ -58,47 +58,47 @@ 2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Methodology . . . . . . . . . . . . . . . . . . . . . . . 6 2.7. Errors and uncertainties . . . . . . . . . . . . . . . . . 7 2.8. Reporting the metric . . . . . . . . . . . . . . . . . . . 7 3. A Singleton Definition for one-way packet duplication . . . . 7 3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 7 3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definition for samples for one-way Packet Duplication . . . . 8 4.1. Poisson Streams . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Metric Name . . . . . . . . . . . . . . . . . . . . . 8 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.1.5. Methodology . . . . . . . . . . . . . . . . . . . . . 9 + 4.1.6. Errors and uncertainties . . . . . . . . . . . . . . . 9 + 4.1.7. Reporting the metric . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 9 - 5. Some statistics definitions for one-way Duplication . . . . . 9 + 4.2.6. Errors and uncertainties . . . . . . . . . . . . . . . 10 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 1. Introduction This document defines a metric for one-way packet duplication across Internet paths. It builds on the IPPM Framework document [RFC2330]; the reader is assumed to be familiar with that document. @@ -214,29 +214,34 @@ If this metrics is used in parallel with the Packet Loss Metric [RFC2680], the value of T0 should 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. - Because of the definition of duplication (identical information - fields), active measurement systems MUST NOT send multiple packets - with identical information fields, in order to avoid that all packets - will be declared duplicates. - 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 labelled 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 is acceptable. + 2.6. Methodology The basic technique to measure this metrics follows the methodology described in [RFC2680], section 2.6, 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 to receive multiple copies. @@ -505,22 +510,22 @@ 8. Acknowledgements The idea to write this draft came up in a meeting with Al Morton, Stanislav Shalunov, Emile Stephan and the author, on the IPPM reporting draft. This document relies heavily on [RFC2680] and the author likes to thank the authors of that document for writing it. - Finally, thanks are due to Al Morton, Martin Swany and Matt Zekauskas - for their comments. + 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.