INTERNET-DRAFT N. Elkins B. Jouris Intended Status: Proposed Standard Inside Products Expires: April 2014 October 15, 2013 IPPM Considerations for the IPv6 PDM Extension Header draft-elkins-ippm-pdm-metrics-01 Abstract To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. These metrics are defined in the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). The base metrics are: packet sequence number and packet timestamp. Other metrics may be derived from these for use in diagnostics. This document specifies such metrics, their calculation, and usage. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Elkins Expires April 18, 2014 [Page 1] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Packet Identification Data . . . . . . . . . . . . . . . . . 3 1.2 Data in the PDM Destination Option Headers . . . . . . . . . 4 2 Metrics Derived from the PDM Destination Options . . . . . . . . 4 3 Base Derived Metrics . . . . . . . . . . . . . . . . . . . . . . 5 3.1 One-Way Delay . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Sample Implementation Flow (PDM Type 1) . . . . . . . . . . . . 5 4.1 Step 1 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 6 4.2 Step 2 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 6 4.3 Step 3 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 7 4.4 Step 4 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 8 4.5 Step 5 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 9 5 Sample Implementation Flow (PDM 2) . . . . . . . . . . . . . . . 9 5.1 Step 1 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 10 5.2 Step 2 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 11 5.3 Step 3 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 11 5.4 Step 4 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 12 5.5 Step 5 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 13 6 Derived Metrics : Advanced . . . . . . . . . . . . . . . . . . . 14 6.1 Advanced Derived Metrics : Triage . . . . . . . . . . . . . 14 6.2 Advanced Derived Metrics : Network Diagnostics . . . . . . . 14 6.2.1 Retransmit Duplication (RD) . . . . . . . . . . . . . . 15 6.2.2 ACK Lag (AL) . . . . . . . . . . . . . . . . . . . . . . 16 6.2.3 Third-party Connection Reset (TPCR) . . . . . . . . . . 16 6.2.4 Potential Hang (PH) . . . . . . . . . . . . . . . . . . 16 6.3 Advanced Metrics : Session Classification . . . . . . . . . 16 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 9.2 Informative References . . . . . . . . . . . . . . . . . . . 17 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Elkins Expires April 18, 2014 [Page 2] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 1 Introduction To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. These metrics are defined in the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). The base metrics are: packet sequence number and packet timestamp. Other metrics may be derived from these for use in diagnostics. This document specifies such metrics, their calculation, and usage. For background, please see draft-ackermann-tictoc-pdm-ntp-usage-00 [ACKPDM], draft-elkins-6man-ipv6-pdm-dest-option-03 [ELKPDM], draft- elkins-v6ops-ipv6-packet-sequence-needed-01 [ELKPSN], draft-elkins- v6ops-ipv6-pdm-recommended-usage-01 [ELKUSE], and draft-elkins-v6ops- ipv6-end-to-end-rt-needed-01 [ELKRSP]. These drafts are companions to this document. As defined in RFC2460 [RFC2460], destination options are carried by the IPv6 Destination Options extension header. Destination options include optional information that need be examined only by the IPv6 node given as the destination address in the IPv6 header, not by routers in between. The PDM DOH will be carried by each packet in the network, if this is configured. That is, the PDM DOH is optional. If the user of the OS configures the PDM DOH to be used, then it will be carried in the packet. The metrics in the PDM are for 'real' data. That is, they are of the traffic actually traveling on the network. 1.1 Packet Identification Data Each packet contains information about the sender and receiver. In IP protocol the identifying information is called a "5-tuple". The flows described below are for the set of packets flowing between A and B without consideration of any other packets sent to any other device from Host A or Host B. The 5-tuple consists of: SADDR : IP address of the sender SPORT : Port for sender DADDR : IP address of the destination DPORT : Port for destination PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) Elkins Expires April 18, 2014 [Page 3] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 1.2 Data in the PDM Destination Option Headers The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is an implementation of the Destination Options Header (Next Header value = 60). Two types of PDM are defined. PDM type 1 requires time synchronization. PDM type 2 does not require time synchronization. PDM type 1 and PDM type 2 are mutually exclusive. That is, a 5-tuple can either both send PDM type 1 or both send PDM type 2. PDM type 1 contains the following fields: PSNTP : Packet Sequence Number This Packet TSTP : Timestamp This Packet PSNLR : Packet Sequence Number Last Received TSLR : Timestamp Last Received PDM type 2 contains the following fields: PSNTP : Packet Sequence Number This Packet PSNLR : Packet Sequence Number Last Received DELTALR : Delta Last Received PSNLS : Packet Sequence Number Last Sent DELTALS : Delta Last Sent The metrics which may be derived from these fields will be discussed in the following sections. 2 Metrics Derived from the PDM Destination Options A number of metrics may be derived from the data contained in the PDM. Some are relationships between two packets, others require analysis of multiple packets or multiple protocols. These metrics fall into the following categories: 1. Base derived metrics 2. Metrics used for triage 3. Metrics used for network diagnostics 4. Metrics used for session classification 5. Metrics used for end user performance optimization It must be understood that when a metric is discussed, it includes the average, median, and other statistical variations of that metric. In the next section, we will discuss the base metrics. In later sections, we will discuss the more advanced metrics and their uses. Elkins Expires April 18, 2014 [Page 4] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 3 Base Derived Metrics The base metrics which may be derived from the PDM are: 1. One-way delay 2. Round-trip delay 3. Server delay 3.1 One-Way Delay One-way delay is the time taken to traverse the path one way between one network device to another. The path from A to B is distinguished from the path from B to A. For many reasons, the paths may have different characteristics and may have different delays. One-way delay is discussed in "A One-way Delay Metric for IPPM" [RFC2679]. 3.1 Round-Trip Delay Round-trip delay is the time taken to traverse the path both ways between one network device to another. The entire delay to travel from A to B and B to A is used. Round-trip delay cannot tell if one path is quite different from another. Round-trip delay is discussed in "A Round-trip Delay Metric for IPPM" [RFC2681]. 3.2 Server Delay Server delay is the interval between when a packet is received by a device and a subsequent packet is sent back in response. This may be "Server Processing Time". It may also be a delay caused by acknowledgements. Server processing time includes the time taken by the combination of the stack and application to return the response. 4 Sample Implementation Flow (PDM Type 1) Following is a sample simple flow with one packet sent from Host A and one packet received by Host B. The descriptions of these fields is in draft-elkins-6man-ipv6-pdm-dest-option-02 [ELKPDM]. Time synchronization is required between Host A and Host B. See draft-ackermann-tictoc-pdm-ntp-usage-00 [ACKPDM] for a description of how an NTP implementation may be set up to achieve good time synchronization. Each packet, in addition to the PDM, contains information on the sender and receiver. This is the 5-tuple consisting of: SADDR : IP address of the sender SPORT : Port for sender Elkins Expires April 18, 2014 [Page 5] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 DADDR : IP address of the destination DPORT : Port for destination PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) It should be understood that the packet identification information is in each packet. We will not repeat that in each of the following steps. 4.1 Step 1 (PDM Type 1) Packet 1 is sent from Host A to Host B. The time for Host A is set initially to 10:00AM. The timestamp and packet sequence number are sent in the PDM. The initial PSNTP from Host A starts at a random number. In this case, 25. The sub-second portion of the timestamp has been omitted for the sake of simplicity. Packet 1 +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM Contents: PSNTP : Packet Sequence Number This Packet: 25 TSTP : Timestamp This Packet: 10:00:00 PSNLR : Packet Sequence Number Last Received: - TSLR : Timestamp Last Received: - There are no derived statistics after packet 1. 4.2 Step 2 (PDM Type 1) Packet 1 is received by Host B. The time for Host B was synchronized with Host A. Both were set initially to 10:00AM. The timestamp and PSN for the received packet are placed in the PSNLR and TSLR fields. These are from the point of view of B. That is, they indicate when the packet from A was received and which packet it was. The PDM is not sent at this point. It is only prepared. It will be Elkins Expires April 18, 2014 [Page 6] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 sent when the response to packet 1 is sent by Host B. Packet 1 Received +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM Contents: PSNTP : Packet Sequence Number This Packet: - TSTP : Timestamp This Packet: - PSNLR : Packet Sequence Number Last Received: 25 TSLR : Timestamp Last Received: 10:00:03 At this point, the following metric may be derived: one-way delay. In fact, we now know the one-way delay and the path. We will call this path 1. This will be the outbound path from the point of view of Host A and the inbound path from the point of view of Host B. The calculation of one-way delay (path 1) is as follows: One-way delay (path 1) = Time packet 1 was received by B - Time Packet 1 was sent by A If we make the substitutions from our sample case above, then: One-way delay (path 1) = 10:00:03 - 10:00:00 or 3 seconds 4.3 Step 3 (PDM Type 1) Packet 2 is sent from Host B to Host A. The initial PSNTP from Host B starts at a random number. In this case, 12. Packet 2 +----------+ +----------+ | | | | | Host | <---------- | Host | | A | | B | | | | | +----------+ +----------+ PDM Contents: Elkins Expires April 18, 2014 [Page 7] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 PSNTP : Packet Sequence Number This Packet: 12 TSTP : Timestamp This Packet: 10:00:07 PSNLR : Packet Sequence Number Last Received: 25 TSLR : Timestamp Last Received: 10:00:03 After Packet 2 is sent, the following metric may be derived: server delay. The calculation of server delay is as follows: Server delay = Time Packet 2 is sent by B - Time Packet 1 was received by B Again, making the substitutions from the sample case: Server delay = 10:00:07 - 10:00:03 or 4 seconds Further elaborations of server delay may be done by limiting the data length to be greater than 1. Some protocols, for example, TCP, have acknowledgements with a data length of 0 or keep-alive packets with a data length of 1. An ACK may preceed the actual response data packet. Keep-alives may be interspersed within the data flow. 4.4 Step 4 (PDM Type 1) Packet 2 is received by Host A. The timestamp and PSN for the received packet are placed in the PSNLR and TSLR fields. These are from the point of view of A. That is, they indicate when the packet from B was received and which packet it was. The PDM is not sent at this point. It is only prepared. It will be sent when the NEXT packet to Host B is sent by Host A. Packet 2 Received +----------+ +----------+ | | | | | Host | <---------- | Host | | A | | B | | | | | +----------+ +----------+ PDM Contents: PSNTP : Packet Sequence Number This Packet: - Elkins Expires April 18, 2014 [Page 8] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 TSTP : Timestamp This Packet: - PSNLR : Packet Sequence Number Last Received: 12 TSLR : Timestamp Last Received: 10:00:10 However, at this point, the following metric may be derived: one-way delay (path 2). The calculation of one-way delay (path 2) is as follows: One-way delay (path 2) = Time packet 2 received by A - Time packet 2 sent by B If we make the substitutions from our sample case above, then: One-way delay (path 2) = 10:00:10 - 10:00:07 or 3 seconds 4.5 Step 5 (PDM Type 1) Packet 3 is sent from Host A to Host B. Packet 3 +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM Contents: PSNTP : Packet Sequence Number This Packet: 26 TSTP : Timestamp This Packet: 10:00:50 PSNLR : Packet Sequence Number Last Received: 12 TSLR : Timestamp Last Received: 10:00:10 At this point the PDM flows across the network revealing the last received timestamp and PSN. 5 Sample Implementation Flow (PDM 2) Following is a sample simple flow for PDM type 2 with one packet sent from Host A and one packet received by Host B. PDM type 2 does not require time synchronization between Host A and Host B. The calculations to derive meaningful metrics for network diagnostics is shown below each packet sent or received. Elkins Expires April 18, 2014 [Page 9] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 Each packet, in addition to the PDM contains information on the sender and receiver. As discussed before, a 5-tuple consists of: SADDR : IP address of the sender SPORT : Port for sender DADDR : IP address of the destination DPORT : Port for destination PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc) It should be understood that the packet identification information is in each packet. We will not repeat that in each of the following steps. 5.1 Step 1 (PDM Type 2) Packet 1 is sent from Host A to Host B. The time for Host A is set initially to 10:00AM. The timestamp and packet sequence number are noted by the sender internally. The packet sequence number and timestamp are sent in the packet. Packet 1 +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM type 2 Contents: PSNTP : Packet Sequence Number This Packet: 25 PSNLR : Packet Sequence Number Last Received: - DELTALR : Delta Last Received: - PSNLS : Packet Sequence Number Last Sent: - DELTALS : Delta Last Sent: - Internally, within the sender, Host A, it must keep: PSNTP : Packet Sequence Number This Packet: 25 TSTP : Timestamp This Packet: 10:00:00 Note, the initial PSNTP from Host A starts at a random number. In this case, 25. The sub-second portion of the timestamp has been omitted for the sake of simplicity. Elkins Expires April 18, 2014 [Page 10] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 There are no derived statistics after packet 1. 5.2 Step 2 (PDM Type 2) Packet 1 is received at Host B. His time is set to one hour later than Host A. In this case, 11:00AM Internally, within the receiver, Host B, it must keep: PSNLR : Packet Sequence Number Last Received: 25 TSLR : Timestamp Last Received : 11:00:03 Note, this timestamp is in Host B time. It has nothing whatsoever to do with Host A time. At this point, we have no derived statistics. In PDM type 1, the derived statistic one-way delay (path 1) could have been calculated. In PDM type 2, this is not possible because there is no time synchronization. 5.3 Step 3 (PDM Type 2) Packet 2 is sent by Host B to Host A. Note, the initial PSNTP from Host B starts at a random number. In this case, 12. Before sending the packet, Host B does a calculation of deltas. Since Host B knows when it is sending the packet, and it knows when it received the previous packet, it can do the following calculation: Sending time (packet 2) - receive time (packet 1) We will call the result of this calculation: Delta Last Received. That is: DELTALR = Sending time (packet 2) - receive time (packet 1) Note, both sending time and receive time are saved internally in Host B. They do not travel in the packet. Only the Delta is in the packet. Assume that within Host B is the following: PSNLR : Packet Sequence Number Last Received: 25 TSLR : Timestamp Last Received : 11:00:03 PSNTP : Packet Sequence Number This Packet : 12 TSTP : Timestamp This Packet : 11:00:07 Hence, DELTALR becomes: Elkins Expires April 18, 2014 [Page 11] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 4 seconds = 11:00:07 - 11:00:03 Let us look at the PDM, and then we will look at the derived metrics at this point. Packet 2 +----------+ +----------+ | | | | | Host | <---------- | Host | | A | | B | | | | | +----------+ +----------+ PDM Type 2 Contents: PSNTP : Packet Sequence Number This Packet: 12 PSNLR : Packet Sequence Number Last Received: 25 DELTALR : Delta Last Received: 4 PSNLS : Packet Sequence Number Last Sent: - DELTALS : Delta Last Sent: - After Packet 2, the following metrics may be derived: Server delay = DELTALR Metrics left to be calculated are the path delay for path 2. This may be calculated when Packet 3 is sent. Clearly, if there is NO next packet for the 5-tuple, then this value will be missing. 5.4 Step 4 (PDM Type 2) Packet 2 is received at Host A. Remember, its time is set to one hour earlier than Host B. It will keep internally: PSNLR : Packet Sequence Number Last Received: 12 TSLR : Timestamp Last Received : 10:00:12 Note, this timestamp is in Host A time. It has nothing whatsoever to do with Host B time. At this point, we have two derived metrics: 1. Two-way delay or Round Trip time 2. Total end-to-end time The formula for end-to-time is: Elkins Expires April 18, 2014 [Page 12] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 Time Last Received - Time Last Sent For example, packet 25 was sent by Host A at 10:00:00. Packet 12 was received by Host A at 10:00:12 so: End-to-End response time = 10:00:12 - 10:00:00 or 12 This derived metric we will call DELTALS or Delta Last Sent. To calculate two-way delay, the formula is: Two-way delay = DELTALS - DELTALR Or: Two-way delay = 12 - 4 or 8 Now, the only problem is that at this point all metrics are in the Host and not exposed in a packet. To do that, we need a third packet. 5.5 Step 5 (PDM Type 2) Packet 3 is sent from Host A to Host B. Packet 3 +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM Type 2 Contents: PSNTP : Packet Sequence Number This Packet: 26 PSNLR : Packet Sequence Number Last Received: 12 DELTALR : Delta Last Received: * PSNLS : Packet Sequence Number Last Sent: 25 DELTALS : Delta Last Sent: 12 Elkins Expires April 18, 2014 [Page 13] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 6 Derived Metrics : Advanced A number of more advanced metrics may be derived from the data contained in the PDM. Some are relationships between two packets, others require analysis of multiple packets. The more advanced metrics fall into the categories shown below: 1. Metrics used for triage 2. Metrics used for network diagnostics 3. Metrics used for session classification 4. Metrics used for end user performance optimization We will discuss each of these in turn. 6.1 Advanced Derived Metrics : Triage In this case, triage means to distinguish between problems occurring on the network paths or the server. The PDM provides one-way delay and server delay. This will enable distinguishing which path is a bottleneck as well as whether the server is a bottleneck. 6.2 Advanced Derived Metrics : Network Diagnostics The data provided by the PDM may be used in combination with data fields in other protocols. We will call this Inter-Protocol Network Diagnostics (IPND). The PDM also allows us to use only a single trace point for a number of diagnostic situations where today we need to trace at multiple points to get required data. In diagnostics, there is often the question of did the end device really send the packet and it got lost in the network or did it not send it at all. So, what is done is that diagnostic traces are run at both client and server to get the required data. With the data provided by the PDM, in a number of the cases, this will not be necessary. For example, taking PDM values along with data fields in the TCP protocol, the following may be found: 1. Retransmit duplication (RD) 2. ACK lag (AL) 3. Third-party connection reset (TPCR) 4. Elapsed time connection reset (ETCR) A description of these follows. Elkins Expires April 18, 2014 [Page 14] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 6.2.1 Retransmit Duplication (RD) The TCP protocol will retransmit segments given indications from the partner that it has not received them. The retransmitted segments contain the TCP sequence number and acknowledgement. The sequence number is started at a random number and increased by the amount of data sent in each packet. Consider the following scenario. There is a packet sequence number in the packet at the IP layer. This is in the PDM that we have defined. The TCP sequence number already exists in the protocol. Host A sends the following packets: IP PSN 20, TCP SEQ 10 IP PSN 21, TCP SEQ 11 IP PSN 22, TCP SEQ 12 Host B receives: IP PSN 20, TCP SEQ 10 IP PSN 22, TCP SEQ 12 Host B indicates to Host A to resend packet with TCP SEQ 2. Retransmits are done at the TCP layer. Host A sends the following packet: IP PSN 23, TCP SEQ 11 The packet never reaches B. B waits until a timeout for retransmits expires. It asks for the packet again. Host A sends the following packet: IP PSN 24, TCP SEQ 11 This time, it reaches Host B. Having the combination of PSN (as provided in the PDM) and the TCP sequence number allows us to see whether the problem is that the network is losing the packet or somehow, the sender is not sending the packet correctly. As we said before, this also allows us a single trace point rather than at the client and server to get the required data. Elkins Expires April 18, 2014 [Page 15] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 6.2.2 ACK Lag (AL) Some protocols, such as TCP, acknowledge packets. The PDM will allow or a calculation of rate of ACKs. Clients can be reconfigured to optimize acknowledgements and to speed traffic flow. 6.2.3 Third-party Connection Reset (TPCR) Connections may be aborted by a packet containing a particular flag. In the TCP protocol, this is the RESET flag. Sometimes a third- party, for example, a VPN router, will abort the connection. This may happen because the router is overloaded, the traffic is too noisy, or other reasons. This can also be quite hard to detect because the third-party will spoof the address of the sender. Much time can be spent by the two endpoints pointing fingers at the other for having dropped the connection. Such a third-party spoofer would likely not have the PDM Destination Option. Routers and other middle boxes are not required to support the Destination Options Extension Header. Even if a PDM DOH was generated, it would most likely violate the pattern of PSNs and time stamps being used. This would be a clue to the diagnostician that the TPCR event has occurred. 6.2.4 Potential Hang (PH) Connections may be aborted by a packet containing a particular flag. In the TCP protocol, this is the RESET flag. Sometimes this is done because a set amount of time has elapsed without activity. The PSN in the PDM can be used to determine the last packet sent by the partner and if a response is required -- a "hang" situation. This can be distinguished from connections which are set to be aborted after a certain period of inactivity. 6.3 Advanced Metrics : Session Classification The PDM may be used to classify sessions as follows: One way traffic flow Two way traffic flow One way traffic flow with keep-alive Two way traffic flow with keep-alive Multiple send traffic flow Multiple receive traffic flow Full duplex traffic flow Half duplex traffic flow Elkins Expires April 18, 2014 [Page 16] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 Immediate ACK data flow Delayed ACK data flow Proxied ACK data flow A session classification system will assist the network diagnostician. This system will also help in categorizing the server delay. 7 Security Considerations There are no security considerations. 8 IANA Considerations There are no IANA considerations. 9 References 9.1 Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. 9.2 Informative References [ACKPDM] Ackermann, M., "draft-ackermann-tictoc-pdm-ntp-usage-00", Internet Draft, September 2013. [ELKPDM] Elkins, N., "draft-elkins-6man-ipv6-pdm-dest-option-03", Internet Draft, October 2013. [ELKPSN] Elkins, N., "draft-elkins-v6ops-ipv6-packet-sequence- needed-01", Internet Draft, September 2013. [ELKRSP] Elkins, N., "draft-elkins-v6ops-ipv6-end-to-end-rt-needed- 01", Internet Draft, September 2013. [ELKUSE] Elkins, N., "draft-elkins-v6ops-ipv6-pdm-recommended-usage- 01", Internet Draft, September 2013 Elkins Expires April 18, 2014 [Page 17] INTERNET DRAFT elkins-ippm-pdm-metrics-01 October 2013 10 Acknowledgments The authors would like to thank Al Morton, David Boyes, and Rick Troth for their comments and assistance. Authors' Addresses Nalini Elkins Inside Products, Inc. 36A Upper Circle Carmel Valley, CA 93924 United States Phone: +1 831 659 8360 Email: nalini.elkins@insidethestack.com http://www.insidethestack.com William Jouris Inside Products, Inc. 36A Upper Circle Carmel Valley, CA 93924 United States Phone: +1 925 855 9512 Email: bill.jouris@insidethestack.com http://www.insidethestack.com Elkins Expires April 18, 2014 [Page 18]