idnits 2.17.1 draft-ietf-ippm-duplicate-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 412. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2007) is 6220 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Uijterwaal 3 Internet-Draft RIPE NCC 4 Intended status: Standards Track April 2007 5 Expires: October 3, 2007 7 A One-Way Packet Duplication Metric for IPPM 8 draft-ietf-ippm-duplicate-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 3, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The IETF IPPM working group has defined a metric for packet loss. 42 The packet loss metric quantifies the case where a packet that is 43 sent, never arrives at its destination. However, the opposite is 44 also possible: a packet is sent and arrives more than once. This 45 document defines a metric to quantify these kinds of events. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 51 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. A Singleton Definition for One-Way Packet Duplication . . . . 3 53 2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 4 55 2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.6. Methodology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.7. Errors and uncertainties . . . . . . . . . . . . . . . . . 4 60 2.8. Reporting the metric . . . . . . . . . . . . . . . . . . . 5 61 3. A definition for Samples of One-way Packet Duplication . . . . 5 62 3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.5. Methodology . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.6. Errors and uncertainties . . . . . . . . . . . . . . . . . 5 68 3.7. Reporting the metric . . . . . . . . . . . . . . . . . . . 6 69 4. Some statistics definitions for One-way Duplication . . . . . 6 70 4.1. Type-P-one-way-packet-duplication-average . . . . . . . . 6 71 4.2. Type-P-one-way-packet-duplication-rate . . . . . . . . . . 6 72 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 6. Relation with Y.1540 . . . . . . . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 Intellectual Property and Copyright Statements . . . . . . . . . . 10 83 1. Introduction 85 This document defines a metric for one-way packet duplication across 86 Internet paths. It builds on the IPPM Framework document [RFC2330]; 87 the reader is assumed to be familiar with that document. 89 This document follows the same structure as the document for One-way 90 Packet Loss [RFC2680]; the reader is assumed to be familiar with that 91 document as well. 93 The structure of this memo is as follows: 94 o First, a singleton metric, called Type-P-One-way-packet- 95 duplication, is introduced to describe a single instance of packet 96 duplication. 97 o Then, this singleton metric is used to define a sample, Type-P- 98 One-way-Packet-Duplication-Poisson-Stream, is introduced to 99 measure duplication in a series of packets sent. 100 o Finally, a method to summarise the properties of this sample is 101 introduced. 103 1.1. Requirements notation 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 1.2. Motivation 111 The IETF IPPM working group has defined a metric for packet loss 112 [RFC2680]. The packet loss metric quantifies the case where a packet 113 that is sent, never arrives at its destination. However, the 114 opposite is also possible: a packet is sent and arrives more than 115 once. This document defines a metric to quantify these kinds of 116 events. 118 As this document describes a case similar to the one discussed in 119 [RFC2680], all considerations from that document on timing and 120 accuracy apply. 122 2. A Singleton Definition for One-Way Packet Duplication 124 2.1. Metric Name 126 Type-P-One-way-Packet-Duplication 128 2.2. Metrics Parameters 130 o Src, the IP address of a host 131 o Dst, the IP address of a host 132 o T, a time 133 o T0, a time 135 2.3. Metric Units 137 A positive integer number 139 2.4. Definition 141 The value of a Type-P-One-way-Packet-Duplication is a positive 142 integer number indicating the number of (uncorrupted and identical) 143 copies received by dst in the interval [T, T+T0] for a packet sent by 144 src at time T. 146 If a packet is sent, but it is lost or does not arrive in the 147 interval [T, T+T0], then the metric is undefined. 149 2.5. Discussion 151 This metric counts the number of packets arriving for each packet 152 sent. The time-out value T0 SHOULD be set to a value when the 153 application could potentially still use the packet and not discard it 154 automatically. 156 The metric only counts packets that are not corrupted during 157 transmission and may have been resent automatically by lower layers 158 or intermediate devices. Packets that were corrupted during 159 transmission but nevertheless still arrived at dst are not counted. 161 If a packet is fragmented and one of the fragments arrives more than 162 once, then the packet is counted as duplicated. 164 2.6. Methodology 166 Refer to section 2.6 of [RFC2680] (We may cut and paste relevant text 167 into this document later). 169 2.7. Errors and uncertainties 171 Refer to section 2.7 of [RFC2680] (We may cut and paste relevant text 172 into this document later). 174 2.8. Reporting the metric 176 Refer to section 2.8 of [RFC2680] (We may cut and paste relevant text 177 into this document later). 179 3. A definition for Samples of One-way Packet Duplication 181 3.1. Metric Name 183 Type-P-One-way-Packet-Duplication-Poisson-Stream 185 3.2. Metric Parameters 187 o Src, the IP address of a host 188 o Dst, the IP address of a host 189 o Ts, a time 190 o T0, a time 191 o Tf, a time 192 o lamba, a rate in reciprocal seconds 194 3.3. Metric Units 196 A sequence of pairs; the elements of each pair are: 197 o T, a time 198 o Type-P-One-way-Packet-Duplication for the packet sent at T. 200 3.4. Definition 202 Given Ts, Tf and lambda, we compute a pseudo-random Poisson process 203 beginning at or before Ts, with average rate lambda and ending at or 204 after Tf. Those time values greater than or equal to Ts, and less 205 than or equal to Tf are then selected. At each of the times in this 206 process, we obtain the value of Type-P-One-way-Packet-Duplication. 207 the value of the sample is the sequence made up of the resulting 208 {time, duplication} pairs. If there are no such pairs, the sequence 209 is of length zero and the sample is said to be empty. 211 3.5. Methodology 213 Refer to [RFC2680] 215 3.6. Errors and uncertainties 217 Refer to [RFC2680] 219 3.7. Reporting the metric 221 Refer to [RFC2680] 223 4. Some statistics definitions for One-way Duplication 225 4.1. Type-P-one-way-packet-duplication-average 227 This statistics gives an estimate of the fraction of additional 228 packets that arrived in a stream. 230 Given a Type-P-One-way-Packet-Duplication-Poisson-Stream, one first 231 removes all values of Type-P-One-way-Packet-Duplication which are 232 undefined. For the remaining pairs in the stream, one calculates: 233 (Sum Type-P-One-Way-Packet-Duplication/Number of pairs left) - 1 (In 234 other words, #packets received/(#sent and not lost).) 236 The number can be expressed as a percentage. 238 Note: this statistics is the equivalent of the Y.1540 IPDR [Y1540] 240 4.2. Type-P-one-way-packet-duplication-rate 242 This statistics gives an estimate of the fraction of packets that was 243 duplicated (one or more times) in a stream. 245 Given a Type-P-One-way-Packet-Duplication-Poisson-Stream, one first 246 removes all values of Type-P-One-way-Packet-Duplication which are 247 undefined. For the remaining pairs in the stream, one counts the 248 number of pairs with Type-P-One-Way-Packet-Duplication greater than 249 1. Then one calculates the fraction of packets that meet this 250 criterium as a fraction of the total. (In other words: # with 251 duplication/(#sent and not lost).). 253 The number can be expressed as a percentage. 255 Note: this statistics is the equivalent of the Y.1540 RIPR [Y1540] 257 4.3. Examples 259 Consider a stream of 4 packets, sent as: 261 (1, 2, 3, 4) 263 and arriving as: 265 o Case 1: (1, 2, 3, 4) 266 o Case 2: (1, 1, 2, 2, 3, 3, 4, 4) 267 o Case 3: (1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 4) 268 o Case 4: (1, 1, 1, 2, 3, 3, 3, 4) 270 Case 1: No packets are duplicated in a stream and both the Type-P- 271 one-way-packet-duplication-average and the type-P-one-way-packet- 272 duplication-rate are 0. 274 Case 2: Every packet is duplicated once and the Type-P-one-way- 275 packet-duplication-average is 100%. The type-P-one-way-packet- 276 duplication-rate is 100% too. 278 Case 3: Every packet is duplicated twice, so the Type-P-one-way- 279 packet-duplication-average is 200%. The type-P-one-way-packet- 280 duplication-rate is still 100%. 282 Case 4: Half the packets are duplicated twice and the other half are 283 not duplicated. The Type-P-one-way-packet-duplication-average is 284 again 100% and this number does not show the difference with case 2. 285 However, the type-P-one-way-packet-duplication-rate is 50% in this 286 case and 100% in case 2. 288 However, the type-P-one-way-packet-duplication-rate will not show the 289 difference between case 2 and 3. For this, one has to look at the 290 Type-P-one-way-packet-duplication-average. 292 5. Security Considerations 294 Conducting Internet measurements raises both security and privacy 295 concerns. This memo does not specify an implementation of the 296 metrics, so it does not directly affect the security of the Internet 297 nor of applications which run on the Internet. However, 298 implementations of these metrics must be mindful of security and 299 privacy concerns. 301 There are two types of security concerns: potential harm caused by 302 the measurements, and potential harm to the measurements. The 303 measurements could cause harm because they are active, and inject 304 packets into the network. The measurement parameters MUST be 305 carefully selected so that the measurements inject trivial amounts of 306 additional traffic into the networks they measure. If they inject 307 "too much" traffic, they can skew the results of the measurement, and 308 in extreme cases cause congestion and denial of service. 310 The measurements themselves could be harmed by routers giving 311 measurement traffic a different priority than "normal" traffic, or by 312 an attacker injecting artificial measurement traffic. If routers can 313 recognize measurement traffic and treat it separately, the 314 measurements will not reflect actual user traffic. If an attacker 315 injects artificial traffic that is accepted as legitimate, the loss 316 rate will be artificially lowered. Therefore, the measurement 317 methodologies SHOULD include appropriate techniques to reduce the 318 probability measurement traffic can be distinguished from "normal" 319 traffic. Authentication techniques, such as digital signatures, may 320 be used where appropriate to guard against injected traffic attacks. 322 The privacy concerns of network measurement are limited by the active 323 measurements described in this memo. Unlike passive measurements, 324 there can be no release of existing user data. 326 6. Relation with Y.1540 328 Do we need this? 330 7. IANA Considerations 332 This document makes no requests from the IANA. This section can be 333 removed upon publication as a RFC. 335 8. Acknowledgements 337 The idea to write this draft came up in a meeting with Al Morton, 338 Stanislav Shalunov, Emile Stephan and the author. 340 This document relies heavily on [RFC2680] and the author likes to 341 thank the authors of that document for writing it. 343 Finally, thanks are due to ... for their comments. 345 9. References 347 9.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 9.2. Informative References 354 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 355 "Framework for IP Performance Metrics", RFC 2330, 356 May 1998. 358 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 359 Packet Loss Metric for IPPM", RFC 2680, September 1999. 361 [Y1540] A. Morton, "Y.1540", July 2003. 363 Author's Address 365 Henk Uijterwaal 366 RIPE NCC 367 Singel 258 368 1016 AB Amsterdam 369 The Netherlands 371 Phone: +31 20 535 4444 372 Email: henk@ripe.net 374 Full Copyright Statement 376 Copyright (C) The IETF Trust (2007). 378 This document is subject to the rights, licenses and restrictions 379 contained in BCP 78, and except as set forth therein, the authors 380 retain all their rights. 382 This document and the information contained herein are provided on an 383 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 384 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 385 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 386 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 387 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 388 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 390 Intellectual Property 392 The IETF takes no position regarding the validity or scope of any 393 Intellectual Property Rights or other rights that might be claimed to 394 pertain to the implementation or use of the technology described in 395 this document or the extent to which any license under such rights 396 might or might not be available; nor does it represent that it has 397 made any independent effort to identify any such rights. Information 398 on the procedures with respect to rights in RFC documents can be 399 found in BCP 78 and BCP 79. 401 Copies of IPR disclosures made to the IETF Secretariat and any 402 assurances of licenses to be made available, or the result of an 403 attempt made to obtain a general license or permission for the use of 404 such proprietary rights by implementers or users of this 405 specification can be obtained from the IETF on-line IPR repository at 406 http://www.ietf.org/ipr. 408 The IETF invites any interested party to bring to its attention any 409 copyrights, patents or patent applications, or other proprietary 410 rights that may cover technology that may be required to implement 411 this standard. Please address the information to the IETF at 412 ietf-ipr@ietf.org. 414 Acknowledgment 416 Funding for the RFC Editor function is provided by the IETF 417 Administrative Support Activity (IASA).