--- 1/draft-ietf-ippm-6man-pdm-option-05.txt 2016-09-23 08:16:53.390187320 -0700 +++ 2/draft-ietf-ippm-6man-pdm-option-06.txt 2016-09-23 08:16:53.450189124 -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: March 18, 2017 September 14, 2016 +Expires: March 27, 2017 September 23, 2016 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option - draft-ietf-ippm-6man-pdm-option-05 + draft-ietf-ippm-6man-pdm-option-06 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. @@ -80,39 +80,39 @@ 4 Considerations of Timing Representation . . . . . . . . . . . . 12 4.1 Encoding the Delta-Time Values . . . . . . . . . . . . . . . 12 4.2 Timer registers are different on different hardware . . . . 13 4.3 Timer Units on Other Systems . . . . . . . . . . . . . . . . 13 4.4 Time Base . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 14 4.6 Limitations with this encoding method . . . . . . . . . . . 15 4.7 Lack of precision induced by timer value truncation . . . . 16 5 PDM Flow - Simple Client Server . . . . . . . . . . . . . . . . 17 5.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 6 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 6.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 21 - 6.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 22 - 6.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 23 - 7 Potential Overhead Considerations . . . . . . . . . . . . . . . 25 - 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 26 - 8.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 26 - 8.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 26 - 8.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 27 - 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 - 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 10.1 Normative References . . . . . . . . . . . . . . . . . . . 28 - 10.2 Informative References . . . . . . . . . . . . . . . . . . 28 - 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 + 5.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 5.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 6 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 6.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 22 + 6.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 23 + 6.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 24 + 7 Potential Overhead Considerations . . . . . . . . . . . . . . . 26 + 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 27 + 8.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 27 + 8.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 27 + 8.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 28 + 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28 + 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 10.1 Normative References . . . . . . . . . . . . . . . . . . . 29 + 10.2 Informative References . . . . . . . . . . . . . . . . . . 29 + 11 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 include optional information that need be examined only by the IPv6 @@ -316,24 +316,23 @@ TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 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. Time Base - 2-bit unsigned integer. It will indicate the lowest granularity - possible for this device. That is, for a value of 00 in the Time - Base field, a value of 1 in the DELTA fields indicates 1 - microsecond. + 2-bit binary value. It will indicate the lowest granularity possible + for this device. That is, for a value of 00 in the Time Base field, + a value of 1 in the DELTA fields indicates 1 millisecond. This field is being included so that a device may choose the granularity which most suits its timer ticks. That is, so that it does not have to do more work than needed to convert values required for the PDM. The possible values of Time Base are as follows: 00 - milliseconds 01 - microseconds @@ -575,24 +574,24 @@ use different binary points. For some clocks, a value of 1 could indicate 1 microsecond, whereas other clocks could use the value 1 to indicate 1 millisecond. In the former case, the binary digits to the right of that binary point measure 2**(-n) microseconds, and in the latter case, 2**(-n) milliseconds. The Time Base allows us to ensure we have a common reference, at the very least, common knowledge of what the binary point is for the transmitted values. - We define a base unit for the time. This is a 2-bit integer + We define a base unit for the time. This is a 2-bit binary value indicating the lowest granularity possible for this device. That is, for a value of 00 in the Time Base field, a value of 1 in the DELTA - fields indicates 1 picosecond. + fields indicates 1 millisecond. The possible values of Time Base are as follows: 00 - milliseconds 01 - microseconds 10 - nanoseconds 11 - picoseconds Time base is not necessarily equivalent to length of one timer tick. That is, on many, if not all, systems, the timer tick value will not @@ -615,21 +614,21 @@ 1110100011010100101001010001000000000000 <-16 bits -><-24 bits -> then, the values stored would be 1110 1000 1101 0100 in binary (E8D4 hexadecimal) for the time value and 24 for the scaling value. Note that the displayed value is the binary equivalent of 1 second expressed in picoseconds. The below table represents a device which has a TimeBase of - picosecond (or 00). The smallest and simplest value to represent is + picoseconds (or 11). The smallest and simplest value to represent is 1 picosecond; the time value stored is 1, and the scaling value is 0. Using values from the table below, we have: Time value in Encoded Scaling Delta time picoseconds value decimal -------------------------------------------------------- 1 picosecond 1 1 0 1 nanosecond 3E8 3E8 0 1 microsecond F4240 F424 4 1 millisecond 3B9ACA00 3B9A 16 @@ -642,84 +641,90 @@ Sample binary values (high order 16 bits taken) 1 psec 1 0001 1 nsec 3E8 0011 1110 1000 1 usec F4240 1111 0100 0010 0100 0000 1 msec 3B9ACA00 0011 1011 1001 1010 1100 1010 0000 0000 1 sec E8D4A51000 1110 1000 1101 0100 1010 0101 0001 0000 0000 0000 4.6 Limitations with this encoding method - If we follow the specification in [TRAM-TCPM], the size of one of - these time-interval fields is limited to this 11-bit value and five- - bit scale, so that they fit into a 16-bit space. With that + According to the specification in [TRAM-TCPM] the size of one such + time-interval field is limited to this 11-bit value and 5-bit + unsigned scale so that they fit into a 16 bit space. With that limitation, the maximum value that could be stored in 16 bits is: 11-bit value Scale ============= ====== 1111 1111 111 1 1111 - or an encoded value of 3FF and a scale value of 31. This value - corresponds to any time differential between: + or an encoded value of 3FF and a scale value of 31. This value, in + microseconds, corresponds to any time differential between: || 11 1111 1111 1000 0000 0000 0000 0000 0000 0000 0000 (binary) 3 F F 8 0 0 0 0 0 0 0 (hexadecimal) and 11 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 (binary) 3 F F F F F F F F F F (hexadecimal) - This time value, 3FFFFFFFFFF, converts to 50 days, 21 hours, 40 + The latter time value, 3FFFFFFFFFF, converts to 50 days, 21 hours 40 minutes and 46.511103 seconds. A time differential 1 microsecond - longer won't fit into 16 bits using this encoding method. + longer won't fit into 16 bits using this encoding scheme. + + Thus, PDM separates the scaling value from the interval value, giving + a full 16 bits for the interval (DELTA) values and introducing a + signed scaling value that can range from -128 to +127. 4.7 Lack of precision induced by timer value truncation - When the bit values following the first 11 significant bits are - truncated, obviously loss of precision in the value. The range of - values that will be truncated to the same encoded value is - 2**(Scale)-1 microseconds. + As PDM specifies the DELTA values as 16-bit unsigned values, any time + the precision is greater than those 16 bits, there will be truncation + of the trailing bits, with an obvious loss precision in the value. + Using microseconds as the Time Base, the range of values that would + be truncated to the same encoded value is 2**(Scale)-1 microseconds. - The smallest time differential value that will be truncated is + The smallest time differential that would be truncated is - 1000 0000 0000 = 2.048 msec + 1 0000 0000 0000 0000 = 65536 usec The value - 1000 0000 0001 = 2.049 msec + 1 0000 0000 0000 0001 = 65537 usec - will be truncated to the same encoded value, which is 400 in hex, - with a scale value of 1. With the scale value of 1, the value range - is calculated as 2**1 - 1, or 1 usec, which you can see is the + would be truncated to the same encoded value, which is 8000 in hex + with a Scale value of 1. When the Scale value is 1, the value range + is calculated as 2**1 - 1, or 1 microsecond, which you can see is the difference between these minimum and maximum values. - With that in mind, let's look at that table of delta time values + With that in mind, let's look at that table of DELTA time values again, where the Precision is the range from the smallest value corresponding to this encoded value to the largest: Time value in Encoded Delta time microseconds value Scale Precision 1 microsecond 1 1 0 0:00.000000 1 millisecond 38E 38E 0 0:00.000000 - 1 second F4240 7A1 9 0:00.000511 - 1 minute 3938700 727 15 0:00.032767 - 1 hour D693A400 6B4 21 0:02.097151 - 1 day 141DD76000 507 26 1:07.108863 - Maximum value 3FFFFFFFFFF 7FF 31 35:47.483647 - So, when measuring the delay between transmission of two packets, or - between the reception of two packets, any delay shorter than 50 days - 21 hours and change can be stored in this encoded fashion within 16 - bits. When you encode, for example, a DTN response time delay of 50 - days, 21 hours and 40 minutes, you can be assured of accuracy within - 35 minutes. + 1 second F4240 F424 4 0:00.000015 + 1 minute 3938700 3938 12 0:00.004095 + 1 hour D693A400 D693 16 0:00.065535 + 1 day 141DD76000 141D 24 0:16.777215 + Maximum value 3FFFFFFFFFF FFFF 36 19:05:19.476735 + + This maximum DELTA value is nearly 52,125 days. At the greatest + value, you can be assured of accuracy within about 19 hours. More + simply, response times in the range of a few seconds can be encoded + with a loss of precision no greater than a tenth of a millisecond. + Most importantly, response times shorter than 65.5 milliseconds can + be encoded with no loss of precision. 5 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. Each packet, in addition to the PDM contains information on the @@ -833,22 +838,22 @@ | | | | | Host | <---------- | Host | | A | | B | | | | | +----------+ +----------+ PDM Contents: PSNTP : Packet Sequence Number This Packet: 12 PSNLR : Packet Sequence Number Last Received: 25 - DELTATLR : Delta Time Last Received: 3A35 (4 seconds) - SCALEDTLR: Scale of Delta Time Last Received: 25 + DELTATLR : Delta Time Last Received: FA0 (4 seconds) + SCALEDTLR: Scale of Delta Time Last Received: 00 DELTATLS : Delta Time Last Sent: - SCALEDTLS: Scale of Delta Time Last Sent: 0 TIMEBASE : Granularity of Time: 00 (Milliseconds) The metric left to be calculated is the Round-Trip Delay. This will be calculated by Host A when it receives Packet 2. 5.4 Step 4 Packet 2 is received at Host A. Remember, its time is set to one @@ -901,22 +906,22 @@ | A | | B | | | | | +----------+ +----------+ PDM Contents: 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: 105e (12 seconds) - SCALEDTLR: Scale of Delta Time Last Received: 26 + DELTATLS : Delta Time Last Sent: 2EE0 (12 seconds) + SCALEDTLR: Scale of Delta Time Last Received: 00 TIMEBASE : Granularity of Time: 00 (Milliseconds) To calculate Two-Way Delay, any packet capture device may look at these packets and do what is necessary. 6 Other Flows What we have 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.