idnits 2.17.1 draft-ietf-ippm-duplicate-02.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 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 553. 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 (August 6, 2007) is 6080 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) -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 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 August 6, 2007 5 Expires: February 7, 2008 7 A One-Way Packet Duplication Metric for IPPM 8 draft-ietf-ippm-duplicate-02.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 February 7, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 When a packet is sent from one host to the other, one normally 42 expects that exactly one copy of the packet that was sent arrives at 43 the destination. It is, however, possible that a packet is either 44 lost or that multiple copies arrive. 46 In earlier work, the IPPM group defined a metric for packet loss. 47 This metric quantifies the case where a packet that is sent, never 48 arrives at its destination. In this memo, a metric for the opposite 49 case is defined: a packet is sent, but multiple copies arrive. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 55 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. A Singleton Definition for one-way packet arrival . . . . . . 5 57 2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.6. Methodology . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.7. Errors and uncertainties . . . . . . . . . . . . . . . . . 6 64 2.8. Reporting the metric . . . . . . . . . . . . . . . . . . . 6 65 3. A Singleton Definition for one-way packet duplication . . . . 6 66 3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Metrics Parameters . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4. Definition for samples for one-way Packet Duplication . . . . 7 72 4.1. Poisson Streams . . . . . . . . . . . . . . . . . . . . . 7 73 4.1.1. Metric Name . . . . . . . . . . . . . . . . . . . . . 7 74 4.1.2. Metric Parameters . . . . . . . . . . . . . . . . . . 7 75 4.1.3. Metric Units . . . . . . . . . . . . . . . . . . . . . 7 76 4.1.4. Definition . . . . . . . . . . . . . . . . . . . . . . 8 77 4.1.5. Methodology . . . . . . . . . . . . . . . . . . . . . 8 78 4.1.6. Errors and uncertainties . . . . . . . . . . . . . . . 8 79 4.1.7. Reporting the metric . . . . . . . . . . . . . . . . . 8 80 4.2. Periodic Streams . . . . . . . . . . . . . . . . . . . . . 8 81 4.2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . 8 82 4.2.2. Metric Parameters . . . . . . . . . . . . . . . . . . 8 83 4.2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . 8 84 4.2.4. Definition . . . . . . . . . . . . . . . . . . . . . . 8 85 4.2.5. Methodology . . . . . . . . . . . . . . . . . . . . . 9 86 4.2.6. Errors and uncertainties . . . . . . . . . . . . . . . 9 87 4.2.7. Reporting the metric . . . . . . . . . . . . . . . . . 9 88 5. Some statistics definitions for one-way Duplication . . . . . 9 89 5.1. Type-P-one-way-packet-duplication-fraction . . . . . . . . 9 90 5.2. Type-P-one-way-replicated-packet-rate . . . . . . . . . . 9 91 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 Intellectual Property and Copyright Statements . . . . . . . . . . 13 101 1. Introduction 103 This document defines a metric for one-way packet duplication across 104 Internet paths. It builds on the IPPM Framework document [RFC2330]; 105 the reader is assumed to be familiar with that document. 107 This document follows the same structure as the document for one-way 108 Packet Loss [RFC2680]; the reader is assumed to be familiar with that 109 document as well. 111 The structure of this memo is as follows: 112 o First, a singleton metric, called Type-P-one-way-packet-arrival- 113 count, is introduced to measure the number of arriving packets for 114 each packet sent. 115 o Then, a singleton metric, called Type-P-one-way-packet- 116 duplication, is defined to describe a single instance of packet 117 duplication. 118 o Next, this singleton metric is used to define samples, Type-P-one- 119 way-Packet-Duplication-Poisson-Stream and Type-P-one-way-Packet- 120 Duplication-Periodic-Stream. These are introduced to measure 121 duplication in a series of packets sent with either Poisson- 122 distributed [RFC2680] or periodic [RFC3432] intervals between the 123 packets. 124 o Finally, a method to summarise the properties of these samples are 125 introduced. 127 1.1. Requirements notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 1.2. Motivation 135 When a packet is sent from one host to the other, one normally 136 expects that exactly one copy of the packet that was sent arrives at 137 the destination. It is, however, possible that a packet is either 138 lost or that multiple copies arrive. 140 In earlier work, the IPPM group defined a metric for packet loss 141 [RFC2680]. This metric quantifies the case where a packet that is 142 sent, never arrives at its destination. In this memo, a metric for 143 the opposite case is defined: a packet is sent, but multiple copies 144 arrive. 146 As this document describes a case similar to the one discussed in 147 [RFC2680], all considerations from that document on timing and 148 accuracy apply. 150 2. A Singleton Definition for one-way packet arrival 152 2.1. Metric Name 154 Type-P-one-way-packet-arrival-count 156 2.2. Metrics Parameters 158 o Src, the IP address of a host 159 o Dst, the IP address of a host 160 o T, a time 161 o T0, a time 163 2.3. Metric Units 165 An integer number 167 2.4. Definition 169 Two packets are considered identical when were sent by one and the 170 same host and contain identical information fields. The recipient 171 thus could take either packet and use it in an application, the other 172 copy would not contain any additional information. 174 The IP headers do not necessarily have to be identical. This can 175 happen, for example, if two packets take a different route resulting 176 in a different TTL. 178 The value of a Type-P-one-way-packet-arrival-count is a positive 179 integer number indicating the number of (uncorrupted and identical) 180 copies received by dst in the interval [T, T+T0] for a packet sent by 181 src at time T. 183 If a packet is sent, but it is lost or does not arrive in the 184 interval [T, T+T0], then the metric is undefined. Applications MAY 185 report an "impossible" value (for example, -1) to indicate this 186 condition instead of undefined. 188 If a packet is fragmented during transport and if, for whatever 189 reason, re-assembly does not occur, then the packet will be deemed 190 lost. It is thus not included in the Type-P-one-way-packet-arrival- 191 count. 193 2.5. Discussion 195 This metric counts the number of packets arriving for each packet 196 sent. The time-out value T0 SHOULD be set to a value when the 197 application could potentially still use the packet and not discard it 198 automatically. 200 The metric only counts packets that are not corrupted during 201 transmission and may have been resent automatically by lower layers 202 or intermediate devices. Packets that were corrupted during 203 transmission but nevertheless still arrived at dst are not counted. 205 Because of the definition of duplication (identical information 206 fields), active measurement systems MUST NOT send multiple packets 207 with identical information fields, in order to avoid that all packets 208 will be declared duplicates. 210 2.6. Methodology 212 The basic technique to measure this metrics follows the methodology 213 described in [RFC2680], section 2.6, with one exception. 215 [RFC2680] does specify that the receiving host should be able to 216 receive multiple copies of a single packet, as it only needs one copy 217 to determine the metrics. Implementations for this metric should 218 obviously be capable to receive multiple copies. 220 2.7. Errors and uncertainties 222 Refer to section 2.7 of [RFC2680] 224 2.8. Reporting the metric 226 Refer to section 2.8 of [RFC2680] 228 3. A Singleton Definition for one-way packet duplication 230 3.1. Metric Name 232 Type-P-one-way-packet-duplication 234 3.2. Metrics Parameters 236 o Src, the IP address of a host 237 o Dst, the IP address of a host 238 o T, a time 239 o T0, a time 241 3.3. Metric Units 243 An integer number. 245 3.4. Definition 247 The value of a Type-P-one-way-packet-duplication is a positive 248 integer number indicating the number of (uncorrupted and identical) 249 additional copies of an individual packet received by dst in the 250 interval [T, T+T0] sent by src at time T. 252 If a packet is sent and only one copy arrives in the interval [T, 253 T+T0], then the metric is 0. If no copy arrives in this interval, , 254 then the metric is undefined. Applications MAY report an 255 "impossible" value (for example, -1) to indicate this condition. 257 3.5. Discussion 259 This metric is equal to 261 Type-P-one-way-packet-arrival-count - 1 263 This metric is expected to be used for applications that need to know 264 duplication for an individual packet. All considerations regarding 265 methodology, errors and reporting from the previous section apply. 267 4. Definition for samples for one-way Packet Duplication 269 4.1. Poisson Streams 271 4.1.1. Metric Name 273 Type-P-one-way-Packet-Duplication-Poisson-Stream 275 4.1.2. Metric Parameters 277 o Src, the IP address of a host 278 o Dst, the IP address of a host 279 o Ts, a time 280 o T0, a time 281 o Tf, a time 282 o lambda, a rate in reciprocal seconds 284 4.1.3. Metric Units 286 A sequence of pairs; the elements of each pair are: 287 o T, a time 288 o Type-P-one-way-packet-arrival-count for the packet sent at T. 290 4.1.4. Definition 292 Given Ts, Tf and lambda, we compute a pseudo-random Poisson process 293 beginning at or before Ts, with average rate lambda and ending at or 294 after Tf. Those time values greater than or equal to Ts, and less 295 than or equal to Tf are then selected. At each of the times in this 296 process, we obtain the value of Type-P-one-way-packet-arrival-count. 297 The value of the sample is the sequence made up of the resulting 298 {time, duplication} pairs. If there are no such pairs, the sequence 299 is of length zero and the sample is said to be empty. 301 4.1.5. Methodology 303 Refer to [RFC2680], section 3.6. 305 4.1.6. Errors and uncertainties 307 Refer to [RFC2680], section 3.7. 309 4.1.7. Reporting the metric 311 Refer to [RFC2680], section 3.8. 313 4.2. Periodic Streams 315 4.2.1. Metric Name 317 Type-P-one-way-Packet-Duplication-Poisson-Stream 319 4.2.2. Metric Parameters 321 o Src, the IP address of a host 322 o Dst, the IP address of a host 323 o Ts, a time 324 o T0, a time 325 o Tf, a time 326 o lambda, a rate in reciprocal seconds 328 4.2.3. Metric Units 330 A sequence of pairs; the elements of each pair are: 331 o T, a time 332 o Type-P-one-way-packet-arrival-count for the packet sent at T. 334 4.2.4. Definition 336 At time Ts, we start sending packets with a constant rate lambda, 337 until time Tf. For each packet sent, we obtain the value of Type-P- 338 one-way-packet-arrival-count. The value of the sample is the 339 sequence made up of the resulting {time, duplication} pairs. If 340 there are no such pairs, the sequence is of length zero and the 341 sample is said to be empty. 343 4.2.5. Methodology 345 Refer to [RFC2680], section 4.5. 347 4.2.6. Errors and uncertainties 349 Refer to [RFC2680], section 4.6. 351 4.2.7. Reporting the metric 353 Refer to [RFC2680], section 4.7. 355 5. Some statistics definitions for one-way Duplication 357 Note: the statistics described in this section can be used for both 358 Type-P-one-way-Packet-Duplication-Poisson-Stream and Type-P-one-way- 359 Packet-Duplication-Periodic-Stream. The application SHOULD report 360 which sample was used as input. 362 5.1. Type-P-one-way-packet-duplication-fraction 364 This statistics gives the fraction of additional packets that arrived 365 in a stream. 367 Given a Type-P-one-way-Packet-Duplication-Poisson-Stream, one first 368 removes all values of Type-P-one-way-Packet-Duplication which are 369 undefined. For the remaining pairs in the stream, one calculates: 370 (Sum Type-P-one-Way-packet-arrival-count/Number of pairs left) - 1 371 (In other words, #packets received/(#sent and not lost).) 373 The number can be expressed as a percentage. 375 Note: this statistics is the equivalent of the Y.1540 IPDR [Y1540] 377 5.2. Type-P-one-way-replicated-packet-rate 379 This statistics gives the fraction of packets that was duplicated 380 (one or more times) in a stream. 382 Given a Type-P-one-way-Packet-Duplication-Poisson-Stream, one first 383 removes all values of Type-P-one-way-packet-arrival-count which are 384 undefined. For the remaining pairs in the stream, one counts the 385 number of pairs with Type-P-one-Way-packet-arrival-count greater than 386 1. Then one calculates the fraction of packets that meet this 387 criterium as a fraction of the total. (In other words: # with 388 duplication/(#sent and not lost).). 390 The number can be expressed as a percentage. 392 Note: this statistics is the equivalent of the Y.1540 RIPR [Y1540] 394 5.3. Examples 396 Consider a stream of 4 packets, sent as: 398 (1, 2, 3, 4) 400 and arriving as: 401 o Case 1: (1, 2, 3, 4) 402 o Case 2: (1, 1, 2, 2, 3, 3, 4, 4) 403 o Case 3: (1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 4) 404 o Case 4: (1, 1, 1, 2, 3, 3, 3, 4) 406 Case 1: No packets are duplicated in a stream and both the Type-P- 407 one-way-packet-duplication-fraction and the type-P-one-way-packet- 408 replicated-packet-rate are 0. 410 Case 2: Every packet is duplicated once and the Type-P-one-way- 411 packet-duplication-fraction is 100%. The type-P-one-way-replicated- 412 packet-rate is 100% too. 414 Case 3: Every packet is duplicated twice, so the Type-P-one-way- 415 packet-duplication-fraction is 200%. The type-P-one-way-replicated- 416 packet-rate is still 100%. 418 Case 4: Half the packets are duplicated twice and the other half are 419 not duplicated. The Type-P-one-way-packet-duplication-fraction is 420 again 100% and this number does not show the difference with case 2. 421 However, the type-P-one-way-packet-replicated-packet-rate is 50% in 422 this case and 100% in case 2. 424 However, the type-P-one-way-packet-duplication-rate will not show the 425 difference between case 2 and 3. For this, one has to look at the 426 Type-P-one-way-packet-duplication-fraction. 428 6. Security Considerations 430 Conducting Internet measurements raises both security and privacy 431 concerns. This memo does not specify an implementation of the 432 metrics, so it does not directly affect the security of the Internet 433 nor of applications which run on the Internet. However, 434 implementations of these metrics must be mindful of security and 435 privacy concerns. 437 There are two types of security concerns: potential harm caused by 438 the measurements, and potential harm to the measurements. The 439 measurements could cause harm because they are active, and inject 440 packets into the network. The measurement parameters MUST be 441 carefully selected so that the measurements inject trivial amounts of 442 additional traffic into the networks they measure. If they inject 443 "too much" traffic, they can skew the results of the measurement, and 444 in extreme cases cause congestion and denial of service. 446 The measurements themselves could be harmed by routers giving 447 measurement traffic a different priority than "normal" traffic, or by 448 an attacker injecting artificial measurement traffic. If routers can 449 recognize measurement traffic and treat it separately, the 450 measurements will not reflect actual user traffic. If an attacker 451 injects artificial traffic that is accepted as legitimate, the loss 452 rate will be artificially lowered. Therefore, the measurement 453 methodologies SHOULD include appropriate techniques to reduce the 454 probability measurement traffic can be distinguished from "normal" 455 traffic. Authentication techniques, such as digital signatures, may 456 be used where appropriate to guard against injected traffic attacks. 458 The privacy concerns of network measurement are limited by the active 459 measurements described in this memo. Unlike passive measurements, 460 there can be no release of existing user data. 462 7. IANA Considerations 464 IANA is asked to add this metrics to the IANA IP Performance Metrics 465 (IPPM) Metrics Registry, see [RFC4148]. This section can be removed 466 after this has been done and upon publication as a RFC. 468 8. Acknowledgements 470 The idea to write this draft came up in a meeting with Al Morton, 471 Stanislav Shalunov, Emile Stephan and the author, on the IPPM 472 reporting draft. 474 This document relies heavily on [RFC2680] and the author likes to 475 thank the authors of that document for writing it. 477 Finally, thanks are due to ... for their comments. 479 9. References 481 9.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 9.2. Informative References 488 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 489 "Framework for IP Performance Metrics", RFC 2330, 490 May 1998. 492 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 493 Packet Loss Metric for IPPM", RFC 2680, September 1999. 495 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 496 performance measurement with periodic streams", RFC 3432, 497 November 2002. 499 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 500 Registry", BCP 108, RFC 4148, August 2005. 502 [Y1540] A. Morton, "Y.1540", July 2003. 504 Author's Address 506 Henk Uijterwaal 507 RIPE NCC 508 Singel 258 509 1016 AB Amsterdam 510 The Netherlands 512 Phone: +31 20 535 4444 513 Email: henk@ripe.net 515 Full Copyright Statement 517 Copyright (C) The IETF Trust (2007). 519 This document is subject to the rights, licenses and restrictions 520 contained in BCP 78, and except as set forth therein, the authors 521 retain all their rights. 523 This document and the information contained herein are provided on an 524 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 525 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 526 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 527 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 528 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 529 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 531 Intellectual Property 533 The IETF takes no position regarding the validity or scope of any 534 Intellectual Property Rights or other rights that might be claimed to 535 pertain to the implementation or use of the technology described in 536 this document or the extent to which any license under such rights 537 might or might not be available; nor does it represent that it has 538 made any independent effort to identify any such rights. Information 539 on the procedures with respect to rights in RFC documents can be 540 found in BCP 78 and BCP 79. 542 Copies of IPR disclosures made to the IETF Secretariat and any 543 assurances of licenses to be made available, or the result of an 544 attempt made to obtain a general license or permission for the use of 545 such proprietary rights by implementers or users of this 546 specification can be obtained from the IETF on-line IPR repository at 547 http://www.ietf.org/ipr. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights that may cover technology that may be required to implement 552 this standard. Please address the information to the IETF at 553 ietf-ipr@ietf.org. 555 Acknowledgment 557 Funding for the RFC Editor function is provided by the IETF 558 Administrative Support Activity (IASA).