--- 1/draft-ietf-ippm-6man-pdm-option-09.txt 2017-05-09 09:13:31.541477705 -0700 +++ 2/draft-ietf-ippm-6man-pdm-option-10.txt 2017-05-09 09:13:31.601479127 -0700 @@ -1,31 +1,32 @@ INTERNET-DRAFT N. Elkins Inside Products R. Hamilton Chemical Abstracts Service M. Ackermann Intended Status: Proposed Standard BCBS Michigan -Expires: September 14, 2017 March 13, 2017 +Expires: November 10, 2017 May 9, 2017 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option - draft-ietf-ippm-6man-pdm-option-09 + draft-ietf-ippm-6man-pdm-option-10 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. + To assess performance problems, this document describes optional + headers embedded in each packet that provide sequence numbers and + timing information as a basis for measurements. 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. 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. @@ -52,73 +53,73 @@ (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 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 . . . . . . . . . . . . . . . . 7 - 2 Measurement Information Derived from PDM . . . . . . . . . . . . 7 - 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7 - 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 . . . . . . . . . . . . . . . . . . . . . 11 - 3.2.3.1 Limitations with this encoding method . . . . . . . 11 - 3.2.3.2 Loss of precision induced by timer value - 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 + 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.2 Rationale for defined solution . . . . . . . . . . . . . . . 5 + 1.3 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6 + 2 Measurement Information Derived from PDM . . . . . . . . . . . . 6 + 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 6 + 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 + 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 10 + 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 10 + 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 10 + 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 10 + 3.5 Implementation Considerations . . . . . . . . . . . . . . . 11 + 3.5.1 PDM Activation . . . . . . . . . . . . . . . . . . . . . 11 + 3.5.2 PDM Timestamps . . . . . . . . . . . . . . . . . . . . . 11 + 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 11 + 3.7 Information Access and Storage . . . . . . . . . . . . . . . 11 + 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 + 4.1 Resource Consumption and Resource Consumption Attacks . . . 12 + 4.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . . 12 + 4.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 13 + 4.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 13 + 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 + 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 + 6.2 Informative References . . . . . . . . . . . . . . . . . . . 15 + Appendix A: Context for PDM . . . . . . . . . . . . . . . . . . . 15 + A.1 End User Quality of Service (QoS) . . . . . . . . . . . . . 15 + A.2 Need for a Packet Sequence Number (PSN) . . . . . . . . . . 15 + A.3 Rationale for Defined Solution . . . . . . . . . . . . . . . 16 + A.4 Use PDM with Other Headers . . . . . . . . . . . . . . . . . 16 + Appendix B : Timing Considerations . . . . . . . . . . . . . . . . 17 + B.1 Timing Differential Calculations . . . . . . . . . . . . . . 17 + B.2 Considerations of this time-differential representation . . 18 + B.2.1 Limitations with this encoding method . . . . . . . . . 18 + B.2.2 Loss of precision induced by timer value truncation . . 19 + Appendix C: Sample Packet Flows . . . . . . . . . . . . . . . . . 20 + C.1 PDM Flow - Simple Client Server . . . . . . . . . . . . . . 20 + C.1.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . 21 + C.1.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 21 + C.1.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . 22 + C.1.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . 23 + C.1.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . 24 + C.2 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . 24 + C.2.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . 24 + C.2.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . 26 + C.2.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . 27 + Appendix D: Potential Overhead Considerations . . . . . . . . . . 28 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 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 @@ -128,73 +129,26 @@ destination option, the Performance and Diagnostic Metrics (PDM) destination option. This document specifies the layout, field limits, calculations, and usage of the PDM in measurement. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. -1.2 End User Quality of Service (QoS) - - The timing values in the PDM embedded in the packet will be used to - estimate QoS as experienced by an end user device. - - For many applications, the key user performance indicator is response - time. When the end user is an individual, he is generally - indifferent to what is happening along the network; what he really - cares about is how long it takes to get a response back. But this is - not just a matter of individuals' personal convenience. In many - cases, rapid response is critical to the business being conducted. - - When the end user is a device (e.g. with the Internet of Things), - what matters is the speed with which requested data can be - transferred -- specifically, whether the requested data can be - transferred in time to accomplish the desired actions. This can be - important when the relevant external conditions are subject to rapid - change. - - Low, reliable and acceptable response times are not just "nice to - have". On many networks, the impact can be financial hardship or can - endanger human life. In some cities, the emergency police contact - system operates over IP; law enforcement, at all levels, use IP - networks; transactions on our stock exchanges are settled using IP - networks. The critical nature of such activities to our daily lives - and financial well-being demand a simple solution to support response - time measurements. - -1.3 Need for a Packet Sequence Number (PSN) - - While performing network diagnostics of an end-to-end connection, it - often becomes necessary to isolate the factors along the network path - responsible for problems. Diagnostic data may be collected at - multiple places along the path (if possible), or at the source and - destination. Then, in post-collection processing, the diagnostic - data corresponding to each packet at different observation points - must be matched for proper measurements. A sequence number in each - packet provides sufficient basis for the matching process. If need - be, the timing fields may be used along with the sequence number to - ensure uniqueness. - - This method of data collection along the path is of special use to - determine where packet loss or packet corruption is happening. - - The packet sequence number needs to be unique in the context of the - session (5-tuple). See section 2 for a definition of 5-tuple. - -1.4 Rationale for defined solution +1.2 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). + field in the IPv6 main header or in any extension header. The IPv6 + Performance and Diagnostic Metrics destination option (PDM) provides + such fields. Advantages include: 1. Real measure of actual transactions. 2. Independence from transport layer protocols. 3. Ability to span organizational boundaries with consistent instrumentation. @@ -195,65 +149,27 @@ 2. Independence from transport layer protocols. 3. Ability to span organizational boundaries with consistent instrumentation. 4. No time synchronization needed between session partners 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). 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 - technician or processing tool could analyze, report or ignore the - data from PDM, as necessary. - - For an example of how PDM can help with TCP retransmit problems, - please look at section 8. + it is a fast way to do triage. For more information on background + and usage of PDM, see Appendix A. -1.6 IPv6 Transition Technologies +1.3 IPv6 Transition Technologies In the path to full implementation of IPv6, transition technologies such as translation or tunneling may be employed. The PDM header is not expected to work in such scenarios. It is likely that an IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. 2 Measurement Information Derived from PDM Each packet contains information about the sender and receiver. In IP @@ -340,20 +256,31 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN This Packet | PSN Last Received | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time Last Received | Delta Time Last Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] + In keeping with RFC2460[RFC2460], the two high order bits of the + Option Type field are encoded to indicate specific processing of the + option; for the PDM destination option, these two bits MUST be set to + 00. + + The third high order bit of the Option Type specifies whether or not + the Option Data of that option can change en-route to the packet's + final destination. + + In the PDM, the value of the third high order bit MUST be 0. + Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. Scale Delta Time Last Received (SCALEDTLR) 8-bit unsigned integer. This is the scaling value for the Delta Time Last Received (DELTATLR) field. The possible values are from 0-255. @@ -376,164 +303,63 @@ packets. Operating systems MUST implement a separate packet sequence number counter per 5-tuple. Packet Sequence Number Last Received (PSNLR) 16-bit unsigned integer. This is the PSNTP of the packet last received on the 5-tuple. + This field is initialized to 0. + Delta Time Last Received (DELTATLR) A 16-bit unsigned integer field. The value is set according to the scale in SCALEDTLR. - Delta Time Last Received = (Send time packet 2 - Receive time packet - 1) + Delta Time Last Received = (Send time packet n - Receive time packet + n-1) Delta Time Last Sent (DELTATLS) A 16-bit unsigned integer field. The value is set according to the scale in SCALEDTLS. - Delta Time Last Sent = (Receive time packet 2 - Send time packet 1) - - Option Type - - In keeping with RFC2460[RFC2460], the two high order bits of the - Option Type field are encoded to indicate specific processing of the - option; for the PDM destination option, these two bits MUST be set to - 00. - - The third high order bit of the Option Type specifies whether or not - the Option Data of that option can change en-route to the packet's - final destination. - - In the PDM, the value of the third high order bit MUST be 0. + Delta Time Last Sent = (Receive time packet n - Send time packet n-1) 3.2.2 Base Unit for Time Measurement A time differential is always a whole number in a CPU; it is the unit specification -- hours, seconds, nanoseconds -- that determine what - the numeric value means. For PDM, we establish the base time unit as - 1 attosecond (asec). This allows for a common unit and scaling of the - time differential among all IP stacks and hardware implementations. + the numeric value means. For PDM, the base time unit is 1 attosecond + (asec). This allows for a common unit and scaling of the time + differential among all IP stacks and hardware implementations. - Note that we are trying to provide the ability to measure both time - differentials that are extremely small, and time differentials in a - DTN-type environment where the delays may be very great. To store a - time differential in just 16 bits that must range in this way will - require some scaling of the time differential value. + Note that PDM provides the ability to measure both time differentials + that are extremely small, and time differentials in a DTN-type + environment where the delays may be very great. To store a time + differential in just 16 bits that must range in this way will require + some scaling of the time differential value. One issue is the conversion from the native time base in the CPU hardware of whatever device is in use to some number of attoseconds. It might seem this will be an astronomical number, but the conversion is straightforward. It involves multiplication by an appropriate power of 10 to change the value into a number of attoseconds. Then, to scale the value so that it fits into DELTATLR or DELTATLS, the value is shifted by of a number of bits, retaining the 16 high-order or most significant bits. The number of bits shifted becomes the scaling factor, stored as SCALEDTLR or SCALEDTLS, respectively. For a full description of this process, including examples, please see Appendix A. -3.2.3 Considerations of this time-differential representation - - There are a few considerations to be taken into account with this - representation of a time differential. The first is whether there are - any limitations on the maximum or minimum time differential that can - be expressed using method of a delta value and a scaling factor. The - second is the amount of imprecision introduced by this method. - -3.2.3.1 Limitations with this encoding method - - The DELTATLS and DELTATLR fields store only the 16 most-significant - bits of the time differential value. Thus the range, excluding the - scaling factor, is from 0 to 65535, or a maximum of 2**16-1. This - method is further described in [TRAM-TCPM]. - - The actual magnitude of the time differential is determined by the - scaling factor. SCALEDTLR and SCALEDTLS are 8-bit unsigned integers, - so the scaling factor ranges from 0 to 255. The smallest number that - can be represented would have a value of 1 in the delta field and a - value of 0 in the associated scale field. This is the representation - for 1 attosecond. Clearly this allows PDM to measure extremely small - time differentials. - - On the other end of the scale, the maximum delta value is 65535, or - FFFF in hexadecimal. If the maximum scale value of 255 is used, the - time differential represented is 65535*2**255, which is over 3*10**55 - years, essentially, forever. So there appears to be no real - limitation to the time differential that can be represented. - -3.2.3.2 Loss of precision induced by timer value truncation - - As PDM specifies the DELTATLR and DELTATLS values as 16-bit unsigned - integers, any time the precision is greater than those 16 bits, there - will be truncation of the trailing bits, with an accompanying loss of - precision in the value. - - Any time differential value smaller than 65536 asec can be stored - exactly in DELTATLR or DELTATLS, because the representation of this - value requires at most 16 bits. - - Since the time differential values in PDM are measured in - attoseconds, the range of values that would be truncated to the same - encoded value is 2**(Scale)-1 asec. - - For example, the smallest time differential that would be truncated - to fit into a delta field is - - 1 0000 0000 0000 0000 = 65536 asec - - This value would be encoded as a delta value of 8000 (hexadecimal) - with a scaling factor of 1. The value - - 1 0000 0000 0000 0001 = 65537 asec - - would also be encoded as a delta value of 8000 with a scaling factor - of 1. This actually is the largest value that would be truncated to - that same encoded value. When the scale value is 1, the value range - is calculated as 2**1 - 1, or 1 asec, which you can see is the - difference between these minimum and maximum values. - - The scaling factor is defined as the number of low-order bits - truncated to reduce the size of the resulting value so it fits into a - 16-bit delta field. If, for example, you had to truncate 12 bits, the - loss of precision would depend on the bits you truncated. The range - of these values would be - - 0000 0000 0000 = 0 asec - to - 1111 1111 1111 = 4095 asec - - So the minimum loss of precision would be 0 asec, where the delta - value exactly represents the time differential, and the maximum loss - of precision would be 4095 asec. As stated above, the scaling factor - of 12 means the maximum loss of precision is 2**12-1 asec, or 4095 - asec. - - Compare this loss of precision to the actual time differential. The - range of actual time differential values that would incur this loss - of precision is from - - 1000 0000 0000 0000 0000 0000 0000 = 2**27 asec or 134217728 asec - to - 1111 1111 1111 1111 1111 1111 1111 = 2**28-1 asec or 268435455 asec - - Granted, these are small values, but the point is, any value between - these two values will have a maximum loss of precision of 4095 asec, - or about 0.00305% for the first value, as encoded, and at most - 0.001526% for the second. These maximum-loss percentages are - consistent for all scaling values. - 3.3 Header Placement The PDM Destination Option is placed as defined in RFC2460 [RFC2460]. There may be a choice of where to place the Destination Options header. If using ESP mode, please see section 3.4 of this document for placement of the PDM Destination Options header. For each IPv6 packet header, the PDM MUST NOT appear more than once. However, an encapsulated packet MAY contain a separate PDM associated with each encapsulated IPv6 header. @@ -542,90 +368,39 @@ IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] and is widely used. Section 3.1.1 of [RFC4303] discusses placement of Destination Options Headers. The placement of PDM is different depending on if ESP is used in tunnel or transport mode. 3.4.1 Using ESP Transport Mode - Below is the diagram from [RFC4303] discussing placement of headers. Note that Destination Options MAY be placed before or after ESP or both. If using PDM in ESP transport mode, PDM MUST be placed after the ESP header so as not to leak information. - BEFORE APPLYING ESP - --------------------------------------- - IPv6 | | ext hdrs | | | - | orig IP hdr |if present| TCP | Data | - --------------------------------------- - - AFTER APPLYING ESP - --------------------------------------------------------- - IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| - |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| - --------------------------------------------------------- - |<--- encryption ---->| - |<------ integrity ------>| - - * = if present, could be before ESP, after ESP, or both - 3.4.2 Using ESP Tunnel Mode - Below is the diagram from [RFC4303] discussing placement of headers. - Note that Destination Options MAY be placed before or after ESP or both in both the outer set of IP headers and the inner set of IP - headers. - - In ESP tunnel mode, PDM MAY be placed before or after the ESP header - or both. - - BEFORE APPLYING ESP - - --------------------------------------- - IPv6 | | ext hdrs | | | - | orig IP hdr |if present| TCP | Data | - --------------------------------------- - - AFTER APPLYING ESP - - ------------------------------------------------------------ - IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP| - |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| - ------------------------------------------------------------ - |<--------- encryption ---------->| - |<------------ integrity ------------>| - - * = if present, construction of outer IP hdr/extensions and - modification of inner IP hdr/extensions is discussed in - the Security Architecture document. - - As a completely new IP packet will be made, it means that PDM - information for that packet does not contain any information from the - inner packet, i.e. the PDM information will NOT be based on the - 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. + headers. A tunnel endpoint that creates a new packet may decide to + use PDM independent of the use of PDM of the original packet to + enable delay measurements between the two tunnel endpoints 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. + An implementation should provide an interface to enable or disable + the use of PDM. This specification recommends having PDM off by + default. 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. @@ -643,75 +418,57 @@ 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 address only. These are at the discretion of the implementation. -3.6 5-tuple Aging - - Within the operating system, metrics must be kept on a 5-tuple basis. +3.7 Information Access and Storage - The question comes of when to stop keeping data or restarting the - numbering for a 5-tuple. For example, in the case of TCP, at some - point, the connection will terminate. Keeping data in control blocks - forever, will have unfortunate consequences for the operating system. + Measurement information provided by PDM may be made accessible for + higher layers or the user itself. Similar to activating the use of + PDM, the implementation may also provide an interface to indicate if + received - So, the recommendation is to use a known aging parameter such as Max - Segment Lifetime (MSL) as defined in Transmission Control Protocol - [RFC0793] to reuse or drop the control block. The choice of aging - parameter is left up to the implementation. + PDM information may be stored, if desired. If a packet with PDM + information is received and the information should be stored, the + upper layers may be notified. Furthermore, the implementation should + define a configurable maximum lifetime after which the information + can be removed as well as a configurable maximum amount of memory + that should be allocated for PDM information. 4 Security Considerations PDM may introduce some new security weaknesses. -4.1. SYN Flood and Resource Consumption Attacks +4.1 Resource Consumption and Resource Consumption Attacks PDM needs to calculate the deltas for time and keep track of the - sequence numbers. This means that control blocks must be kept at the - end hosts per 5-tuple. Any time a control block is kept, an - attacker can try to mis-use the control blocks such that there is a - compromise of the end host. - - PDM is used only at the end hosts and the control blocks are only - kept at the end host and not at routers or middle boxes. Remember, - PDM is an implementation of the Destination Option extension header. + sequence numbers. This means that control blocks which reside in + memory may be kept at the end hosts per 5-tuple. - A "SYN flood" type of attack succeeds because a TCP SYN packet is - small but it causes the end host to start creating a place holder for - the session such that quite a bit of control block and other storage - is used. This is an asynchronous type of attack in that a small - amount of work by the attacker creates a large amount of work by the - resource attacked. + A limit on how much memory is being used SHOULD be implemented. - For PDM, the amount of data to be kept is quite small. That is, the - control block is quite lightweight. Concerns about SYN Flood and - other type of resource consumption attacks (memory, processing power, - etc) can be alleviated by having a limit on the number of control - block entries. + Without a memory limit, any time a control block is kept in memory, + an attacker can try to mis-use the control blocks to cause excessive + resource consumption. This could be used to compromise the end host. - We recommend that implementation of PDM SHOULD have a limit on the - number of control block entries. + PDM is used only at the end hosts and memory is used only at the end + host and not at routers or middle boxes. 4.2 Pervasive monitoring Since PDM passes in the clear, a concern arises as to whether the data can be used to fingerprint the system or somehow obtain information about the contents of the payload. Let us discuss fingerprinting of the end host first. It is possible that seeing the pattern of deltas or the absolute values could give some information as to the speed of the end host - that is, if it is @@ -731,67 +488,72 @@ be chosen rather than another part of the payload or another Extension Header. A firewall or another device could sanity check the fields within the PDM but randomly assigned sequence numbers and delta times might be expected to vary widely. The biggest problem though is how an attacker would get access to PDM in the first place to leak data. The attacker would have to either compromise the end host or have Man in the Middle (MitM). It is possible that either one could change the fields. But, then the other end host would get sequence numbers - and deltas that don't make any sense. Presumably, one is using PDM - and doing packet tracing for diagnostic purposes, so the changes - would be obvious. It is conceivable that someone could compromise - an end host and make it start sending packets with PDM without the - knowledge of the host. But, again, the bigger problem is the - compromise of the end host. Once that is done, the attacker - probably has better ways to leak data. + and deltas that don't make any sense. - Having said that, an implementation SHOULD stop using PDM if it gets - some number of "nonsensical" sequence numbers. + It is conceivable that someone could compromise an end host and make + it start sending packets with PDM without the knowledge of the host. + But, again, the bigger problem is the compromise of the end host. + Once that is done, the attacker probably has better ways to leak + data. + + Having said that, if a PDM aware middle box or an implementation + detects some number of "nonsensical" sequence numbers it could take + action to block (or alert on) this traffic. 4.4 Timing Attacks The fact that PDM can help in the separation of node processing time from network latency brings value to performance monitoring. Yet, it is this very characteristic of PDM which may be misused to make certain new type of timing attacks against protocols and implementations possible. Depending on the nature of the cryptographic protocol used, it may be possible to leak the long term credentials of the device. For example, if an attacker is able to create an attack which causes the enterprise to turn on PDM to diagnose the attack, then the attacker might use PDM during that debugging time to launch a timing attack against the long term keying material used by the cryptographic protocol. An implementation may want to be sure that PDM is enabled only for - certain ip addresses, or only for some ports. Additionally, we - recommend that the implementation SHOULD require an explicit restart - of monitoring after a certain timeperiod (for example for 1 hour), to - make sure that PDM is not accidently left on after debugging has been - done etc. + certain ip addresses, or only for some ports. Additionally, the + implementation SHOULD require an explicit restart of monitoring after + a certain time period (for example for 1 hour), to make sure that PDM + is not accidentally left on after debugging has been done etc. - Even so, if using PDM, we introduce the concept of user "Consent to - be Measured" as a pre-requisite for using PDM. Consent is common in - enterprises and with some subscription services. So, if with PDM, we - recommend that the user SHOULD consent to its use. + Even so, if using PDM, a user "Consent to be Measured" SHOULD be a + pre-requisite for using PDM. Consent is common in enterprises and + with some subscription services. The actual content of "Consent to + be Measured" will differ by site but it SHOULD make clear that the + traffic is being measured for quality of service and to assist in + diagnostics as well as to make clear that there may be potential + risks of certain vulnerabilities if the traffic is captured during a + diagnostic session 5 IANA Considerations This draft requests an Option Type assignment in the Destination Options and Hop-by-Hop Options sub-registry of Internet Protocol Version 6 (IPv6) Parameters [ref to RFCs and URL below]. http://www.iana.org/assignments/ipv6-parameters/ipv6- parameters.xhtml#ipv6-parameters-2 + Hex Value Binary Value Description Reference act chg rest ------------------------------------------------------------------- TBD TBD Performance and [This draft] Diagnostic Metrics (PDM) 6 References 6.1 Normative References @@ -789,23 +551,20 @@ act chg rest ------------------------------------------------------------------- TBD TBD Performance and [This draft] Diagnostic Metrics (PDM) 6 References 6.1 Normative References - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC - 793, September 1981. - [RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989. [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 @@ -819,21 +578,96 @@ 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 +Appendix A: Context for PDM + +A.1 End User Quality of Service (QoS) + + The timing values in the PDM embedded in the packet will be used to + estimate QoS as experienced by an end user device. + + For many applications, the key user performance indicator is response + time. When the end user is an individual, he is generally + indifferent to what is happening along the network; what he really + cares about is how long it takes to get a response back. But this is + not just a matter of individuals' personal convenience. In many + cases, rapid response is critical to the business being conducted. + + Low, reliable and acceptable response times are not just "nice to + have". On many networks, the impact can be financial hardship or can + endanger human life. In some cities, the emergency police contact + system operates over IP; law enforcement, at all levels, use IP + networks; transactions on our stock exchanges are settled using IP + networks. The critical nature of such activities to our daily lives + and financial well-being demand a simple solution to support response + time measurements. + +A.2 Need for a Packet Sequence Number (PSN) + + While performing network diagnostics of an end-to-end connection, it + often becomes necessary to isolate the factors along the network path + responsible for problems. Diagnostic data may be collected at + multiple places along the path (if possible), or at the source and + destination. Then, in post-collection processing, the diagnostic + data corresponding to each packet at different observation points + must be matched for proper measurements. A sequence number in each + packet provides sufficient basis for the matching process. If need + be, the timing fields may be used along with the sequence number to + ensure uniqueness. + + This method of data collection along the path is of special use to + determine where packet loss or packet corruption is happening. + + The packet sequence number needs to be unique in the context of the + session (5-tuple). + +A.3 Rationale for Defined Solution + + 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 does tell you is whether the problem is in the network or + the server. + +A.4 Use PDM with Other Headers + + For diagnostics, one my want to use PDM with other headers (L2, L3, + etc). For example, if PDM is 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 technician or + processing tool could analyze, report or ignore the data from PDM, as + necessary. + + For an example of how PDM can help with TCP retransmit problems, + please look at Appendix C. + +Appendix B : Timing Considerations + +B.1 Timing 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: Base value = # of sec = # of asec 1000s of asec --------------- ------------- ------------- ------------- 1 second 1 sec 10**18 asec 1000**6 asec @@ -895,31 +729,122 @@ 3 seconds = 3*10**18 asec (decimal) = 29A2241AF62C0000 asec (hexadecimal) If you just truncate the last 60 bits, you end up with a delta value of 2 and a scaling factor of 60, when what you really wanted was a delta value with more significant digits. The most precision with which you can store this value in 16 bits is A688, with a scaling factor of 46. -Appendix B: Sample Packet Flows +B.2 Considerations of this time-differential representation -B.1 PDM Flow - Simple Client Server + There are a few considerations to be taken into account with this + representation of a time differential. The first is whether there are + any limitations on the maximum or minimum time differential that can + be expressed using method of a delta value and a scaling factor. The + second is the amount of imprecision introduced by this method. + +B.2.1 Limitations with this encoding method + + The DELTATLS and DELTATLR fields store only the 16 most-significant + bits of the time differential value. Thus the range, excluding the + scaling factor, is from 0 to 65535, or a maximum of 2**16-1. This + method is further described in [TRAM-TCPM]. + + The actual magnitude of the time differential is determined by the + scaling factor. SCALEDTLR and SCALEDTLS are 8-bit unsigned integers, + so the scaling factor ranges from 0 to 255. The smallest number that + can be represented would have a value of 1 in the delta field and a + value of 0 in the associated scale field. This is the representation + for 1 attosecond. Clearly this allows PDM to measure extremely small + time differentials. + + On the other end of the scale, the maximum delta value is 65535, or + FFFF in hexadecimal. If the maximum scale value of 255 is used, the + time differential represented is 65535*2**255, which is over 3*10**55 + years, essentially, forever. So there appears to be no real + limitation to the time differential that can be represented. + +B.2.2 Loss of precision induced by timer value truncation + + As PDM specifies the DELTATLR and DELTATLS values as 16-bit unsigned + integers, any time the precision is greater than those 16 bits, there + will be truncation of the trailing bits, with an accompanying loss of + precision in the value. + + Any time differential value smaller than 65536 asec can be stored + exactly in DELTATLR or DELTATLS, because the representation of this + value requires at most 16 bits. + + Since the time differential values in PDM are measured in + attoseconds, the range of values that would be truncated to the same + encoded value is 2**(Scale)-1 asec. + + For example, the smallest time differential that would be truncated + to fit into a delta field is + + 1 0000 0000 0000 0000 = 65536 asec + + This value would be encoded as a delta value of 8000 (hexadecimal) + with a scaling factor of 1. The value + + 1 0000 0000 0000 0001 = 65537 asec + + would also be encoded as a delta value of 8000 with a scaling factor + of 1. This actually is the largest value that would be truncated to + that same encoded value. When the scale value is 1, the value range + is calculated as 2**1 - 1, or 1 asec, which you can see is the + difference between these minimum and maximum values. + + The scaling factor is defined as the number of low-order bits + truncated to reduce the size of the resulting value so it fits into a + 16-bit delta field. If, for example, you had to truncate 12 bits, the + loss of precision would depend on the bits you truncated. The range + of these values would be + + 0000 0000 0000 = 0 asec + + to + 1111 1111 1111 = 4095 asec + + So the minimum loss of precision would be 0 asec, where the delta + value exactly represents the time differential, and the maximum loss + of precision would be 4095 asec. As stated above, the scaling factor + of 12 means the maximum loss of precision is 2**12-1 asec, or 4095 + asec. + + Compare this loss of precision to the actual time differential. The + range of actual time differential values that would incur this loss + of precision is from + + 1000 0000 0000 0000 0000 0000 0000 = 2**27 asec or 134217728 asec + to + 1111 1111 1111 1111 1111 1111 1111 = 2**28-1 asec or 268435455 asec + + Granted, these are small values, but the point is, any value between + these two values will have a maximum loss of precision of 4095 asec, + or about 0.00305% for the first value, as encoded, and at most + 0.001526% for the second. These maximum-loss percentages are + consistent for all scaling values. + +Appendix C: Sample Packet Flows + +C.1 PDM Flow - Simple Client Server Following is a sample simple flow for the PDM with one packet sent from Host A and one packet received by Host B. The PDM does not require time synchronization between Host A and Host B. The calculations to derive meaningful metrics for network diagnostics are shown below each packet sent or received. -B.1.1 Step 1 +C.1.1 Step 1 Packet 1 is sent from Host A to Host B. The time for Host A is set initially to 10:00AM. The time and packet sequence number are saved by the sender internally. The packet sequence number and delta times are sent in the packet. Packet 1 @@ -941,63 +866,63 @@ Internally, within the sender, Host A, it must keep: Packet Sequence Number of the last packet sent: 25 Time the last packet was sent: 10:00:00 Note, the initial PSNTP from Host A starts at a random number. In this case, 25. The time in these examples is shown in seconds for the sake of simplicity. -B.1.2 Step 2 +C.1.2 Step 2 Packet 1 is received at Host B. Its time is set to one hour later than Host A. In this case, 11:00AM Internally, within the receiver, Host B, it must note: Packet Sequence Number of the last packet received: 25 Time the last packet was received : 11:00:03 Note, this timestamp is in Host B time. It has nothing whatsoever to do with Host A time. The Packet Sequence Number of the last packet received will become PSNLR which will be sent out in the packet sent by Host B in the next step. The time last received will be used to calculate the DELTALR value to be sent out in the packet sent by Host B in the next step. -B.1.3 Step 3 +C.1.3 Step 3 Packet 2 is sent by Host B to Host A. Note, the initial packet sequence number (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 Time Last Received + The result of this calculation is called: Delta Time Last Received (DELTATLR) 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: Packet Sequence Number of the last packet received: 25 Time the last packet was received: 11:00:03 Packet Sequence Number of this packet: 12 Time this packet is being sent: 11:00:07 - We can now calculate a delta value to be sent out in the packet. + Now a delta value to be sent out in the packet can be calculated. DELTATLR becomes: 4 seconds = 11:00:07 - 11:00:03 = 3782DACE9D900000 asec This is the derived metric: Server Delay. The time and scaling factor must be converted; in this case, the time differential is DE0B, and the scaling factor is 2E, or 46 in decimal. Then, these values, along with the packet sequence numbers will be sent to Host A as follows: @@ -1015,21 +940,21 @@ PSNTP : Packet Sequence Number This Packet: 12 PSNLR : Packet Sequence Number Last Received: 25 DELTATLR : Delta Time Last Received: DE0B (4 seconds) SCALEDTLR: Scale of Delta Time Last Received: 2E (46 decimal) DELTATLS : Delta Time Last Sent: - SCALEDTLS: Scale of Delta Time Last Sent: 0 The metric left to be calculated is the Round-Trip Delay. This will be calculated by Host A when it receives Packet 2. -B.1.4 Step 4 +C.1.4 Step 4 Packet 2 is received at Host A. Remember, its time is set to one hour earlier than Host B. Internally, it must note: Packet Sequence Number of the last packet received: 12 Time the last packet was received : 10:00:12 Note, this timestamp is in Host A time. It has nothing whatsoever to do with Host B time. @@ -1039,24 +964,23 @@ 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 time = 10:00:12 - 10:00:00 or 12 (Server and Network RT delay combined). This time may also be called total Overall Round- Trip Time (RTT) which includes Network RTT and Host Response Time. This derived metric we will call Delta Time Last Sent (DELTATLS) - We can now also calculate round trip delay. The formula is: + Round trip delay can now be calculated. The formula is: Round trip delay = (Delta Time Last Sent - Delta Time Last Received) - Or: Round trip delay = 12 - 4 or 8 Now, the only problem is that at this point all metrics are in Host A only and not exposed in a packet. To do that, we need a third packet. Note: this simple example assumes one send and one receive. That is done only for purposes of explaining the function of the PDM. In cases where there are multiple packets returned, one would take the @@ -1057,21 +981,21 @@ Now, the only problem is that at this point all metrics are in Host A only and not exposed in a packet. To do that, we need a third packet. Note: this simple example assumes one send and one receive. That is done only for purposes of explaining the function of the PDM. In cases where there are multiple packets returned, one would take the time in the last packet in the sequence. The calculations of such timings and intelligent processing is the function of post-processing of the data. -B.1.5 Step 5 +C.1.5 Step 5 Packet 3 is sent from Host A to Host B. +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ @@ -1080,27 +1004,27 @@ PSNTP : Packet Sequence Number This Packet: 26 PSNLR : Packet Sequence Number Last Received: 12 DELTATLR : Delta Time Last Received: 0 SCALEDTLS: Scale of Delta Time Last Received 0 DELTATLS : Delta Time Last Sent: A688 (scaled value) SCALEDTLR: Scale of Delta Time Last Received: 30 (48 decimal) To calculate Two-Way Delay, any packet capture device may look at these packets and do what is necessary. -B.2 Other Flows +C.2 Other Flows - What we have discussed so far is a simple flow with one packet sent + What has been discussed so far is a simple flow with one packet sent and one returned. Let's look at how PDM may be useful in other types of flows. -B.2.1 PDM Flow - One Way Traffic +C.2.1 PDM Flow - One Way Traffic The flow on a particular session may not be a send-receive paradigm. Let us consider some other situations. In the case of a one-way flow, one might see the following: Note: The time is expressed in generic units for simplicity. That is, these values do not represent a number of attoseconds, microseconds or any other real units of time. Packet Sender PSN PSN Delta Time Delta Time @@ -1127,21 +1051,21 @@ the path other than at the server which may be causing the delivery issue of that packet. Such delays may include the network links, middle-boxes, etc. Now, true one-way traffic is quite rare. What people often mean by "one-way" traffic is an application such as FTP where a group of packets (for example, a TCP window size worth) is sent, then the sender waits for acknowledgment. This type of flow would actually fall into the "multiple-send" traffic model. -B.2.2 PDM Flow - Multiple Send Traffic +C.2.2 PDM Flow - Multiple Send Traffic Assume that two packets are sent for each ACK from the server. For 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 @@ -1172,25 +1097,25 @@ "User Think Time". Again, this may or may not be interesting, in isolation. But, if there is a performance problem receiving data at the server, then taken in conjunction with RTT or other packet timing information, this information may be quite interesting. Of course, one also needs to look at the PSN Last Received field to make sure of the interpretation of this data. That is, to make sure that the Delta Last Received corresponds to the packet of interest. - The benefits of PDM are that we have such information available in a + The benefits of PDM are that such information is now available in a uniform manner for all applications and all protocols without extensive changes required to applications. -B.2.3 PDM Flow - Multiple Send with Errors +C.2.3 PDM Flow - Multiple Send with Errors Let us now look at a case of how PDM may be able to help in a case of TCP retransmission and add to the information that is sent in the TCP header. Assume that three packets are sent with each send from the server. From the server, this is what is seen. Pkt Sender PSN PSN Delta Time Delta Time TCP Data @@ -1256,21 +1182,21 @@ the client received it. If the client did not receive it, then we start tracking back to trace points at the router right after the server and the router right before the client. Did they get these packets which the server has sent? This is a time consuming activity. With PDM, we can speed up the diagnostic time because we may be able to use only the trace taken at the client to see what the server is sending. -Appendix C: Potential Overhead Considerations +Appendix D: Potential Overhead Considerations One might wonder as to the potential overhead of PDM. First, PDM is entirely optional. That is, a site may choose to implement PDM or not as they wish. If they are happy with the costs of PDM vs. the benefits, then the choice should be theirs. Below is a table outlining the potential overhead in terms of additional time to deliver the response to the end user for various assumed RTTs. @@ -1293,20 +1219,25 @@ The second example is for packets at a large enterprise customer within a data center. Notice that the scale is now in microseconds rather than milliseconds. Bytes RTT Bytes Bytes New Overhead in Packet Per Microsec in PDM RTT ===================================================================== 1000 20 micro 50 16 20.320 .320 micro + As with other diagnostic tools, such as packet traces, a certain + amount of processing time will be required to create and process PDM. + Since PDM is lightweight (has only a few variables), we expect the + processing time to be minimal. + 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 and Jouni Korhonen for their detailed and perceptive reviews. Authors' Addresses