--- 1/draft-ietf-ippm-duplicate-05.txt 2008-12-09 14:12:03.000000000 +0100 +++ 2/draft-ietf-ippm-duplicate-06.txt 2008-12-09 14:12:03.000000000 +0100 @@ -1,18 +1,18 @@ Network Working Group H. Uijterwaal Internet-Draft RIPE NCC -Intended status: Standards Track October 7, 2008 -Expires: April 10, 2009 +Intended status: Standards Track December 9, 2008 +Expires: June 12, 2009 A One-Way Packet Duplication Metric - draft-ietf-ippm-duplicate-05.txt + draft-ietf-ippm-duplicate-06.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 April 10, 2009. + This Internet-Draft will expire on June 12, 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 @@ -50,21 +50,21 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 2. A Singleton Definition for one-way packet arrival count . . . 5 2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 5 2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.6. Methodology . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.6. Methodology . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definition for samples for one-way Packet Duplication . . . . 8 4.1. Poisson Streams . . . . . . . . . . . . . . . . . . . . . 8 @@ -228,20 +228,24 @@ 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. + In IPv4, "information fields" refers to all data following the IPv4 + header. The equivalent of this in IPv6 is all information following + the IPv6 header and the hop-by-hop options header. + 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. @@ -368,29 +372,29 @@ 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 [RFC2680], section 4.5. + Refer to [RFC3432], section 4.5. 4.2.6. Errors and uncertainties - Refer to [RFC2680], section 4.6. + Refer to [RFC3432], section 4.6. 4.2.7. Reporting the metric - Refer to [RFC2680], section 4.7. + Refer to [RFC3432], section 4.7. 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