idnits 2.17.1 draft-elkins-ippm-pdm-metrics-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (October 15, 2013) is 3839 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 normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT N. Elkins 3 B. Jouris 4 Intended Status: Proposed Standard Inside Products 5 Expires: April 2014 October 15, 2013 7 IPPM Considerations for the IPv6 PDM Extension Header 8 draft-elkins-ippm-pdm-metrics-01 10 Abstract 12 To diagnose performance and connectivity problems, metrics on real 13 (non-synthetic) transmission are critical for timely end-to-end 14 problem resolution. Such diagnostics may be real-time or after the 15 fact, but must not impact an operational production network. These 16 metrics are defined in the IPv6 Performance and Diagnostic Metrics 17 Destination Option (PDM). The base metrics are: packet sequence 18 number and packet timestamp. Other metrics may be derived from these 19 for use in diagnostics. This document specifies such metrics, their 20 calculation, and usage. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Packet Identification Data . . . . . . . . . . . . . . . . . 3 62 1.2 Data in the PDM Destination Option Headers . . . . . . . . . 4 63 2 Metrics Derived from the PDM Destination Options . . . . . . . . 4 64 3 Base Derived Metrics . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1 One-Way Delay . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4 Sample Implementation Flow (PDM Type 1) . . . . . . . . . . . . 5 69 4.1 Step 1 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 6 70 4.2 Step 2 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 6 71 4.3 Step 3 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 7 72 4.4 Step 4 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 8 73 4.5 Step 5 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 9 74 5 Sample Implementation Flow (PDM 2) . . . . . . . . . . . . . . . 9 75 5.1 Step 1 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 10 76 5.2 Step 2 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 11 77 5.3 Step 3 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 11 78 5.4 Step 4 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 12 79 5.5 Step 5 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 13 80 6 Derived Metrics : Advanced . . . . . . . . . . . . . . . . . . . 14 81 6.1 Advanced Derived Metrics : Triage . . . . . . . . . . . . . 14 82 6.2 Advanced Derived Metrics : Network Diagnostics . . . . . . . 14 83 6.2.1 Retransmit Duplication (RD) . . . . . . . . . . . . . . 15 84 6.2.2 ACK Lag (AL) . . . . . . . . . . . . . . . . . . . . . . 16 85 6.2.3 Third-party Connection Reset (TPCR) . . . . . . . . . . 16 86 6.2.4 Potential Hang (PH) . . . . . . . . . . . . . . . . . . 16 87 6.3 Advanced Metrics : Session Classification . . . . . . . . . 16 88 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 89 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 90 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 92 9.2 Informative References . . . . . . . . . . . . . . . . . . . 17 93 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 1 Introduction 98 To diagnose performance and connectivity problems, metrics on real 99 (non-synthetic) transmission are critical for timely end-to-end 100 problem resolution. Such diagnostics may be real-time or after the 101 fact, but must not impact an operational production network. These 102 metrics are defined in the IPv6 Performance and Diagnostic Metrics 103 Destination Option (PDM). The base metrics are: packet sequence 104 number and packet timestamp. Other metrics may be derived from these 105 for use in diagnostics. This document specifies such metrics, their 106 calculation, and usage. 108 For background, please see draft-ackermann-tictoc-pdm-ntp-usage-00 109 [ACKPDM], draft-elkins-6man-ipv6-pdm-dest-option-03 [ELKPDM], draft- 110 elkins-v6ops-ipv6-packet-sequence-needed-01 [ELKPSN], draft-elkins- 111 v6ops-ipv6-pdm-recommended-usage-01 [ELKUSE], and draft-elkins-v6ops- 112 ipv6-end-to-end-rt-needed-01 [ELKRSP]. These drafts are companions to 113 this document. 115 As defined in RFC2460 [RFC2460], destination options are carried by 116 the IPv6 Destination Options extension header. Destination options 117 include optional information that need be examined only by the IPv6 118 node given as the destination address in the IPv6 header, not by 119 routers in between. 121 The PDM DOH will be carried by each packet in the network, if this is 122 configured. That is, the PDM DOH is optional. If the user of the OS 123 configures the PDM DOH to be used, then it will be carried in the 124 packet. 126 The metrics in the PDM are for 'real' data. That is, they are of the 127 traffic actually traveling on the network. 129 1.1 Packet Identification Data 131 Each packet contains information about the sender and receiver. In IP 132 protocol the identifying information is called a "5-tuple". The 133 flows described below are for the set of packets flowing between A 134 and B without consideration of any other packets sent to any other 135 device from Host A or Host B. 137 The 5-tuple consists of: 139 SADDR : IP address of the sender 140 SPORT : Port for sender 141 DADDR : IP address of the destination 142 DPORT : Port for destination 143 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) 145 1.2 Data in the PDM Destination Option Headers 147 The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) 148 is an implementation of the Destination Options Header (Next Header 149 value = 60). Two types of PDM are defined. PDM type 1 requires time 150 synchronization. PDM type 2 does not require time synchronization. 152 PDM type 1 and PDM type 2 are mutually exclusive. That is, a 5-tuple 153 can either both send PDM type 1 or both send PDM type 2. 155 PDM type 1 contains the following fields: 157 PSNTP : Packet Sequence Number This Packet 158 TSTP : Timestamp This Packet 159 PSNLR : Packet Sequence Number Last Received 160 TSLR : Timestamp Last Received 162 PDM type 2 contains the following fields: 164 PSNTP : Packet Sequence Number This Packet 165 PSNLR : Packet Sequence Number Last Received 166 DELTALR : Delta Last Received 167 PSNLS : Packet Sequence Number Last Sent 168 DELTALS : Delta Last Sent 170 The metrics which may be derived from these fields will be discussed 171 in the following sections. 173 2 Metrics Derived from the PDM Destination Options 175 A number of metrics may be derived from the data contained in the 176 PDM. Some are relationships between two packets, others require 177 analysis of multiple packets or multiple protocols. 179 These metrics fall into the following categories: 181 1. Base derived metrics 182 2. Metrics used for triage 183 3. Metrics used for network diagnostics 184 4. Metrics used for session classification 185 5. Metrics used for end user performance optimization 187 It must be understood that when a metric is discussed, it includes 188 the average, median, and other statistical variations of that metric. 190 In the next section, we will discuss the base metrics. In later 191 sections, we will discuss the more advanced metrics and their uses. 193 3 Base Derived Metrics 195 The base metrics which may be derived from the PDM are: 197 1. One-way delay 198 2. Round-trip delay 199 3. Server delay 201 3.1 One-Way Delay 203 One-way delay is the time taken to traverse the path one way between 204 one network device to another. The path from A to B is distinguished 205 from the path from B to A. For many reasons, the paths may have 206 different characteristics and may have different delays. One-way 207 delay is discussed in "A One-way Delay Metric for IPPM" [RFC2679]. 209 3.1 Round-Trip Delay 211 Round-trip delay is the time taken to traverse the path both ways 212 between one network device to another. The entire delay to travel 213 from A to B and B to A is used. Round-trip delay cannot tell if one 214 path is quite different from another. Round-trip delay is discussed 215 in "A Round-trip Delay Metric for IPPM" [RFC2681]. 217 3.2 Server Delay 219 Server delay is the interval between when a packet is received by a 220 device and a subsequent packet is sent back in response. This may be 221 "Server Processing Time". It may also be a delay caused by 222 acknowledgements. Server processing time includes the time taken by 223 the combination of the stack and application to return the response. 225 4 Sample Implementation Flow (PDM Type 1) 227 Following is a sample simple flow with one packet sent from Host A 228 and one packet received by Host B. The descriptions of these fields 229 is in draft-elkins-6man-ipv6-pdm-dest-option-02 [ELKPDM]. 231 Time synchronization is required between Host A and Host B. See 232 draft-ackermann-tictoc-pdm-ntp-usage-00 [ACKPDM] for a description of 233 how an NTP implementation may be set up to achieve good time 234 synchronization. 236 Each packet, in addition to the PDM, contains information on the 237 sender and receiver. This is the 5-tuple consisting of: 239 SADDR : IP address of the sender 240 SPORT : Port for sender 241 DADDR : IP address of the destination 242 DPORT : Port for destination 243 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) 245 It should be understood that the packet identification information is 246 in each packet. We will not repeat that in each of the following 247 steps. 249 4.1 Step 1 (PDM Type 1) 251 Packet 1 is sent from Host A to Host B. The time for Host A is set 252 initially to 10:00AM. 254 The timestamp and packet sequence number are sent in the PDM. 256 The initial PSNTP from Host A starts at a random number. In this 257 case, 25. The sub-second portion of the timestamp has been omitted 258 for the sake of simplicity. 260 Packet 1 262 +----------+ +----------+ 263 | | | | 264 | Host | ----------> | Host | 265 | A | | B | 266 | | | | 267 +----------+ +----------+ 269 PDM Contents: 271 PSNTP : Packet Sequence Number This Packet: 25 272 TSTP : Timestamp This Packet: 10:00:00 273 PSNLR : Packet Sequence Number Last Received: - 274 TSLR : Timestamp Last Received: - 276 There are no derived statistics after packet 1. 278 4.2 Step 2 (PDM Type 1) 280 Packet 1 is received by Host B. The time for Host B was synchronized 281 with Host A. Both were set initially to 10:00AM. 283 The timestamp and PSN for the received packet are placed in the PSNLR 284 and TSLR fields. These are from the point of view of B. That is, 285 they indicate when the packet from A was received and which packet it 286 was. 288 The PDM is not sent at this point. It is only prepared. It will be 289 sent when the response to packet 1 is sent by Host B. 291 Packet 1 Received 293 +----------+ +----------+ 294 | | | | 295 | Host | ----------> | Host | 296 | A | | B | 297 | | | | 298 +----------+ +----------+ 300 PDM Contents: 302 PSNTP : Packet Sequence Number This Packet: - 303 TSTP : Timestamp This Packet: - 304 PSNLR : Packet Sequence Number Last Received: 25 305 TSLR : Timestamp Last Received: 10:00:03 307 At this point, the following metric may be derived: one-way delay. 308 In fact, we now know the one-way delay and the path. We will call 309 this path 1. This will be the outbound path from the point of view 310 of Host A and the inbound path from the point of view of Host B. 312 The calculation of one-way delay (path 1) is as follows: 314 One-way delay (path 1) = Time packet 1 was received by B - Time 315 Packet 1 was sent by A 317 If we make the substitutions from our sample case above, then: 319 One-way delay (path 1) = 10:00:03 - 10:00:00 or 3 seconds 321 4.3 Step 3 (PDM Type 1) 323 Packet 2 is sent from Host B to Host A. The initial PSNTP from Host 324 B starts at a random number. In this case, 12. 326 Packet 2 328 +----------+ +----------+ 329 | | | | 330 | Host | <---------- | Host | 331 | A | | B | 332 | | | | 333 +----------+ +----------+ 335 PDM Contents: 337 PSNTP : Packet Sequence Number This Packet: 12 338 TSTP : Timestamp This Packet: 10:00:07 339 PSNLR : Packet Sequence Number Last Received: 25 340 TSLR : Timestamp Last Received: 10:00:03 342 After Packet 2 is sent, the following metric may be derived: server 343 delay. 345 The calculation of server delay is as follows: 347 Server delay = Time Packet 2 is sent by B - Time Packet 1 was 348 received by B 350 Again, making the substitutions from the sample case: 352 Server delay = 10:00:07 - 10:00:03 or 4 seconds 354 Further elaborations of server delay may be done by limiting the data 355 length to be greater than 1. Some protocols, for example, TCP, have 356 acknowledgements with a data length of 0 or keep-alive packets with a 357 data length of 1. An ACK may preceed the actual response data 358 packet. Keep-alives may be interspersed within the data flow. 360 4.4 Step 4 (PDM Type 1) 362 Packet 2 is received by Host A. 364 The timestamp and PSN for the received packet are placed in the PSNLR 365 and TSLR fields. These are from the point of view of A. That is, 366 they indicate when the packet from B was received and which packet it 367 was. 369 The PDM is not sent at this point. It is only prepared. It will be 370 sent when the NEXT packet to Host B is sent by Host A. 372 Packet 2 Received 374 +----------+ +----------+ 375 | | | | 376 | Host | <---------- | Host | 377 | A | | B | 378 | | | | 379 +----------+ +----------+ 381 PDM Contents: 383 PSNTP : Packet Sequence Number This Packet: - 384 TSTP : Timestamp This Packet: - 385 PSNLR : Packet Sequence Number Last Received: 12 386 TSLR : Timestamp Last Received: 10:00:10 388 However, at this point, the following metric may be derived: one-way 389 delay (path 2). 391 The calculation of one-way delay (path 2) is as follows: 393 One-way delay (path 2) = Time packet 2 received by A - Time packet 2 394 sent by B 396 If we make the substitutions from our sample case above, then: 398 One-way delay (path 2) = 10:00:10 - 10:00:07 or 3 seconds 400 4.5 Step 5 (PDM Type 1) 402 Packet 3 is sent from Host A to Host B. 404 Packet 3 406 +----------+ +----------+ 407 | | | | 408 | Host | ----------> | Host | 409 | A | | B | 410 | | | | 411 +----------+ +----------+ 413 PDM Contents: 415 PSNTP : Packet Sequence Number This Packet: 26 416 TSTP : Timestamp This Packet: 10:00:50 417 PSNLR : Packet Sequence Number Last Received: 12 418 TSLR : Timestamp Last Received: 10:00:10 420 At this point the PDM flows across the network revealing the last 421 received timestamp and PSN. 423 5 Sample Implementation Flow (PDM 2) 425 Following is a sample simple flow for PDM type 2 with one packet sent 426 from Host A and one packet received by Host B. PDM type 2 does not 427 require time synchronization between Host A and Host B. The 428 calculations to derive meaningful metrics for network diagnostics is 429 shown below each packet sent or received. 431 Each packet, in addition to the PDM contains information on the 432 sender and receiver. As discussed before, a 5-tuple consists of: 434 SADDR : IP address of the sender 435 SPORT : Port for sender 436 DADDR : IP address of the destination 437 DPORT : Port for destination 438 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc) 440 It should be understood that the packet identification information is 441 in each packet. We will not repeat that in each of the following 443 5.1 Step 1 (PDM Type 2) 445 Packet 1 is sent from Host A to Host B. The time for Host A is set 446 initially to 10:00AM. 448 The timestamp and packet sequence number are noted by the sender 449 internally. The packet sequence number and timestamp are sent in the 450 packet. 452 Packet 1 454 +----------+ +----------+ 455 | | | | 456 | Host | ----------> | Host | 457 | A | | B | 458 | | | | 459 +----------+ +----------+ 461 PDM type 2 Contents: 463 PSNTP : Packet Sequence Number This Packet: 25 464 PSNLR : Packet Sequence Number Last Received: - 465 DELTALR : Delta Last Received: - 466 PSNLS : Packet Sequence Number Last Sent: - 467 DELTALS : Delta Last Sent: - 469 Internally, within the sender, Host A, it must keep: 471 PSNTP : Packet Sequence Number This Packet: 25 472 TSTP : Timestamp This Packet: 10:00:00 474 Note, the initial PSNTP from Host A starts at a random number. In 475 this case, 25. The sub-second portion of the timestamp has been 476 omitted for the sake of simplicity. 478 There are no derived statistics after packet 1. 480 5.2 Step 2 (PDM Type 2) 482 Packet 1 is received at Host B. His time is set to one hour later 483 than Host A. In this case, 11:00AM 485 Internally, within the receiver, Host B, it must keep: 487 PSNLR : Packet Sequence Number Last Received: 25 488 TSLR : Timestamp Last Received : 11:00:03 490 Note, this timestamp is in Host B time. It has nothing whatsoever to 491 do with Host A time. 493 At this point, we have no derived statistics. In PDM type 1, the 494 derived statistic one-way delay (path 1) could have been calculated. 495 In PDM type 2, this is not possible because there is no time 496 synchronization. 498 5.3 Step 3 (PDM Type 2) 500 Packet 2 is sent by Host B to Host A. Note, the initial PSNTP from 501 Host B starts at a random number. In this case, 12. Before sending 502 the packet, Host B does a calculation of deltas. Since Host B knows 503 when it is sending the packet, and it knows when it received the 504 previous packet, it can do the following calculation: 506 Sending time (packet 2) - receive time (packet 1) 508 We will call the result of this calculation: Delta Last Received. 510 That is: 512 DELTALR = Sending time (packet 2) - receive time (packet 1) 514 Note, both sending time and receive time are saved internally in Host 515 B. They do not travel in the packet. Only the Delta is in the 516 packet. 518 Assume that within Host B is the following: 520 PSNLR : Packet Sequence Number Last Received: 25 521 TSLR : Timestamp Last Received : 11:00:03 522 PSNTP : Packet Sequence Number This Packet : 12 523 TSTP : Timestamp This Packet : 11:00:07 525 Hence, DELTALR becomes: 527 4 seconds = 11:00:07 - 11:00:03 529 Let us look at the PDM, and then we will look at the derived metrics 530 at this point. 532 Packet 2 534 +----------+ +----------+ 535 | | | | 536 | Host | <---------- | Host | 537 | A | | B | 538 | | | | 539 +----------+ +----------+ 541 PDM Type 2 Contents: 543 PSNTP : Packet Sequence Number This Packet: 12 544 PSNLR : Packet Sequence Number Last Received: 25 545 DELTALR : Delta Last Received: 4 546 PSNLS : Packet Sequence Number Last Sent: - 547 DELTALS : Delta Last Sent: - 549 After Packet 2, the following metrics may be derived: 551 Server delay = DELTALR 553 Metrics left to be calculated are the path delay for path 2. This may 554 be calculated when Packet 3 is sent. Clearly, if there is NO next 555 packet for the 5-tuple, then this value will be missing. 557 5.4 Step 4 (PDM Type 2) 559 Packet 2 is received at Host A. Remember, its time is set to one 560 hour earlier than Host B. It will keep internally: 562 PSNLR : Packet Sequence Number Last Received: 12 563 TSLR : Timestamp Last Received : 10:00:12 565 Note, this timestamp is in Host A time. It has nothing whatsoever to 566 do with Host B time. 568 At this point, we have two derived metrics: 570 1. Two-way delay or Round Trip time 571 2. Total end-to-end time 573 The formula for end-to-time is: 575 Time Last Received - Time Last Sent 577 For example, packet 25 was sent by Host A at 10:00:00. Packet 12 was 578 received by Host A at 10:00:12 so: 580 End-to-End response time = 10:00:12 - 10:00:00 or 12 582 This derived metric we will call DELTALS or Delta Last Sent. 584 To calculate two-way delay, the formula is: 586 Two-way delay = DELTALS - DELTALR 588 Or: 590 Two-way delay = 12 - 4 or 8 592 Now, the only problem is that at this point all metrics are in the 593 Host and not exposed in a packet. To do that, we need a third packet. 595 5.5 Step 5 (PDM Type 2) 597 Packet 3 is sent from Host A to Host B. 599 Packet 3 601 +----------+ +----------+ 602 | | | | 603 | Host | ----------> | Host | 604 | A | | B | 605 | | | | 606 +----------+ +----------+ 608 PDM Type 2 Contents: 610 PSNTP : Packet Sequence Number This Packet: 26 611 PSNLR : Packet Sequence Number Last Received: 12 612 DELTALR : Delta Last Received: * 613 PSNLS : Packet Sequence Number Last Sent: 25 614 DELTALS : Delta Last Sent: 12 616 6 Derived Metrics : Advanced 618 A number of more advanced metrics may be derived from the data 619 contained in the PDM. Some are relationships between two packets, 620 others require analysis of multiple packets. The more advanced 621 metrics fall into the categories shown below: 623 1. Metrics used for triage 624 2. Metrics used for network diagnostics 625 3. Metrics used for session classification 626 4. Metrics used for end user performance optimization 628 We will discuss each of these in turn. 630 6.1 Advanced Derived Metrics : Triage 632 In this case, triage means to distinguish between problems occurring 633 on the network paths or the server. The PDM provides one-way delay 634 and server delay. This will enable distinguishing which path is a 635 bottleneck as well as whether the server is a bottleneck. 637 6.2 Advanced Derived Metrics : Network Diagnostics 639 The data provided by the PDM may be used in combination with data 640 fields in other protocols. We will call this Inter-Protocol Network 641 Diagnostics (IPND). 643 The PDM also allows us to use only a single trace point for a number 644 of diagnostic situations where today we need to trace at multiple 645 points to get required data. In diagnostics, there is often the 646 question of did the end device really send the packet and it got lost 647 in the network or did it not send it at all. 649 So, what is done is that diagnostic traces are run at both client and 650 server to get the required data. With the data provided by the PDM, 651 in a number of the cases, this will not be necessary. 653 For example, taking PDM values along with data fields in the TCP 654 protocol, the following may be found: 656 1. Retransmit duplication (RD) 657 2. ACK lag (AL) 658 3. Third-party connection reset (TPCR) 659 4. Elapsed time connection reset (ETCR) 661 A description of these follows. 663 6.2.1 Retransmit Duplication (RD) 665 The TCP protocol will retransmit segments given indications from the 666 partner that it has not received them. The retransmitted segments 667 contain the TCP sequence number and acknowledgement. The sequence 668 number is started at a random number and increased by the amount of 669 data sent in each packet. 671 Consider the following scenario. There is a packet sequence number 672 in the packet at the IP layer. This is in the PDM that we have 673 defined. The TCP sequence number already exists in the protocol. 675 Host A sends the following packets: 677 IP PSN 20, TCP SEQ 10 678 IP PSN 21, TCP SEQ 11 679 IP PSN 22, TCP SEQ 12 681 Host B receives: 683 IP PSN 20, TCP SEQ 10 684 IP PSN 22, TCP SEQ 12 686 Host B indicates to Host A to resend packet with TCP SEQ 2. 687 Retransmits are done at the TCP layer. 689 Host A sends the following packet: 691 IP PSN 23, TCP SEQ 11 693 The packet never reaches B. B waits until a timeout for retransmits 694 expires. It asks for the packet again. 696 Host A sends the following packet: 698 IP PSN 24, TCP SEQ 11 700 This time, it reaches Host B. Having the combination of PSN (as 701 provided in the PDM) and the TCP sequence number allows us to see 702 whether the problem is that the network is losing the packet or 703 somehow, the sender is not sending the packet correctly. 705 As we said before, this also allows us a single trace point rather 706 than at the client and server to get the required data. 708 6.2.2 ACK Lag (AL) 710 Some protocols, such as TCP, acknowledge packets. The PDM will allow 711 or a calculation of rate of ACKs. Clients can be reconfigured to 712 optimize acknowledgements and to speed traffic flow. 714 6.2.3 Third-party Connection Reset (TPCR) 716 Connections may be aborted by a packet containing a particular flag. 717 In the TCP protocol, this is the RESET flag. Sometimes a third- 718 party, for example, a VPN router, will abort the connection. This 719 may happen because the router is overloaded, the traffic is too 720 noisy, or other reasons. This can also be quite hard to detect 721 because the third-party will spoof the address of the sender. 723 Much time can be spent by the two endpoints pointing fingers at the 724 other for having dropped the connection. 726 Such a third-party spoofer would likely not have the PDM Destination 727 Option. Routers and other middle boxes are not required to support 728 the Destination Options Extension Header. Even if a PDM DOH was 729 generated, it would most likely violate the pattern of PSNs and time 730 stamps being used. This would be a clue to the diagnostician that 731 the TPCR event has occurred. 733 6.2.4 Potential Hang (PH) 735 Connections may be aborted by a packet containing a particular flag. 736 In the TCP protocol, this is the RESET flag. Sometimes this is done 737 because a set amount of time has elapsed without activity. The PSN in 738 the PDM can be used to determine the last packet sent by the partner 739 and if a response is required -- a "hang" situation. 741 This can be distinguished from connections which are set to be 742 aborted after a certain period of inactivity. 744 6.3 Advanced Metrics : Session Classification 746 The PDM may be used to classify sessions as follows: 748 One way traffic flow 749 Two way traffic flow 750 One way traffic flow with keep-alive 751 Two way traffic flow with keep-alive 752 Multiple send traffic flow 753 Multiple receive traffic flow 754 Full duplex traffic flow 755 Half duplex traffic flow 756 Immediate ACK data flow 757 Delayed ACK data flow 758 Proxied ACK data flow 760 A session classification system will assist the network 761 diagnostician. This system will also help in categorizing the server 762 delay. 764 7 Security Considerations 766 There are no security considerations. 768 8 IANA Considerations 770 There are no IANA considerations. 772 9 References 774 9.1 Normative References 776 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 777 (IPv6) Specification", RFC 2460, December 1998. 779 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 780 Delay Metric for IPPM", RFC 2679, September 1999. 782 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 783 Delay Metric for IPPM", RFC 2681, September 1999. 785 9.2 Informative References 787 [ACKPDM] Ackermann, M., "draft-ackermann-tictoc-pdm-ntp-usage-00", 788 Internet Draft, September 2013. 790 [ELKPDM] Elkins, N., "draft-elkins-6man-ipv6-pdm-dest-option-03", 791 Internet Draft, October 2013. 793 [ELKPSN] Elkins, N., "draft-elkins-v6ops-ipv6-packet-sequence- 794 needed-01", Internet Draft, September 2013. 796 [ELKRSP] Elkins, N., "draft-elkins-v6ops-ipv6-end-to-end-rt-needed- 797 01", Internet Draft, September 2013. 799 [ELKUSE] Elkins, N., "draft-elkins-v6ops-ipv6-pdm-recommended-usage- 800 01", Internet Draft, September 2013 802 10 Acknowledgments 804 The authors would like to thank Al Morton, David Boyes, 805 and Rick Troth for their comments and assistance. 807 Authors' Addresses 809 Nalini Elkins 810 Inside Products, Inc. 811 36A Upper Circle 812 Carmel Valley, CA 93924 813 United States 814 Phone: +1 831 659 8360 815 Email: nalini.elkins@insidethestack.com 816 http://www.insidethestack.com 818 William Jouris 819 Inside Products, Inc. 820 36A Upper Circle 821 Carmel Valley, CA 93924 822 United States 823 Phone: +1 925 855 9512 824 Email: bill.jouris@insidethestack.com 825 http://www.insidethestack.com