idnits 2.17.1 draft-ietf-ippm-6man-pdm-option-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 6, 2017) is 2628 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT N. Elkins 3 Inside Products 4 R. Hamilton 5 Chemical Abstracts Service 6 M. Ackermann 7 Intended Status: Proposed Standard BCBS Michigan 8 Expires: August 10, 2017 February 6, 2017 10 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option 11 draft-ietf-ippm-6man-pdm-option-07 13 Abstract 15 To assess performance problems, measurements based on optional 16 sequence numbers and timing may be embedded in each packet. Such 17 measurements may be interpreted in real-time or after the fact. An 18 implementation of the existing IPv6 Destination Options extension 19 header, the Performance and Diagnostic Metrics (PDM) Destination 20 Options extension header as well as the field limits, calculations, 21 and usage of the PDM in measurement are included in this document. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 50 3: This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 4 65 1.3 Need for a Packet Sequence Number . . . . . . . . . . . . . 5 66 1.4 Rationale for defined solution . . . . . . . . . . . . . . . 5 67 1.5 PDM Works in Collaboration with Other Headers . . . . . . . 6 68 1.6 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6 69 2 Measurement Information Derived from PDM . . . . . . . . . . . . 6 70 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7 71 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3 Performance and Diagnostic Metrics Destination Option Layout . . 7 73 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7 74 3.2 Performance and Diagnostic Metrics Destination Option . . . 7 75 3.2.1 PDM Layout . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 10 77 3.2.3 Considerations of this time-differential 78 representation . . . . . . . . . . . . . . . . . . . . . 10 79 3.2.3.1 Limitations with this encoding method . . . . . . . 11 80 3.2.3.2 Loss of precision induced by timer value 81 truncation . . . . . . . . . . . . . . . . . . . . . 11 82 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 12 83 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 13 84 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 13 85 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 14 86 3.5 Implementation Considerations . . . . . . . . . . . . . . . 14 87 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 15 88 3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 15 89 4 PDM Flow - Simple Client Server . . . . . . . . . . . . . . . . 15 90 4.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 4.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 4.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 4.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 4.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 5 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 5.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 20 97 5.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 21 98 5.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 22 99 6 Potential Overhead Considerations . . . . . . . . . . . . . . . 23 100 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 24 101 7.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 24 102 7.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 25 103 7.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 25 104 7.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 26 105 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26 106 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 107 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 108 9.2 Informative References . . . . . . . . . . . . . . . . . . . 27 109 Appendix A : Timing Considerations . . . . . . . . . . . . . . . . 28 110 A.1 Time Differential Calculations . . . . . . . . . . . . . . . 28 111 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 114 1 Background 116 To assess performance problems, measurements based on optional 117 sequence numbers and timing may be embedded in each packet. Such 118 measurements may be interpreted in real-time or after the fact. 120 As defined in RFC2460 [RFC2460], destination options are carried by 121 the IPv6 Destination Options extension header. Destination options 122 include optional information that need be examined only by the IPv6 123 node given as the destination address in the IPv6 header, not by 124 routers or other "middle boxes". This document specifies a new 125 destination option, the Performance and Diagnostic Metrics (PDM) 126 destination option. This document specifies the layout, field 127 limits, calculations, and usage of the PDM in measurement. 129 1.1 Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 1.2 End User Quality of Service (QoS) 137 The timing values in the PDM embedded in the packet will be used to 138 estimate QoS as experienced by an end user device. 140 For many applications, the key user performance indicator is response 141 time. When the end user is an individual, he is generally 142 indifferent to what is happening along the network; what he really 143 cares about is how long it takes to get a response back. But this is 144 not just a matter of individuals' personal convenience. In many 145 cases, rapid response is critical to the business being conducted. 147 When the end user is a device (e.g. with the Internet of Things), 148 what matters is the speed with which requested data can be 149 transferred -- specifically, whether the requested data can be 150 transferred in time to accomplish the desired actions. This can be 151 important when the relevant external conditions are subject to rapid 152 change. 154 Low, reliable and acceptable response times are not just "nice to 155 have". On many networks, the impact can be financial hardship or can 156 endanger human life. In some cities, the emergency police contact 157 system operates over IP; law enforcement, at all levels, use IP 158 networks; transactions on our stock exchanges are settled using IP 159 networks. The critical nature of such activities to our daily lives 160 and financial well-being demand a simple solution to support response 161 time measurements. 163 1.3 Need for a Packet Sequence Number 165 While performing network diagnostics of an end-to-end connection, it 166 often becomes necessary to isolate the factors along the network path 167 responsible for problems. Diagnostic data may be collected at 168 multiple places along the path (if possible), or at the source and 169 destination. Then, in post-collection processing, the diagnostic 170 data corresponding to each packet at different observation points 171 must be matched for proper measurements. A sequence number in each 172 packet provides sufficient basis for the matching process. If need 173 be, the timing fields may be used along with the sequence number to 174 ensure uniqueness. 176 This method of data collection along the path is of special use to 177 determine where packet loss or packet corruption is happening. 179 The packet sequence number needs to be unique in the context of the 180 session (5-tuple). See section 2 for a definition of 5-tuple. 182 1.4 Rationale for defined solution 184 The current IPv6 specification does not provide timing nor a similar 185 field in the IPv6 main header or in any extension header. So, we 186 define the IPv6 Performance and Diagnostic Metrics destination option 187 (PDM). 189 Advantages include: 191 1. Real measure of actual transactions. 192 2. Independence from transport layer protocols. 193 3. Ability to span organizational boundaries with consistent 194 instrumentation 195 4. No time synchronization needed between session partners 196 5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) 197 in a uniform way 199 The PDM provides the ability to determine quickly if the (latency) 200 problem is in the network or in the server (application). More 201 intermediate measurements may be needed if the host or network 202 discrimination is not sufficient. At the client, TCP/IP stack time 203 vs. application time may still need to be broken out by client 204 software. 206 1.5 PDM Works in Collaboration with Other Headers 208 The purpose of the PDM is not to supplant all the variables present 209 in all other headers but to provide data which is not available or 210 very difficult to get. The way PDM would be used is by a technician 211 (or tool) looking at a packet capture. Within the packet capture, 212 they would have available to them the layer 2 header, IP header (v6 213 or v4), TCP, UCP, ICMP, SCTP or other headers. All information 214 would be looked at together to make sense of the packet flow. The 215 technician or processing tool could analyze, report or ignore the 216 data from PDM, as necessary. 218 For an example of how PDM can help with TCP retransmit problems, 219 please look at section 8. 221 1.6 IPv6 Transition Technologies 223 In the path to full implementation of IPv6, transition technologies 224 such as translation or tunneling may be employed. The PDM header is 225 not expected to work in such scenarios. It is likely that an IPv6 226 packet containing PDM will be dropped if using IPv6 transition 227 technologies. 229 2 Measurement Information Derived from PDM 231 Each packet contains information about the sender and receiver. In IP 232 protocol, the identifying information is called a "5-tuple". 234 The 5-tuple consists of: 236 SADDR : IP address of the sender 237 SPORT : Port for sender 238 DADDR : IP address of the destination 239 DPORT : Port for destination 240 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) 242 The PDM contains the following base fields: 244 PSNTP : Packet Sequence Number This Packet 245 PSNLR : Packet Sequence Number Last Received 246 DELTATLR : Delta Time Last Received 247 DELTATLS : Delta Time Last Sent 249 Other fields for storing time scaling factors are also in the PDM and 250 will be described in section 3. 252 This information, combined with the 5-tuple, allows the measurement 253 of the following metrics: 255 1. Round-trip delay 256 2. Server delay 258 2.1 Round-Trip Delay 260 Round-trip *Network* delay is the delay for packet transfer from a 261 source host to a destination host and then back to the source host. 262 This measurement has been defined, and the advantages and 263 disadvantages discussed in "A Round-trip Delay Metric for IPPM" 264 [RFC2681]. 266 2.2 Server Delay 268 Server delay is the interval between when a packet is received by a 269 device and the first corresponding packet is sent back in response. 270 This may be "Server Processing Time". It may also be a delay caused 271 by acknowledgements. Server processing time includes the time taken 272 by the combination of the stack and application to return the 273 response. The stack delay may be related to network performance. If 274 this aggregate time is seen as a problem, and there is a need to make 275 a clear distinction between application processing time and stack 276 delay, including that caused by the network, then more client based 277 measurements are needed. 279 3 Performance and Diagnostic Metrics Destination Option Layout 281 3.1 Destination Options Header 283 The IPv6 Destination Options Header is used to carry optional 284 information that needs to be examined only by a packet's destination 285 node(s). The Destination Options Header is identified by a Next 286 Header value of 60 in the immediately preceding header and is defined 287 in RFC2460 [RFC2460]. The IPv6 Performance and Diagnostic Metrics 288 Destination Option (PDM) is an implementation of the Destination 289 Options Header. The PDM does not require time synchronization. 291 3.2 Performance and Diagnostic Metrics Destination Option 293 3.2.1 PDM Layout 295 The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) 296 contains the following fields: 298 SCALEDTLR: Scale for Delta Time Last Received 299 SCALEDTLS: Scale for Delta Time Last Sent 300 PSNTP : Packet Sequence Number This Packet 301 PSNLR : Packet Sequence Number Last Received 302 DELTATLR : Delta Time Last Received 303 DELTATLS : Delta Time Last Sent 305 The PDM destination option is encoded in type-length-value (TLV) 306 format as follows: 308 0 1 2 3 309 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Option Type | Option Length | ScaleDTLR | ScaleDTLS | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | PSN This Packet | PSN Last Received | 314 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Delta Time Last Received | Delta Time Last Sent | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Option Type 320 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 322 Option Length 324 8-bit unsigned integer. Length of the option, in octets, excluding 325 the Option Type and Option Length fields. This field MUST be set to 326 16. 328 Scale Delta Time Last Received (SCALEDTLR) 330 8-bit unsigned integer. This is the scaling value for the Delta Time 331 Last Received (DELTATLR) field. The possible values are from 0-255. 332 See Section 4 for further discussion on Timing Considerations and 333 formatting of the scaling values. 335 Scale Delta Time Last Sent (SCALEDTLS) 337 8-bit signed integer. This is the scaling value for the Delta Time 338 Last Sent (DELTATLS) field. The possible values are from 0 to 255. 340 Packet Sequence Number This Packet (PSNTP) 342 16-bit unsigned integer. This field will wrap. It is intended for 343 use while analyzing packet traces. 345 Initialized at a random number and incremented monotonically for each 346 packet of the session flow of the 5-tuple. The 5-tuple consists of 347 the source and destination IP addresses, the source and destination 348 ports, and the upper layer protocol (ex. TCP, ICMP, etc). The 349 random number initialization is intended to make it harder to spoof 350 and insert such packets. 352 Operating systems MUST implement a separate packet sequence number 353 counter per 5-tuple. Operating systems MUST NOT implement a single 354 counter for all connections. 356 Packet Sequence Number Last Received (PSNLR) 358 16-bit unsigned integer. This is the PSNTP of the packet last 359 received on the 5-tuple. 361 Delta Time Last Received (DELTATLR) 363 A 16-bit unsigned integer field. The value is set according to the 364 scale in SCALEDTLR. 366 Delta Time Last Received = (Send time packet 2 - Receive time packet 367 1) 369 Delta Time Last Sent (DELTATLS) 371 A 16-bit unsigned integer field. The value is set according to the 372 scale in SCALEDTLS. 374 Delta Time Last Sent = (Receive time packet 2 - Send time packet 1) 376 Option Type 378 The two highest-order bits of the Option Type field are encoded to 379 indicate specific processing of the option; for the PDM destination 380 option, these two bits MUST be set to 00. This indicates the 381 following processing requirements: 383 00 - skip over this option and continue processing the header. 385 RFC2460 [RFC2460] defines other values for the Option Type field. 386 These MUST NOT be used in the PDM. 388 In keeping with RFC2460 [RFC2460], the third-highest-order bit of the 389 Option Type specifies whether or not the Option Data of that option 390 can change en-route to the packet's final destination. 392 In the PDM, the value of the third-highest-order bit MUST be 0. The 393 possible values are as follows: 395 0 - Option Data does not change en-route 397 1 - Option Data may change en-route 399 The three high-order bits described above are to be treated as part 400 of the Option Type, not independent of the Option Type. That is, a 401 particular option is identified by a full 8-bit Option Type, not just 402 the low-order 5 bits of an Option Type. 404 3.2.2 Base Unit for Time Measurement 406 A time differential is always a whole number in a CPU; it is the unit 407 specification -- hours, seconds, nanoseconds -- that determine what 408 the numeric value means. For PDM, we establish the base time unit as 409 1 attosecond (asec). This allows for a common unit and scaling of the 410 time differential among all IP stacks and hardware implementations. 412 Note that we are trying to provide the ability to measure both time 413 differentials that are extremely small, and time differentials in a 414 DTN-type environment where the delays may be very great. To store a 415 time differential in just 16 bits that must range in this way will 416 require some scaling of the time differential value. 418 One issue is the conversion from the native time base in the CPU 419 hardware of whatever device is in use to some number of attoseconds. 420 It might seem this will be an astronomical number, but the conversion 421 is straightforward. It involves multiplication by an appropriate 422 power of 10 to change the value into a number of attoseconds. Then, 423 to scale the value so that it fits into DELTATLR or DELTATLS, the 424 value is shifted by of a number of bits, retaining the 16 high-order 425 or most significant bits. The number of bits shifted becomes the 426 scaling factor, stored as SCALEDTLR or SCALEDTLS, respectively. For a 427 full description of this process, including examples, please see 428 Appendix A. 430 3.2.3 Considerations of this time-differential representation 432 There are a few considerations to be taken into account with this 433 representation of a time differential. The first is whether there are 434 any limitations on the maximum or minimum time differential that can 435 be expressed using method of a delta value and a scaling factor. The 436 second is the amount of imprecision introduced by this method. 438 3.2.3.1 Limitations with this encoding method 440 The DELTATLS and DELTATLR fields store only the 16 most-significant 441 bits of the time differential value. Thus the range, excluding the 442 scaling factor, is from 0 to 65535, or a maximum of 2**16-1. This 443 method is further described in [TRAM-TCPM]. 445 The actual magnitude of the time differential is determined by the 446 scaling factor. SCALEDTLR and SCALEDTLS are 8-bit unsigned integers, 447 so the scaling factor ranges from 0 to 255. The smallest number that 448 can be represented would have a value of 1 in the delta field and a 449 value of 0 in the associated scale field. This is the representation 450 for 1 attosecond. Clearly this allows PDM to measure extremely small 451 time differentials. 453 On the other end of the scale, the maximum delta value is 65535, or 454 FFFF in hexadecimal. If the maximum scale value of 255 is used, the 455 time differential represented is 65535*2**255, which is over 3*10**55 456 years, essentially, forever. So there appears to be no real 457 limitation to the time differential that can be represented. 459 3.2.3.2 Loss of precision induced by timer value truncation 461 As PDM specifies the DELTATLR and DELTATLS values as 16-bit unsigned 462 integers, any time the precision is greater than those 16 bits, there 463 will be truncation of the trailing bits, with an accompanying loss of 464 precision in the value. 466 Any time differential value smaller than 65536 asec can be stored 467 exactly in DELTATLR or DELTATLS, because the representation of this 468 value requires at most 16 bits. 470 Since the time differential values in PDM are measured in 471 attoseconds, the range of values that would be truncated to the same 472 encoded value is 2**(Scale)-1 asec. 474 For example, the smallest time differential that would be truncated 475 to fit into a delta field is 477 1 0000 0000 0000 0000 = 65536 asec 479 This value would be encoded as a delta value of 8000 (hexadecimal) 480 with a scaling factor of 1. The value 482 1 0000 0000 0000 0001 = 65537 asec 484 would also be encoded as a delta value of 8000 with a scaling factor 485 of 1. This actually is the largest value that would be truncated to 486 that same encoded value. When the scale value is 1, the value range 487 is calculated as 2**1 - 1, or 1 asec, which you can see is the 488 difference between these minimum and maximum values. 490 The scaling factor is defined as the number of low-order bits 491 truncated to reduce the size of the resulting value so it fits into a 492 16-bit delta field. If, for example, you had to truncate 12 bits, the 493 loss of precision would depend on the bits you truncated. The range 494 of these values would be 496 0000 0000 0000 = 0 asec 497 to 498 1111 1111 1111 = 4095 asec 500 So the minimum loss of precision would be 0 asec, where the delta 501 value exactly represents the time differential, and the maximum loss 502 of precision would be 4095 asec. As stated above, the scaling factor 503 of 12 means the maximum loss of precision is 2**12-1 asec, or 4095 504 asec. 506 Compare this loss of precision to the actual time differential. The 507 range of actual time differential values that would incur this loss 508 of precision is from 510 1000 0000 0000 0000 0000 0000 0000 = 2**27 asec or 134217728 asec 511 to 512 1111 1111 1111 1111 1111 1111 1111 = 2**28-1 asec or 268435455 asec 514 Granted, these are small values, but the point is, any value between 515 these two values will have a maximum loss of precision of 4095 asec, 516 or about 0.00305% for the first value, as encoded, and at most 517 0.001526% for the second. These maximum-loss percentages are 518 consistent for all scaling values. 520 3.3 Header Placement 522 The PDM destination option follows the order defined in RFC2460 523 [RFC2460]. 525 IPv6 header 527 Hop-by-Hop Options header 529 Destination Options header <-------- 531 Routing header 533 Fragment header 534 Authentication header 536 Encapsulating Security Payload header 538 Destination Options header <------------ 540 upper-layer header 542 Note that there is a choice of where to place the Destination Options 543 header. If using ESP mode, please see section 3.4 of this document 544 for placement of the PDM Destination Options header. 546 For each IPv6 packet header, the PDM MUST NOT appear more than once. 547 However, an encapsulated packet MAY contain a separate PDM associated 548 with each encapsulated IPv6 header. 550 3.4 Header Placement Using IPSec ESP Mode 552 IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] 553 and is widely used. Section 3.1.1 of [RFC4303] discusses placement 554 of Destination Options Headers. 556 The placement of PDM is different depending on if ESP is used in 557 tunnel or transport mode. 559 3.4.1 Using ESP Transport Mode 561 Below is the diagram from [RFC4303] discussing placement of headers. 562 Note that Destination Options MAY be placed before or after ESP or 563 both. If using PDM in ESP transport mode, PDM MUST be placed after 564 the ESP header so as not to leak information. 566 BEFORE APPLYING ESP 567 --------------------------------------- 568 IPv6 | | ext hdrs | | | 569 | orig IP hdr |if present| TCP | Data | 570 --------------------------------------- 572 AFTER APPLYING ESP 573 --------------------------------------------------------- 574 IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| 575 |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| 576 --------------------------------------------------------- 577 |<--- encryption ---->| 578 |<------ integrity ------>| 580 * = if present, could be before ESP, after ESP, or both 582 3.4.2 Using ESP Tunnel Mode 584 Below is the diagram from [RFC4303] discussing placement of headers. 586 Note that Destination Options MAY be placed before or after ESP or 587 both in both the outer set of IP headers and the inner set of IP 588 headers. 590 In ESP tunnel mode, PDM MAY be placed before or after the ESP header 591 or both. 593 BEFORE APPLYING ESP 595 --------------------------------------- 596 IPv6 | | ext hdrs | | | 597 | orig IP hdr |if present| TCP | Data | 598 --------------------------------------- 600 AFTER APPLYING ESP 602 ------------------------------------------------------------ 603 IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP| 604 |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| 605 ------------------------------------------------------------ 606 |<--------- encryption ---------->| 607 |<------------ integrity ------------>| 609 * = if present, construction of outer IP hdr/extensions and 610 modification of inner IP hdr/extensions is discussed in 611 the Security Architecture document. 613 As a completely new IP packet will be made, it means that PDM 614 information for that packet does not contain any information from the 615 inner packet, i.e. the PDM information will NOT be based on the 616 transport layer (TCP, UDP, etc) ports etc in the inner header, but 617 will be specific to the ESP flow. 619 If PDM information for the inner packet is desired, the original host 620 sending the inner packet needs to put PDM header in the tunneled 621 packet, and then the PDM information will be specific for that 622 stream. 624 3.5 Implementation Considerations 626 The PDM destination options extension header MUST be explicitly 627 turned on by each stack on a host node by administrative action. The 628 default value of PDM is off. 630 PDM MUST NOT be turned on merely if a packet is received with a PDM 631 header. The received packet could be spoofed by another device. 633 3.6 Dynamic Configuration Options 635 If implemented, each operating system MUST have a default 636 configuration parameter, e.g. diag_header_sys_default_value=yes/no. 637 The operating system MAY also have a dynamic configuration option to 638 change the configuration setting as needed. 640 If the PDM destination options extension header is used, then it MAY 641 be turned on for all packets flowing through the host, applied to an 642 upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP 643 address only. These are at the discretion of the implementation. 645 As with all other destination options extension headers, the PDM is 646 for destination nodes only. As specified above, intermediate devices 647 MUST neither set nor modify this field. 649 3.6 5-tuple Aging 651 Within the operating system, metrics must be kept on a 5-tuple basis. 653 The 5-tuple is: 655 SADDR : IP address of the sender SPORT : Port for sender DADDR : IP 656 address of the destination DPORT : Port for destination PROTC : 657 Protocol for upper layer (ex. TCP, UDP, ICMP) 659 The question comes of when to stop keeping data or restarting the 660 numbering for a 5-tuple. For example, in the case of TCP, at some 661 point, the connection will terminate. Keeping data in control blocks 662 forever, will have unfortunate consequences for the operating system. 664 So, the recommendation is to use a known aging parameter such as Max 665 Segment Lifetime (MSL) as defined in Transmission Control Protocol 666 [RFC0793] to reuse or drop the control block. The choice of aging 667 parameter is left up to the implementation. 669 4 PDM Flow - Simple Client Server 671 Following is a sample simple flow for the PDM with one packet sent 672 from Host A and one packet received by Host B. The PDM does not 673 require time synchronization between Host A and Host B. The 674 calculations to derive meaningful metrics for network diagnostics are 675 shown below each packet sent or received. 677 Each packet, in addition to the PDM contains information on the 678 sender and receiver. As discussed before, a 5-tuple consists of: 680 SADDR : IP address of the sender 681 SPORT : Port for sender 682 DADDR : IP address of the destination 683 DPORT : Port for destination 684 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP) 686 It should be understood that the packet identification information is 687 in each packet. We will not repeat that in each of the following 688 steps. 690 4.1 Step 1 692 Packet 1 is sent from Host A to Host B. The time for Host A is set 693 initially to 10:00AM. 695 The time and packet sequence number are saved by the sender 696 internally. The packet sequence number and delta times are sent in 697 the packet. 699 Packet 1 701 +----------+ +----------+ 702 | | | | 703 | Host | ----------> | Host | 704 | A | | B | 705 | | | | 706 +----------+ +----------+ 708 PDM Contents: 710 PSNTP : Packet Sequence Number This Packet: 25 711 PSNLR : Packet Sequence Number Last Received: - 712 DELTATLR : Delta Time Last Received: - 713 SCALEDTLR: Scale of Delta Time Last Received: 0 714 DELTATLS : Delta Time Last Sent: - 715 SCALEDTLS: Scale of Delta Time Last Sent: 0 717 Internally, within the sender, Host A, it must keep: 719 Packet Sequence Number of the last packet sent: 25 720 Time the last packet was sent: 10:00:00 722 Note, the initial PSNTP from Host A starts at a random number. In 723 this case, 25. The time in these examples is shown in seconds for 724 the sake of simplicity. 726 4.2 Step 2 728 Packet 1 is received at Host B. Its time is set to one hour later 729 than Host A. In this case, 11:00AM 731 Internally, within the receiver, Host B, it must note: 733 Packet Sequence Number of the last packet received: 25 734 Time the last packet was received : 11:00:03 736 Note, this timestamp is in Host B time. It has nothing whatsoever to 737 do with Host A time. The Packet Sequence Number of the last packet 738 received will become PSNLR which will be sent out in the packet sent 739 by Host B in the next step. The time last received will be used to 740 calculate the DELTALR value to be sent out in the packet sent by Host 741 B in the next step. 743 4.3 Step 3 745 Packet 2 is sent by Host B to Host A. Note, the initial packet 746 sequence number (PSNTP) from Host B starts at a random number. In 747 this case, 12. Before sending the packet, Host B does a calculation 748 of deltas. Since Host B knows when it is sending the packet, and it 749 knows when it received the previous packet, it can do the following 750 calculation: 752 Sending time : packet 2 - receive time : packet 1 754 We will call the result of this calculation: Delta Time Last Received 755 (DELTATLR) 757 That is: 759 Delta Time Last Received = (Sending time: packet 2 - receive time: 760 packet 1) 762 Note, both sending time and receive time are saved internally in Host 763 B. They do not travel in the packet. Only the Delta is in the 764 packet. 766 Assume that within Host B is the following: 768 Packet Sequence Number of the last packet received: 25 769 Time the last packet was received: 11:00:03 770 Packet Sequence Number of this packet: 12 771 Time this packet is being sent: 11:00:07 772 We can now calculate a delta value to be sent out in the packet. 773 DELTATLR becomes: 775 4 seconds = 11:00:07 - 11:00:03 = 3782DACE9D900000 asec 777 This is the derived metric: Server Delay. The time and scaling 778 factor must be converted; in this case, the time differential is 779 DE0B, and the scaling factor is 2E, or 46 in decimal. Then, these 780 values, along with the packet sequence numbers will be sent to Host A 781 as follows: 783 Packet 2 785 +----------+ +----------+ 786 | | | | 787 | Host | <---------- | Host | 788 | A | | B | 789 | | | | 790 +----------+ +----------+ 792 PDM Contents: 794 PSNTP : Packet Sequence Number This Packet: 12 795 PSNLR : Packet Sequence Number Last Received: 25 796 DELTATLR : Delta Time Last Received: DE0B (4 seconds) 797 SCALEDTLR: Scale of Delta Time Last Received: 2E (46 decimal) 798 DELTATLS : Delta Time Last Sent: - 799 SCALEDTLS: Scale of Delta Time Last Sent: 0 801 The metric left to be calculated is the Round-Trip Delay. This will 802 be calculated by Host A when it receives Packet 2. 804 4.4 Step 4 806 Packet 2 is received at Host A. Remember, its time is set to one 807 hour earlier than Host B. Internally, it must note: 809 Packet Sequence Number of the last packet received: 12 810 Time the last packet was received : 10:00:12 812 Note, this timestamp is in Host A time. It has nothing whatsoever to 813 do with Host B time. 815 So, now, Host A can calculate total end-to-end time. That is: 817 End-to-End Time = Time Last Received - Time Last Sent 818 For example, packet 25 was sent by Host A at 10:00:00. Packet 12 was 819 received by Host A at 10:00:12 so: 821 End-to-End time = 10:00:12 - 10:00:00 or 12 (Server and Network RT 822 delay combined). This time may also be called total Overall Round- 823 trip time (which includes Network RTT and Host Response Time). 825 This derived metric we will call Delta Time Last Sent (DELTATLS) 827 We can now also calculate round trip delay. The formula is: 829 Round trip delay = (Delta Time Last Sent - Delta Time Last Received) 831 Or: 833 Round trip delay = 12 - 4 or 8 835 Now, the only problem is that at this point all metrics are in Host A 836 only and not exposed in a packet. To do that, we need a third packet. 838 Note: this simple example assumes one send and one receive. That 839 is done only for purposes of explaining the function of the PDM. In 840 cases where there are multiple packets returned, one would take the 841 time in the last packet in the sequence. The calculations of such 842 timings and intelligent processing is the function of post-processing 843 of the data. 845 4.5 Step 5 847 Packet 3 is sent from Host A to Host B. 849 +----------+ +----------+ 850 | | | | 851 | Host | ----------> | Host | 852 | A | | B | 853 | | | | 854 +----------+ +----------+ 856 PDM Contents: 858 PSNTP : Packet Sequence Number This Packet: 26 859 PSNLR : Packet Sequence Number Last Received: 12 860 DELTATLR : Delta Time Last Received: 0 861 SCALEDTLS: Scale of Delta Time Last Received 0 862 DELTATLS : Delta Time Last Sent: A688 (scaled value) 863 SCALEDTLR: Scale of Delta Time Last Received: 30 (48 decimal) 864 To calculate Two-Way Delay, any packet capture device may look at 865 these packets and do what is necessary. 867 5 Other Flows 869 What we have discussed so far is a simple flow with one packet sent 870 and one returned. Let's look at how PDM may be useful in other 871 types of flows. 873 5.1 PDM Flow - One Way Traffic 875 The flow on a particular session may not be a send-receive paradigm. 876 Let us consider some other situations. In the case of a one-way 877 flow, one might see the following: 879 Note: The time is expressed in generic units for simplicity. That 880 is, these values do not represent a number of attoseconds, 881 microseconds or any other real units of time. 883 Packet Sender PSN PSN Delta Time Delta Time 884 This Packet Last Recvd Last Recvd Last Sent 885 ===================================================================== 886 1 Server 1 0 0 0 887 2 Server 2 0 0 5 888 3 Server 3 0 0 12 889 4 Server 4 0 0 20 891 What does this mean and how is it useful? 893 In a one-way flow, only the Delta Time Last Sent will be seen as 894 used. Recall, Delta Time Last Sent is the difference between the 895 send of one packet from a device and the next. This is a measure of 896 throughput for the sender - according to the sender's point of view. 897 That is, it is a measure of how fast is the application itself (with 898 stack time included) able to send packets. 900 How might this be useful? If one is having a performance issue at 901 the client and sees that packet 2, for example, is sent after 5 time 902 units from the server but takes 10 times that long to arrive at the 903 destination, then one may safely conclude that there are delays in 904 the path other than at the server which may be causing the delivery 905 issue of that packet. Such delays may include the network links, 906 middle-boxes, etc. 908 Now, true one-way traffic is quite rare. What people often mean by 909 "one-way" traffic is an application such as FTP where a group of 910 packets (for example, a TCP window size worth) is sent, then the 911 sender waits for acknowledgment. This type of flow would actually 912 fall into the "multiple-send" traffic model. 914 5.2 PDM Flow - Multiple Send Traffic 916 Assume that two packets are sent for each ACK from the server. For 917 example, a TCP flow will do this, per RFC1122 [RFC1122] Section- 918 4.2.3. 920 Packet Sender PSN PSN Delta Time Delta Time 921 This Packet Last Recvd Last Recvd Last Sent 922 ===================================================================== 923 1 Server 1 0 0 0 924 2 Server 2 0 0 5 925 3 Client 1 2 20 0 926 4 Server 3 1 10 15 928 How might this be used? 930 Notice that in packet 3, the client has a value of Delta Time Last 931 received of 20. Recall that Delta Time Last Received is the Send 932 time of packet 3 - receive time of packet 2. So, what does one know 933 now? In this case, Delta Time Last Received is the processing time 934 for the Client to send the next packet. 936 How to interpret this depends on what is actually being sent. 937 Remember, PDM is not being used in isolation, but to supplement the 938 fields found in other headers. Let's take some examples: 940 1. Client is sending a standalone TCP ACK. One would find this by 941 looking at the payload length in the IPv6 header and the TCP 942 Acknowledgement field in the TCP header. So, in this case, the 943 client is taking 20 units to send back the ACK. This may or may not 944 be interesting. 946 2. Client is sending data with the packet. Again, one would find 947 this by looking at the payload length in the IPv6 header and the TCP 948 Acknowledgement field in the TCP header. So, in this case, the 949 client is taking 20 units to send back data. This may represent 950 "User Think Time". Again, this may or may not be interesting, in 951 isolation. But, if there is a performance problem receiving data at 952 the server, then taken in conjunction with RTT or other packet timing 953 information, this information may be quite interesting. 955 Of course, one also needs to look at the PSN Last Received field to 956 make sure of the interpretation of this data. That is, to make 957 sure that the Delta Last Received corresponds to the packet of 958 interest. 960 The benefits of PDM are that we have such information available in a 961 uniform manner for all applications and all protocols without 962 extensive changes required to applications. 964 5.3 PDM Flow - Multiple Send with Errors 966 Let us now look at a case of how PDM may be able to help in a case of 967 TCP retransmission and add to the information that is sent in the TCP 968 header. 970 Assume that three packets are sent with each send from the server. 972 From the server, this is what is seen. 974 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 975 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 976 ===================================================================== 977 1 Server 1 0 0 0 123 100 978 2 Server 2 0 0 5 223 100 979 3 Server 3 0 0 5 333 100 981 The client, however, does not receive all the packets. From the 982 client, this is what is seen for the packets sent from the server. 984 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 985 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 986 ===================================================================== 987 1 Server 1 0 0 0 123 100 988 2 Server 3 0 0 5 333 100 990 Let's assume that the server now retransmits the packet. 991 (Obviously, a duplicate acknowledgment sequence for fast retransmit 992 or a retransmit timeout would occur. To illustrate the point, these 993 packets are being left out.) 995 So, then if a TCP retransmission is done, then from the client, this 996 is what is seen for the packets sent from the server. 998 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 999 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 1000 ===================================================================== 1001 1 Server 4 0 0 30 223 100 1003 The server has resent the old packet 2 with TCP sequence number of 1004 223. The retransmitted packet now has a PSN This Packet value of 4. 1006 The Delta Last Sent is 30 - the time between sending the packet with 1007 PSN of 3 and this current packet. 1009 Let's say that packet 4 is lost again. Then, after some amount of 1010 time (RTO) then the packet with TCP sequence number of 223 is resent. 1012 From the client, this is what is seen for the packets sent from the 1013 server. 1015 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 1016 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 1017 ===================================================================== 1018 1 Server 5 0 0 60 223 100 1020 If now, this packet arrives at the destination, one has a very good 1021 idea that packets exist which are being sent from the server as 1022 retransmissions and not arriving at the client. This is because the 1023 PSN of the resent packet from the server is 5 rather than 4. If we 1024 had used TCP sequence number alone, we would never have seen this 1025 situation. The TCP sequence number in all situations is 223. 1027 This situation would be experienced by the user of the application 1028 (the human being actually sitting somewhere) as a "hangs" or long 1029 delay between packets. On large networks, to diagnose problems such 1030 as these where packets are lost somewhere on the network, one has to 1031 take multiple traces to find out exactly where. 1033 The first thing is to start with doing a trace at the client and the 1034 server. So, we can see if the server sent a particular packet and 1035 the client received it. If the client did not receive it, then we 1036 start tracking back to trace points at the router right after the 1037 server and the router right before the client. Did they get these 1038 packets which the server has sent? This is a time consuming 1039 activity. 1041 With PDM, we can speed up the diagnostic time because we may be able 1042 to use only the trace taken at the client to see what the server is 1043 sending. 1045 6 Potential Overhead Considerations 1047 Questions have been posed as to the potential overhead of PDM. 1048 First, PDM is entirely optional. That is, a site may choose to 1049 implement PDM or not as they wish. If they are happy with the costs 1050 of PDM vs. the benefits, then the choice should be theirs. 1052 Below is a table outlining the potential overhead in terms of 1053 additional time to deliver the response to the end user for various 1054 assumed RTTs. 1056 Bytes RTT Bytes Bytes New Overhead 1057 in Packet Per Milli in PDM RTT 1058 ===================================================================== 1059 1000 1000 milli 1 16 1016.000 16.000 milli 1060 1000 100 milli 10 16 101.600 1.600 milli 1061 1000 10 milli 100 16 10.160 .160 milli 1062 1000 1 milli 1000 16 1.016 .016 milli 1064 Below are some examples of actual RTTs for packets traversing large 1065 enterprise networks. The first example is for packets going to 1066 multiple business partners. 1068 Bytes RTT Bytes Bytes New Overhead 1069 in Packet Per Milli in PDM RTT 1070 ===================================================================== 1071 1000 17 milli 58 16 17.360 .360 milli 1073 The second example is for packets at a large enterprise customer 1074 within a data center. Notice that the scale is now in microseconds 1075 rather than milliseconds. 1077 Bytes RTT Bytes Bytes New Overhead 1078 in Packet Per Micro in PDM RTT 1079 ===================================================================== 1080 1000 20 micro 50 16 20.320 .320 micro 1082 7 Security Considerations 1084 PDM may introduce some new security weaknesses. 1086 7.1. SYN Flood and Resource Consumption Attacks 1088 PDM needs to calculate the deltas for time and keep track of the 1089 sequence numbers. This means that control blocks must be kept at the 1090 end hosts per 5-tuple. Any time a control block is kept, an 1091 attacker can try to mis-use the control blocks such that there is a 1092 compromise of the end host. 1094 PDM is used only at the end hosts and the control blocks are only 1095 kept at the end host and not at routers or middle boxes. Remember, 1096 PDM is an implementation of the Destination Option extension header. 1098 A "SYN flood" type of attack succeeds because a TCP SYN packet is 1099 small but it causes the end host to start creating a place holder for 1100 the session such that quite a bit of control block and other storage 1101 is used. This is an asynchronous type of attack in that a small 1102 amount of work by the attacker creates a large amount of work by the 1103 resource attacked. 1105 For PDM, the amount of data to be kept is quite small. That is, the 1106 control block is quite lightweight. Concerns about SYN Flood and 1107 other type of resource consumption attacks (memory, processing power, 1108 etc) can be alleviated by having a limit on the number of control 1109 block entries. 1111 We recommend that implementation of PDM SHOULD have a limit on the 1112 number of control block entries. 1114 7.2 Pervasive monitoring 1116 Since PDM passes in the clear, a concern arises as to whether the 1117 data can be used to fingerprint the system or somehow obtain 1118 information about the contents of the payload. 1120 Let us discuss fingerprinting of the end host first. It is possible 1121 that seeing the pattern of deltas or the absolute values could give 1122 some information as to the speed of the end host - that is, if it is 1123 a very fast system or an older, slow device. This may be useful to 1124 the attacker. However, if the attacker has access to PDM, the 1125 attacker also has access to the entire packet and could make such a 1126 deduction based merely on the time frames elapsed between packets 1127 WITHOUT PDM. 1129 As far as deducing the content of the payload, it appears to us that 1130 PDM is quite unhelpful in this regard. 1132 7.3 PDM as a Covert Channel 1134 PDM provides a set of fields in the packet which could be used to 1135 leak data. But, there is no real reason to suspect that PDM would 1136 be chosen rather than another part of the payload or another 1137 Extension Header. 1139 A firewall or another device could sanity check the fields within the 1140 PDM but randomly assigned sequence numbers and delta times might be 1141 expected to vary widely. The biggest problem though is how an 1142 attacker would get access to PDM in the first place to leak data. 1143 The attacker would have to either compromise the end host or have Man 1144 in the Middle (MitM). It is possible that either one could change 1145 the fields. But, then the other end host would get sequence numbers 1146 and deltas that don't make any sense. Presumably, one is using PDM 1147 and doing packet tracing for diagnostic purposes, so the changes 1148 would be obvious. It is conceivable that someone could compromise 1149 an end host and make it start sending packets with PDM without the 1150 knowledge of the host. But, again, the bigger problem is the 1151 compromise of the end host. Once that is done, the attacker 1152 probably has better ways to leak data. 1154 Having said that, an implementation SHOULD stop using PDM if it gets 1155 some number of "nonsensical" sequence numbers. 1157 7.4 Timing Attacks 1159 The fact that PDM can help in the separation of node processing time 1160 from network latency brings value to performance monitoring. Yet, it 1161 is this very characteristic of PDM which may be misused to make 1162 certain new type of timing attacks against protocols and 1163 implementations possible. 1165 Depending on the nature of the cryptographic protocol used, it may be 1166 possible to leak the long term credentials of the device. For 1167 example, if an attacker is able to create an attack which causes the 1168 enterprise to turn on PDM to diagnose the attack, then the attacker 1169 might use PDM during that debugging time to launch a timing attack 1170 against the long term keying material used by the cryptographic 1171 protocol. 1173 An implementation may want to be sure that PDM is enabled only for 1174 certain ip addresses, or only for some ports. Additionally, we 1175 recommend that the implementation SHOULD require an explicit restart 1176 of monitoring after a certain timeperiod (for example for 1 hour), to 1177 make sure that PDM is not accidently left on after debugging has been 1178 done etc. 1180 Even so, if using PDM, we introduce the concept of user "Consent to 1181 be Measured" as a pre-requisite for using PDM. Consent is common in 1182 enterprises and with some subscription services. So, if with PDM, we 1183 recommend that the user SHOULD consent to its use. 1185 8 IANA Considerations 1187 This draft requests an Option Type assignment in the Destination 1188 Options and Hop-by-Hop Options sub-registry of Internet Protocol 1189 Version 6 (IPv6) Parameters [ref to RFCs and URL below]. 1191 http://www.iana.org/assignments/ipv6-parameters/ipv6- 1192 parameters.xhtml#ipv6-parameters-2 1193 Hex Value Binary Value Description Reference 1194 act chg rest 1195 ------------------------------------------------------------------- 1196 TBD TBD Performance and [This draft] 1197 Diagnostic Metrics 1198 (PDM) 1200 9 References 1202 9.1 Normative References 1204 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1205 793, September 1981. 1207 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 1208 Communication Layers", RFC 1122, October 1989. 1210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1211 Requirement Levels", BCP 14, RFC 2119, March 1997. 1213 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1214 (IPv6) Specification", RFC 2460, December 1998. 1216 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1217 Delay Metric for IPPM", RFC 2681, September 1999. 1219 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1220 Values In the Internet Protocol and Related Headers", BCP 37, RFC 1221 2780, March 2000. 1223 [RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 1224 4303, December 2005. 1226 9.2 Informative References 1228 [TRAM-TCPM] Trammel, B., "Encoding of Time Intervals for the TCP 1229 Timestamp Option-01", Internet Draft, July 2013. [Work in Progress] 1231 Appendix A : Timing Considerations 1233 A.1 Time Differential Calculations 1235 The time counter in a CPU is a binary whole number, representing a 1236 number of milliseconds (msec), microseconds (usec) or even 1237 picoseconds (psec). Representing one of these values as attoseconds 1238 (asec) means multiplying by 10 raised to some exponent. Refer to this 1239 table of equalities: 1241 Base value = # of sec = # of asec 1000s of asec 1242 --------------- ------------- ------------- ------------- 1243 1 second 1 sec 10**18 asec 1000**6 asec 1244 1 millisecond 10**-3 sec 10**15 asec 1000**5 asec 1245 1 microsecond 10**-6 sec 10**12 asec 1000**4 asec 1246 1 nanosecond 10**-9 sec 10**9 asec 1000**3 asec 1247 1 picosecond 10**-12 sec 10**6 asec 1000**2 asec 1248 1 femtosecond 10**-15 sec 10**3 asec 1000**1 asec 1250 For example, if you have a time differential expressed in 1251 microseconds, since each microsecond is 10**12 asec, you would 1252 multiply your time value by 10**12 to obtain the number of 1253 attoseconds. If you time differential is expressed in nanoseconds, 1254 you would multiply by 10**9 to get the number of attoseconds. 1256 The result is a binary value that will need to be shortened by a 1257 number of bits so it will fit into the 16-bit PDM DELTA field. 1259 The next step is to divide by 2 until the value is contained in just 1260 16 significant bits. The exponent of the value in the last column of 1261 of the table is useful here; the initial scaling factor is that 1262 exponent multiplied by 10. This is the minimum number of low-order 1263 bits to be shifted-out or discarded. It represents dividing the time 1264 value by 1024 raised to that exponent. 1266 The resulting value may still be too large to fit into 16 bits, but 1267 can be normalized by shifting out more bits (dividing by 2) until the 1268 value fits into the 16-bit DELTA field. The number of extra bits 1269 shifted out is then added to the scaling factor. The scaling factor, 1270 the total number of low-order bits dropped, is the SCALEDTL value. 1272 For example: say an application has these start and finish timer 1273 values (hexadecimal values, in microseconds): 1275 Finish: 27C849234 usec (02:57:58.997556) 1276 -Start: 27C83F696 usec (02:57:58.957718) 1277 ========== ========= =============== 1278 Difference 9B9E usec 00.039838 sec or 39838 usec 1280 To convert this differential value to binary attoseconds, multiply 1281 the number of microseconds by 10**12. Divide by 1024**4, or simply 1282 discard 40 bits from the right. The result is 36232, or 8D88 in hex, 1283 with a scaling factor or SCALEDTL value of 40. 1285 For another example, presume the time differential is larger, say 1286 32.311072 seconds, which is 32311072 usec. Each microsecond is 10**12 1287 asec, so multiply by 10**12, giving the hexadecimal value 1288 1C067FCCAE8120000. Using the initial scaling factor of 40, drop the 1289 last 10 characters (40 bits) from that string, giving 1C067FC. This 1290 will not fit into a DELTA field, as it is 25 bits long. Shifting the 1291 value to the right another 9 bits results in a DELTA value of E033, 1292 with a resulting scaling factor of 49. 1294 When the time differential value is a small number, regardless of the 1295 time unit, the exponent trick given above is not useful in 1296 determining the proper scaling value. For example, if the time 1297 differential is 3 seconds and you want to convert that directly, you 1298 would follow this path: 1300 3 seconds = 3*10**18 asec (decimal) 1301 = 29A2241AF62C0000 asec (hexadecimal) 1303 If you just truncate the last 60 bits, you end up with a delta value 1304 of 2 and a scaling factor of 60, when what you really wanted was a 1305 delta value with more significant digits. The most precision with 1306 which you can store this value in 16 bits is A688, with a scaling 1307 factor of 46. 1309 Acknowledgments 1311 The authors would like to thank Keven Haining, Al Morton, Brian 1312 Trammel, David Boyes, Bill Jouris, Richard Scheffenegger, and Rick 1313 Troth for their comments and assistance. We would also like to thank 1314 Tero Kivinen for his detailed and perceptive review. 1316 Authors' Addresses 1318 Nalini Elkins 1319 Inside Products, Inc. 1320 36A Upper Circle 1321 Carmel Valley, CA 93924 1322 United States 1323 Phone: +1 831 659 8360 1324 Email: nalini.elkins@insidethestack.com 1325 http://www.insidethestack.com 1326 Robert M. Hamilton 1327 Chemical Abstracts Service 1328 A Division of the American Chemical Society 1329 2540 Olentangy River Road 1330 Columbus, Ohio 43202 1331 United States 1332 Phone: +1 614 447 3600 x2517 1333 Email: rhamilton@cas.org 1334 http://www.cas.org 1336 Michael S. Ackermann 1337 Blue Cross Blue Shield of Michigan 1338 P.O. Box 2888 1339 Detroit, Michigan 48231 1340 United States 1341 Phone: +1 310 460 4080 1342 Email: mackermann@bcbsm.com 1343 http://www.bcbsm.com