--- 1/draft-ietf-ippm-6man-pdm-option-08.txt 2017-03-13 05:13:44.070512314 -0700 +++ 2/draft-ietf-ippm-6man-pdm-option-09.txt 2017-03-13 05:13:44.322518248 -0700 @@ -1,21 +1,21 @@ INTERNET-DRAFT N. Elkins Inside Products R. Hamilton Chemical Abstracts Service M. Ackermann Intended Status: Proposed Standard BCBS Michigan -Expires: September 1, 2017 February 28, 2017 +Expires: September 14, 2017 March 13, 2017 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option - draft-ietf-ippm-6man-pdm-option-08 + draft-ietf-ippm-6man-pdm-option-09 Abstract To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. @@ -58,65 +58,68 @@ described in the Simplified BSD License. Table of Contents 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 4 1.3 Need for a Packet Sequence Number (PSN) . . . . . . . . . . 5 1.4 Rationale for defined solution . . . . . . . . . . . . . . . 5 1.5 PDM Works in Collaboration with Other Headers . . . . . . . 6 - 1.6 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6 - 2 Measurement Information Derived from PDM . . . . . . . . . . . . 6 + 1.6 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 7 + 2 Measurement Information Derived from PDM . . . . . . . . . . . . 7 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7 - 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3 Performance and Diagnostic Metrics Destination Option Layout . . 7 - 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7 - 3.2 Performance and Diagnostic Metrics Destination Option . . . 7 - 3.2.1 PDM Layout . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 9 + 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3 Performance and Diagnostic Metrics Destination Option Layout . . 8 + 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 8 + 3.2 Performance and Diagnostic Metrics Destination Option . . . 8 + 3.2.1 PDM Layout . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 10 3.2.3 Considerations of this time-differential - representation . . . . . . . . . . . . . . . . . . . . . 10 - 3.2.3.1 Limitations with this encoding method . . . . . . . 10 + representation . . . . . . . . . . . . . . . . . . . . . 11 + 3.2.3.1 Limitations with this encoding method . . . . . . . 11 3.2.3.2 Loss of precision induced by timer value - truncation . . . . . . . . . . . . . . . . . . . . . 11 - 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 12 - 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 12 - 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 12 - 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 13 - 3.5 Implementation Considerations . . . . . . . . . . . . . . . 14 - 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 14 - 3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 14 - 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 - 4.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 15 - 4.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 15 - 4.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 16 - 4.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 16 - 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 - 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 - 6.2 Informative References . . . . . . . . . . . . . . . . . . . 18 - Appendix A : Timing Time Differential Calculations . . . . . . . . 18 - Appendix B: Sample Packet Flows . . . . . . . . . . . . . . . . . 19 - B.1 PDM Flow - Simple Client Server . . . . . . . . . . . . . . 19 - B.1.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . 20 - B.1.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 20 - B.1.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . 21 - B.1.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . 22 - B.1.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . 23 - B.2 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . 23 - B.2.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . 23 - B.2.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . 24 - B.2.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . 25 - Appendix C: Potential Overhead Considerations . . . . . . . . . . 27 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 + truncation . . . . . . . . . . . . . . . . . . . . . 12 + 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 13 + 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 13 + 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 13 + 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 14 + 3.5 Implementation Considerations . . . . . . . . . . . . . . . 15 + 3.5.1 PDM Activation . . . . . . . . . . . . . . . . . . . . . 15 + 3.5.2 PDM Timestamps . . . . . . . . . . . . . . . . . . . . . 15 + 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 16 + 3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 16 + 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 + 4.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 16 + 4.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 17 + 4.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 17 + 4.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 18 + 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 + 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 + 6.2 Informative References . . . . . . . . . . . . . . . . . . . 19 + Appendix A : Timing Time Differential Calculations . . . . . . . . 20 + Appendix B: Sample Packet Flows . . . . . . . . . . . . . . . . . 21 + B.1 PDM Flow - Simple Client Server . . . . . . . . . . . . . . 21 + B.1.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . 21 + B.1.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 22 + B.1.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . 23 + B.1.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . 24 + B.1.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . 25 + + B.2 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . 25 + B.2.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . 25 + B.2.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . 26 + B.2.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . 27 + Appendix C: Potential Overhead Considerations . . . . . . . . . . 29 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 1 Background To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. 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 @@ -181,34 +184,59 @@ 1.4 Rationale for defined solution The current IPv6 specification does not provide timing nor a similar field in the IPv6 main header or in any extension header. So, we define the IPv6 Performance and Diagnostic Metrics destination option (PDM). Advantages include: - 1. Real measure of actual transactions - 2. Independence from transport layer protocols + 1. Real measure of actual transactions. + + 2. Independence from transport layer protocols. + 3. Ability to span organizational boundaries with consistent - instrumentation + instrumentation. + 4. No time synchronization needed between session partners - 5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) - in a uniform way + 5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) in + a uniform way The PDM provides the ability to determine quickly if the (latency) - problem is in the network or in the server (application). More - intermediate measurements may be needed if the host or network - discrimination is not sufficient. At the client, TCP/IP stack time - vs. application time may still need to be broken out by client - software. + problem is in the network or in the server (application). That is, + it is a fast way to do triage. + + One of the important functions of PDM is to allow you to do quickly + dispatch the right set of diagnosticians. Within network or server + latency, there may be many components. The job of the diagnostician + is to rule each one out until the culprit is found. + + How PDM fits into this diagnostic picture is that PDM will quickly + tell you how to escalate. PDM will point to either the network area + or the server area. Within the server latency, PDM does not tell + you if the bottleneck is in the IP stack or the application or buffer + allocation. Within the network latency, PDM does not tell you which + of the network segments or middle boxes is at fault. + + What PDM will tell you is whether the problem is in the network or + the server. In our experience, there is often a different group which + is involved to troubleshoot the problem depending on the nature of + the problem. That is, the problem may be escalated to the + application developers or the team that deals with the routers and + infrastructure. Both the network group and the application group + have quite a few specialized tools at their disposal to further + investigate their own areas. What is missing is the first step, + which PDM provides. + + In our experience, valuable time is often lost at this first stage of + triage. PDM is expected to reduce this time substantially. 1.5 PDM Works in Collaboration with Other Headers The purpose of the PDM is not to supplant all the variables present in all other headers but to provide data which is not available or very difficult to get. The way PDM would be used is by a technician (or tool) looking at a packet capture. Within the packet capture, they would have available to them the layer 2 header, IP header (v6 or v4), TCP, UCP, ICMP, SCTP or other headers. All information would be looked at together to make sense of the packet flow. The @@ -577,27 +607,54 @@ transport layer (TCP, UDP, etc) ports etc in the inner header, but will be specific to the ESP flow. If PDM information for the inner packet is desired, the original host sending the inner packet needs to put PDM header in the tunneled packet, and then the PDM information will be specific for that stream. 3.5 Implementation Considerations +3.5.1 PDM Activation + The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off. PDM MUST NOT be turned on merely if a packet is received with a PDM header. The received packet could be spoofed by another device. +3.5.2 PDM Timestamps + + The PDM timestamps are intended to isolate wire time from server or + host time, but may necessarily attribute some host processing time to + network latency. + + RFC2330 [RFC2330] "Framework for IP Performance Metrics" describes + two notions of wire time in section 10.2. These notions are only + defined in terms of an Internet host H observing an Internet link L + at a particular location: + + + For a given IP packet P, the 'wire arrival time' of P at H on L + is the first time T at which any bit of P has appeared at H's + observational position on L. + + + For a given IP packet P, the 'wire exit time' of P at H on L is + the first time T at which all the bits of P have appeared at H's + observational position on L. + + This specification does not define the exact H's observing position + on L. That is left for the deployment setups to define. However, the + position where PDM timestamps are taken SHOULD be as close to the + physical network interface as possible. Not all implementations will + be able to achieve the ideal level of measurement. + 3.6 Dynamic Configuration Options If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to change the configuration setting as needed. If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP @@ -748,29 +804,32 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. - [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For - Values In the Internet Protocol and Related Headers", BCP 37, RFC + [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines + For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 6.2 Informative References + [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, + "Framework for IP Performance Metrics", RFC 2330, May 1998. + [TRAM-TCPM] Trammel, B., "Encoding of Time Intervals for the TCP Timestamp Option-01", Internet Draft, July 2013. [Work in Progress] Appendix A : Timing Time Differential Calculations The time counter in a CPU is a binary whole number, representing a number of milliseconds (msec), microseconds (usec) or even picoseconds (psec). Representing one of these values as attoseconds (asec) means multiplying by 10 raised to some exponent. Refer to this table of equalities: @@ -1080,22 +1140,22 @@ example, a TCP flow will do this, per RFC1122 [RFC1122] Section- 4.2.3. Packet Sender PSN PSN Delta Time Delta Time This Packet Last Recvd Last Recvd Last Sent ===================================================================== 1 Server 1 0 0 0 2 Server 2 0 0 5 3 Client 1 2 20 0 4 Server 3 1 10 15 - How might this be used? + How might this be used? Notice that in packet 3, the client has a value of Delta Time Last received of 20. Recall that Delta Time Last Received is the Send time of packet 3 - receive time of packet 2. So, what does one know now? In this case, Delta Time Last Received is the processing time for the Client to send the next packet. How to interpret this depends on what is actually being sent. Remember, PDM is not being used in isolation, but to supplement the fields found in other headers. Let's take some examples: @@ -1238,21 +1298,22 @@ Bytes RTT Bytes Bytes New Overhead in Packet Per Microsec in PDM RTT ===================================================================== 1000 20 micro 50 16 20.320 .320 micro Acknowledgments The authors would like to thank Keven Haining, Al Morton, Brian Trammel, David Boyes, Bill Jouris, Richard Scheffenegger, and Rick Troth for their comments and assistance. We would also like to thank - Tero Kivinen for his detailed and perceptive review. + Tero Kivinen and Jouni Korhonen for their detailed and perceptive + reviews. 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