draft-ietf-ippm-duplicate-05.txt   draft-ietf-ippm-duplicate-06.txt 
Network Working Group H. Uijterwaal Network Working Group H. Uijterwaal
Internet-Draft RIPE NCC Internet-Draft RIPE NCC
Intended status: Standards Track October 7, 2008 Intended status: Standards Track December 9, 2008
Expires: April 10, 2009 Expires: June 12, 2009
A One-Way Packet Duplication Metric A One-Way Packet Duplication Metric
draft-ietf-ippm-duplicate-05.txt draft-ietf-ippm-duplicate-06.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 April 10, 2009. This Internet-Draft will expire on June 12, 2009.
Abstract Abstract
When a packet is sent from one host to the other, one normally 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 expects that exactly one copy of the packet that was sent arrives at
the destination. It is, however, possible that a packet is either the destination. It is, however, possible that a packet is either
lost or that multiple copies arrive. lost or that multiple copies arrive.
In earlier work a metric for packet loss has been defined. This In earlier work a metric for packet loss has been defined. This
metric quantifies the case where a packet that is sent, does not metric quantifies the case where a packet that is sent, does not
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
2. A Singleton Definition for one-way packet arrival count . . . 5 2. A Singleton Definition for one-way packet arrival count . . . 5
2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 5 2.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 5
2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Methodology . . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Methodology . . . . . . . . . . . . . . . . . . . . . . . 7
2.7. Errors and uncertainties . . . . . . . . . . . . . . . . . 7 2.7. Errors and uncertainties . . . . . . . . . . . . . . . . . 7
2.8. Reporting the metric . . . . . . . . . . . . . . . . . . . 7 2.8. Reporting the metric . . . . . . . . . . . . . . . . . . . 7
3. A Singleton Definition for one-way packet duplication . . . . 7 3. A Singleton Definition for one-way packet duplication . . . . 7
3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 7 3.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 7
3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Definition for samples for one-way Packet Duplication . . . . 8 4. Definition for samples for one-way Packet Duplication . . . . 8
4.1. Poisson Streams . . . . . . . . . . . . . . . . . . . . . 8 4.1. Poisson Streams . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 6, line 49 skipping to change at page 6, line 49
If this metric is used in an active measurement system, the system If this metric is used in an active measurement system, the system
MUST NOT send multiple packets with identical information fields, in MUST NOT send multiple packets with identical information fields, in
order to avoid that all packets will be declared duplicates. This order to avoid that all packets will be declared duplicates. This
metric can be used inside a passive measurement system as well, using metric can be used inside a passive measurement system as well, using
packets generated by another source. However, if the source can send packets generated by another source. However, if the source can send
two identical packets within the interval [T, T+T0], this will be two identical packets within the interval [T, T+T0], this will be
incorrectly labelled as a duplicate, resulting in a false positive. incorrectly labelled as a duplicate, resulting in a false positive.
It is up to the implementor to estimate if this scenario is likely to It is up to the implementor to estimate if this scenario is likely to
happen and the rate of false positives is acceptable. 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 2.6. Methodology
The basic technique to measure this metrics follows the methodology The basic technique to measure this metrics follows the methodology
described in [RFC2680], section 2.6, with one exception. described in [RFC2680], section 2.6, with one exception.
[RFC2680] does not specify that the receiving host should be able to [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 receive multiple copies of a single packet, as it only needs one copy
to determine the metrics. Implementations for this metric should to determine the metrics. Implementations for this metric should
obviously be capable to receive multiple copies. obviously be capable to receive multiple copies.
skipping to change at page 9, line 51 skipping to change at page 9, line 51
At time Ts, we start sending packets with a constant rate lambda, 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- 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 one-way-packet-arrival-count. The value of the sample is the
sequence made up of the resulting {time, duplication} pairs. If sequence made up of the resulting {time, duplication} pairs. If
there are no such pairs, the sequence is of length zero and the there are no such pairs, the sequence is of length zero and the
sample is said to be empty. sample is said to be empty.
4.2.5. Methodology 4.2.5. Methodology
Refer to [RFC2680], section 4.5. Refer to [RFC3432], section 4.5.
4.2.6. Errors and uncertainties 4.2.6. Errors and uncertainties
Refer to [RFC2680], section 4.6. Refer to [RFC3432], section 4.6.
4.2.7. Reporting the metric 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 5. Some statistics definitions for one-way Duplication
Note: the statistics described in this section can be used for both 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- Type-P-one-way-Packet-Duplication-Poisson-Stream and Type-P-one-way-
Packet-Duplication-Periodic-Stream. The application SHOULD report Packet-Duplication-Periodic-Stream. The application SHOULD report
which sample was used as input. which sample was used as input.
5.1. Type-P-one-way-packet-duplication-fraction 5.1. Type-P-one-way-packet-duplication-fraction
 End of changes. 8 change blocks. 
8 lines changed or deleted 12 lines changed or added

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