INTERNET-DRAFT N. Elkins Intended Status: Proposed Standard W. Jouris Inside Products Expires: April 2014 October 3, 2013 IPPM Considerations for the IPv6 PDM Extension Header draft-elkins-ippm-pdm-metrics-00 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 14, 2014 [Page 1] INTERNET DRAFT elkins-ippm-pdm-metrics-00 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Packet Identification Data . . . . . . . . . . . . . . . . . 4 1.3 Data in the PDM Destination Option Header . . . . . . . . . 5 2 Metrics Derived from the PDM Destination Option . . . . . . . . 5 3 Base Derived Metrics . . . . . . . . . . . . . . . . . . . . . . 5 3.1 One-Way Delay . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 6 4.0 Sample Implementation Flow . . . . . . . . . . . . . . . . . 6 4.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Elkins Expires April 14, 2014 [Page 2] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 4.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5 Derived Metrics : Advanced . . . . . . . . . . . . . . . . . . . 10 5.1 Advanced Derived Metrics : Triage . . . . . . . . . . . . . 10 5.2 Advanced Derived Metrics : Network Diagnostics . . . . . . . 11 5.2.1 Retransmit Duplication (RD) . . . . . . . . . . . . . . 11 5.2.2 ACK Lag (AL) . . . . . . . . . . . . . . . . . . . . . . 12 5.2.3 Third-party Connection Reset (TPCR) . . . . . . . . . . 12 5.2.4 Potential Hang (PH) . . . . . . . . . . . . . . . . . . 12 5.3 Advanced Metrics : Session Classification . . . . . . . . . 13 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 9 Acknowledgments .. . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Elkins Expires April 14, 2014 [Page 3] INTERNET DRAFT elkins-ippm-pdm-metrics-00 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-02 [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. Elkins Expires April 14, 2014 [Page 4] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 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.) 1.2 Data in the PDM Destination Option Header The data contained in the PDM is as follows: PSNTP : Packet Sequence Number This Packet TSTP : Timestamp This Packet PSNLR : Packet Sequence Number Last Received TSLR : Timestamp Last Received The metrics which may be derived from these fields will be discussed in the following sections. 2 Metrics Derived from the PDM Destination Option 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. 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 Elkins Expires April 14, 2014 [Page 5] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 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.0 Sample Implementation Flow 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 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 Packet 1 is sent from Host A to Host B. The time for Host A is set Elkins Expires April 14, 2014 [Page 6] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 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 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 sent when the response to packet 1 is sent by Host B. Packet 1 Received +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ Elkins Expires April 14, 2014 [Page 7] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 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 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: 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 Elkins Expires April 14, 2014 [Page 8] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 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 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: - 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 Elkins Expires April 14, 2014 [Page 9] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 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 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 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. 5.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. Elkins Expires April 14, 2014 [Page 10] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 5.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. 5.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. Elkins Expires April 14, 2014 [Page 11] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 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. 5.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. 5.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. Elkins Expires April 14, 2014 [Page 12] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 5.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. 5.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 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. 6 Security Considerations There are no security considerations. 7 IANA Considerations There are no IANA considerations. 8 References 8.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. Elkins Expires April 14, 2014 [Page 13] INTERNET DRAFT elkins-ippm-pdm-metrics-00 October 2013 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [ACKPDM] Ackermann, M., "draft-ackermann-tictoc-pdm-ntp-usage-00", Internet Draft, September 2013. [ELKPDM] Elkins, N., "draft-elkins-6man-ipv6-pdm-dest-option-02", Internet Draft, September 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 9 Acknowledgments The authors would like to thank Al Morton, David Boyes, Mike Ackermann, Keven Haining, Sigfrido Perdomo 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 14, 2014 [Page 14]