idnits 2.17.1 draft-kikuchi-passive-measure-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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (May 21, 2008) is 5817 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) == Unused Reference: 'RFC2003' is defined on line 543, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-morton-perf-metrics-framework-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Kikuchi 3 Internet-Draft Kochi University of Technology 4 Intended status: Standards Track S. Matsushima 5 Expires: November 22, 2008 Softbank Telecom Corp. 6 K. Nagami 7 Intec Netcore Inc. 8 S. Uda 9 Japan Advanced Institute of 10 Science and Technology 11 N. Ogashiwa 12 Maebashi Kyoai Gakuen College 13 May 21, 2008 15 One-way Passive Measurement of End-to-End Quality 16 draft-kikuchi-passive-measure-02.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on November 22, 2008. 43 Abstract 45 This draft describes a passive measurement method for one-way end-to- 46 end quality. This method reports both whether a flow of packets is 47 in-sequence or not and error types on detecting out-of-sequence. The 48 method consumes small resource therefore it can be adapted to many 49 protocols that have sequence number field. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 56 2. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Measurement Method . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Counters and Functions . . . . . . . . . . . . . . . . . . 5 60 3.2. Measurement Algorithm . . . . . . . . . . . . . . . . . . 5 62 4. Requirements to Sequence Numbering . . . . . . . . . . . . . . 7 63 4.1. Indication of Sequence Number . . . . . . . . . . . . . . 7 64 4.2. Field Length . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. An Evaluation Trial . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. Usefullness . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.2. Qualifying Metrics . . . . . . . . . . . . . . . . . . . . 8 69 5.3. Reporting Model . . . . . . . . . . . . . . . . . . . . . 9 71 6. Algorithm Behavior . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 Intellectual Property and Copyright Statements . . . . . . . . . . 19 84 1. Introduction 86 This draft describes a passive measurement method for one-way end-to- 87 end connections quality. This method reports both 89 o whether a flow of packets is in-sequence or out-of-sequence, and 91 o error types on detecting out-of-sequence. 93 The purpose of the measurement by this method is to maintain 94 transports in operation [I-D.kikuchi-tunnel-measure-req] so that the 95 algorithm was designed to be lightweight. The algorithm detects out- 96 of-sequence packets strictly though; the error metrics is even not 97 accurate because the metrics should only provide some hints to 98 operators. 100 The algorithm requires a sequence number field in the packet headers, 101 such as extended GRE[RFC2784] [RFC2890], PWE3[RFC3985] and 102 RTP[RFC3550]. 104 1.1. Requirements notation 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Metrics 112 We firstly define ``in-sequence'' of a flow. 114 o in-sequence: the order of arrival packets at the egress of a flow 115 is the same order as departure at the ingress. 117 o out-of-sequence: a packet exists, which violates in-sequence state 118 of a flow. 120 We secondly define the metrics of types of out-of-sequence packet. 122 o dup-train: packet that is identical to the immediately preceding 123 arrival packet 125 o skipping: packet that should arrive next or more lately 127 o astern: packet that arrives after the successive packets' arrival 129 The metrics ``dup-train'', ``skipping'' and ``astern'' are similar to 130 duplication, lost and reordering respectively though, these metrics 131 above have different names because the definitions are slightly 132 different from any metrics defined before. 134 o ``dup-train'' does not mean naive duplication because the pair of 135 dup-train packets should arrive uninterruptedly by another packet. 137 o ``skipping'' happens on ``packet loss'' and even by 138 ``reordering''. 140 o ``astern'' might count inaccrately for as reordering packets on 141 complicated situation. 143 This kind of difference comes from the request of let the algorithm 144 lightweight described in Section 3. An accurate algorithm must have 145 much space for keeping the order of arrival packets until the exact 146 irregular reason will be become clear, moreover it takes much 147 computing power according to the space consumption. Those rough 148 metrics above allow to shrink the space that keeps just one sequence 149 number of the previously arrival packet. 151 Note that we do not define some kinds of ``rates'' because they are 152 easy to derived from total numbers of irregular packets. For 153 example, if you use SNMP [RFC3411] the rates are calculated from 154 periodical polling by an SNMP manager. 156 3. Measurement Method 158 In this section, we illustrate a method to measure qualities defined 159 in the previous section. The protocol should have the sequence 160 number field in its headers. 162 3.1. Counters and Functions 164 Egress router of a flow must have a register, named ``recvseq'', that 165 maintains the number that the successive arriving packet should have. 166 The ``recvseq'' register should be initialized by the specific number 167 depends on the target protocol. 169 The router must also have the following counters: 171 o duptrcnt: the number of dup-train packets, 173 o skipcnt: the number of skipping packets, and 175 o astrncnt: the number of astern packets 177 Let the counters above be unsigned integer and initialized by 0 on 178 the birth of the flow. The length of the counters should be the same 179 as the sequence number field defined in the protocol. 181 3.2. Measurement Algorithm 183 This algorithm determines whether a receiving packet is normal or not 184 while comparing a counter "recvseq" with the sequence number of the 185 packet named "seqno". The basic idea consists of the following 186 conditions. 188 1. if recvseq and seqno are same then "in-sequence", 190 2. else if seqno is just a predecessor of recvseq then "dup-train"; 192 3. otherwise if seqno proceed then "skipping" else "astern". 194 The following C-like codes specifies the algorithm in detail. The 195 function measure will be invoked by every one of the receptions of 196 packets. 198 boolean measure(packet_t packet) 199 { 200 unsigned int seqno; 201 seqno = packet->header->seqno; // getting seq # from header 203 if (seqno == recvseq) { 204 recvseq++; 205 return true; // in-sequence 206 } elsif (seqno+1 == recvseq) { // same # as predecessor's 207 duptrcnt++; // determines a dup-train 208 return false; // out-of-seq by dup-train 209 } 211 signed int diff; 212 diff = (signed int)(seqno - recvseq); 213 if (diff > 0) { // from past or future? 214 skipcnt += diff; // determines a skipping 215 recvseq = seqno; 216 } else { // means it is a past packet 217 astrncnt++; // determines a astern 218 } 219 return false; // out-of-seq w/o dup-train 220 } 222 Figure 1 224 The function ``measure'' returns true only if the packet is in- 225 sequence otherwise false on out-of-sequence. The value can be used 226 to discard the packet when the protocol does not allow passing 227 irregular packets to its higher layer. 229 4. Requirements to Sequence Numbering 231 In this section, we describe the requirements for protocols to adopt 232 this method. 234 4.1. Indication of Sequence Number 236 The protocol MUST indicate whether sequence numbering is enabled or 237 not. 239 There are two ways to indicate whether the sequence numbers are 240 enabled or not. One is to prepare an indication field in the header 241 independent from the sequence number field. 243 The other is to indicate a special sequence number, typically 0, 244 meaning disabled. In this case, the measurement process needs 245 additional steps on wrapping sequence number overflow because the 246 sequence number will skip 0 that does not seem continuous even if the 247 flow packets are still in-sequence. 249 4.2. Field Length 251 The length of sequence number field SHOULD be long enough according 252 to the transmission speed. Otherwise, the period of a lap of the 253 sequence number becomes too short and the reliability of the 254 measurement decreases. 256 For example, the algorithm may determine packets loss as reordering, 257 when there is a set of burst packets loss in case of the path change. 258 It is necessary to determine whether a burst packet loss occurred or 259 if it was simply the arrival of a very past packet when the 260 difference of the sequence numbers between two continuous packets is 261 very large. The typical technique is to use half of the 262 representable maximum value. This is simple and adequate if the 263 field is long enough. 265 However, the existence of the sequence number field generates more 266 amounts of transmission packets. Thus, if an insufficiently long 267 field creates overhead for protocols that are sensitive to resource 268 consumption. The sequence number field length should be considered 269 as a tradeoff between bandwidth efficiency and quality assurance. 271 5. An Evaluation Trial 273 Here we try to evaluate the metrics according to the framework 274 described in [I-D.morton-perf-metrics-framework]. 276 5.1. Usefullness 278 Firstly, we check the usefullness of the metrics listed in the 279 section 3.1 of [I-D.morton-perf-metrics-framework]. 281 1. The degree to which its absence would cause significant loss of 282 information on the behavior or state of the application or system 283 being measured? 285 * YES for TSPs who have SLA contracts with their customers. 287 * NO for best effort oriented flows. 289 2. The correlation between the metric and the quality of service / 290 experience delivered to the user (person or other application)? 292 * YES. It shows primitive quality to determine a flow traffic 293 in operation. 295 * NO. There is no correlation to any application because the 296 metrics are independent from specific applications. 298 3. The degree to which the metric is able to support the 299 identification and location of problems affecting service 300 quality? 302 * YES. It helps for operators to find out that problems come 303 from whether application or transport. 305 * NO. It does not indicate that problems come from whether TSP 306 or intermediate ISPs. 308 5.2. Qualifying Metrics 310 Secondly, we qualify the metrics by the list in the section 3.5 of 311 [I-D.morton-perf-metrics-framework]. 313 o Unambiguously defined? Yes. The description is not by a concrete 314 specification in natural language but in C-code. 316 o Units of Measure Specified? Yes. 318 o Measurement Errors Identified? Refer to Section 4.2 for less 319 sequence field length. 321 o Repeatable? Yes. 323 o Implementable? Yes, very much. 325 o Assumptions concerning underlying process? Not discussed. 327 o Use cases? Yes. Some examples are shown in Section 6. Moreover, 328 there is an implementation using the metrics in a multi-homing 329 solution with [RFC4908], which has been provided by Intec Netcore 330 Inc. 332 o Correlation with application performance / user experience? The 333 discussion is done in Section 5.1. 335 5.3. Reporting Model 337 The document does not define any reporting model for the metric. 339 6. Algorithm Behavior 341 The following diagrams show the behavior of the algorithm on 342 receiving out-of-sequence packets. Figure 3 shows the legend of flow 343 diagram here. The left and right sides represent the sender and 344 receiver of a flow respectively. Time flows upper to lower in the 345 diagrams. This illustrates a normal transmission with the sequence 346 number n. 348 time sender receiver 350 | | | 351 | n | | n 0 0 0 352 | |----[seq #: n]----->| 353 | n+1 | | n+1 0 0 0 354 | | | 355 V V V 357 Figure 2 359 Figure 3, Figure 4 and Figure 5 show simple cases, such as loss, 360 duplication and reordering of packets respectively. 362 [astrncnt]................ 363 [duptrcnt].............. : 364 [skipcnt]............ : : 365 : : : 366 [recvseq]......... : : : 367 ........[sendseq] : : : : 368 : : : : : 369 : : : : : 370 : : : : : 371 | | 372 0 | | 0 0 0 0 373 |------------------->| 374 1 | | 1 0 0 0 375 |------------------->| 376 2 | | 2 0 0 0 377 |-----> !LOST! | 378 3 | | 379 |------------------->| 380 4 | | 4 1 0 0 381 |-----> !LOST! | 382 5 | | 383 |-----> !LOST! | 384 6 | | 385 |------------------->| 386 7 | | 7 3 0 0 387 | | 388 V V 390 Figure 3 392 [astrncnt]................ 393 [duptrcnt].............. : 394 [skipcnt]............ : : 395 : : : 396 [recvseq]......... : : : 397 ........[sendseq] : : : : 398 : : : : : 399 | | 400 0 | | 0 0 0 0 401 |------------------->| 402 1 | | 1 0 0 0 403 |-------!DUP!------->| 404 | \ | 2 0 0 0 405 | \-------->| 406 2 | | 2 0 1 0 407 |------------------->| 408 3 | | 3 0 1 0 409 |-------!DUP!------->| 410 4 | \ | 4 0 1 0 411 | !DUP!------>| 412 | \ | 4 1 2 0 413 | \------>| 414 | | 4 1 3 0 415 |------------------->| 416 5 | | 5 1 3 0 417 | | 418 V V 420 Figure 4 422 [astrncnt]................ 423 [duptrcnt].............. : 424 [skipcnt]............ : : 425 : : : 426 [recvseq]......... : : : 427 ........[sendseq] : : : : 428 : : : : : 429 | | 430 0 | | 0 0 0 0 431 |------------------->| 432 1 | | 1 0 0 0 433 |-------\ | 434 2 | \ | 435 |---------\--------->| 436 3 | \ | 3 1 0 0 437 | \------->| 438 | | 3 1 0 1 439 |------------------->| 440 4 | | 4 1 0 1 441 |-------\ | 442 5 | \ | 443 |------\ \ | 444 6 | \ \ | 445 |--------\--\------->| 446 7 | \ \ | 7 3 0 1 447 | \ \----->| 448 | \ | 7 3 0 2 449 | \------>| 450 | | 7 3 0 3 451 | | 452 V V 454 Figure 5 456 Figure 6 and Figure 7 show cases in a little bit complex situations. 457 Figure 6 shows that the algorithm cannot distinguish a combination of 458 duplication and loss from a reordering. Compare the flow to former 459 of Figure 5. 461 [astrncnt]................ 462 [duptrcnt].............. : 463 [skipcnt]............ : : 464 : : : 465 [recvseq]......... : : : 466 ........[sendseq] : : : : 467 : : : : : 468 | | 469 0 | | 0 0 0 0 470 |------------------->| 471 1 | | 1 0 0 0 472 |-----!DUP!-->!LOST! | 473 2 | \ | 474 |---------\--------->| 475 3 | \ | 3 1 0 0 476 | \------->| 477 | | 3 1 0 1 478 | | 479 V V 481 Figure 6 483 Figure 7 shows that the algorithm interprets duplication as 484 reordering when a duplicated packet does not arrive in succession. 485 It is not possible to hold all of the information contained in the 486 arrival packets needed to measure accurately. 488 [astrncnt]................ 489 [duptrcnt].............. : 490 [skipcnt]............ : : 491 : : : 492 [recvseq]......... : : : 493 ........[sendseq] : : : : 494 : : : : : 495 | | 496 0 | | 0 0 0 0 497 |------------------->| 498 1 | | 1 0 0 0 499 |------!DUP!-------->| 500 2 | \ | 2 0 0 0 501 |----------\-------->| 502 3 | \ | 3 0 0 0 503 | \------>| 504 | | 3 0 0 1 505 V V 507 Figure 7 509 7. Security Considerations 511 The passive measurements do not use any additional packets and flows, 512 so that most security considerations boil down to the issues of the 513 original protocols. For example, fraud sequence numbers cause the 514 measurement process to become disorganized. This discussion boils 515 down to the issues of the header protection. 517 Appendix A. Acknowledgements 519 The authors would like to thank for helpful discussions in TEReCo 2.0 520 research project sponsored in part by the ministry of internal 521 affairs and communications Japan (SCOPE 072309007). 523 8. References 525 8.1. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, March 1997. 530 8.2. Informative References 532 [I-D.kikuchi-tunnel-measure-req] 533 Kikuchi, Y., Matsushima, S., Nagami, K., and S. Uda, 534 "Quality Measurement Requirements for Tunneling 535 Protocols", draft-kikuchi-tunnel-measure-req-02 (work in 536 progress), November 2007. 538 [I-D.morton-perf-metrics-framework] 539 Morton, A., "Framework for Performance Metric 540 Development", draft-morton-perf-metrics-framework-00 (work 541 in progress), October 2007. 543 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 544 October 1996. 546 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 547 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 548 March 2000. 550 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 551 RFC 2890, September 2000. 553 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 554 Architecture for Describing Simple Network Management 555 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 556 December 2002. 558 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 559 Jacobson, "RTP: A Transport Protocol for Real-Time 560 Applications", STD 64, RFC 3550, July 2003. 562 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 563 Edge (PWE3) Architecture", RFC 3985, March 2005. 565 [RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, 566 R., and H. Ohnishi, "Multi-homing for small scale fixed 567 network Using Mobile IP and NEMO", RFC 4908, June 2007. 569 Authors' Addresses 571 Yutaka Kikuchi 572 Kochi University of Technology 573 306B Research Collaboration Center 574 185 Miyanokuchi, Tosayamada-cho 575 Kami-shi, Kochi 782-0003 576 JP 578 Email: yu@kikuken.org 580 Satoru Matsushima 581 Softbank Telecom Corp. 582 1-9-1 Higashi-Shinbashi, Minato-ku 583 Tokyo 584 JP 586 Email: satoru@ft.solteria.net 588 Ken-ichi Nagami 589 Intec Netcore Inc. 590 1-3-3, Shin-suna 591 Koto-ku, Tokyo 592 JP 594 Email: nagami@inetcore.com 596 Satoshi Uda 597 Japan Advanced Institute of Science and Technology 598 1-1 Asahi-dai 599 Nomi-shi, Ishikawa-ken 923-1292 600 JP 602 Email: zin@jaist.ac.jp 604 Nobuo Ogashiwa 605 Maebashi Kyoai Gakuen College 606 Koyahara 1154-4 607 Maebashi, Gunma 379-2192 608 JP 610 Email: ogashiwa@c.kyoai.ac.jp 612 Full Copyright Statement 614 Copyright (C) The IETF Trust (2008). 616 This document is subject to the rights, licenses and restrictions 617 contained in BCP 78, and except as set forth therein, the authors 618 retain all their rights. 620 This document and the information contained herein are provided on an 621 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 622 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 623 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 624 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 625 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 628 Intellectual Property 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any 640 assurances of licenses to be made available, or the result of an 641 attempt made to obtain a general license or permission for the use of 642 such proprietary rights by implementers or users of this 643 specification can be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at 650 ietf-ipr@ietf.org.