idnits 2.17.1 draft-ietf-ippm-6man-pdm-option-11.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 (June 6, 2017) is 2510 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 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 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: December 8, 2017 June 6, 2017 10 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option 11 draft-ietf-ippm-6man-pdm-option-11 13 Abstract 15 To assess performance problems, this document describes optional 16 headers embedded in each packet that provide sequence numbers and 17 timing information as a basis for measurements. Such measurements 18 may be interpreted in real-time or after the fact. An implementation 19 of the existing IPv6 Destination Options extension header, the 20 Performance and Diagnostic Metrics (PDM) Destination Options 21 extension header as well as the field limits, calculations, and usage 22 of the PDM in measurement are included in this document. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 51 3: This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1.2 Rationale for defined solution . . . . . . . . . . . . . . . 5 66 1.3 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6 67 2 Measurement Information Derived from PDM . . . . . . . . . . . . 6 68 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 6 69 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3 Performance and Diagnostic Metrics Destination Option Layout . . 8 71 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 8 72 3.2 Performance and Diagnostic Metrics Destination Option . . . 8 73 3.2.1 PDM Layout . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 10 75 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 11 76 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 11 77 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 11 78 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 11 79 3.5 Implementation Considerations . . . . . . . . . . . . . . . 12 80 3.5.1 PDM Activation . . . . . . . . . . . . . . . . . . . . . 12 81 3.5.2 PDM Timestamps . . . . . . . . . . . . . . . . . . . . . 12 82 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 12 83 3.7 Information Access and Storage . . . . . . . . . . . . . . . 12 84 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 85 4.1 Resource Consumption and Resource Consumption Attacks . . . 13 86 4.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . . 13 87 4.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 14 88 4.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 14 89 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 90 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 92 6.2 Informative References . . . . . . . . . . . . . . . . . . . 16 93 Appendix A: Context for PDM . . . . . . . . . . . . . . . . . . . 16 94 A.1 End User Quality of Service (QoS) . . . . . . . . . . . . . 16 95 A.2 Need for a Packet Sequence Number (PSN) . . . . . . . . . . 16 96 A.3 Rationale for Defined Solution . . . . . . . . . . . . . . . 17 97 A.4 Use PDM with Other Headers . . . . . . . . . . . . . . . . . 17 98 Appendix B : Timing Considerations . . . . . . . . . . . . . . . . 18 99 B.1 Timing Differential Calculations . . . . . . . . . . . . . . 18 100 B.2 Considerations of this time-differential representation . . 19 101 B.2.1 Limitations with this encoding method . . . . . . . . . 19 102 B.2.2 Loss of precision induced by timer value truncation . . 20 103 Appendix C: Sample Packet Flows . . . . . . . . . . . . . . . . . 21 104 C.1 PDM Flow - Simple Client Server . . . . . . . . . . . . . . 21 105 C.1.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 C.1.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 C.1.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . 23 108 C.1.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . 24 109 C.1.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . 25 110 C.2 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . 25 111 C.2.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . 25 112 C.2.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . 27 113 C.2.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . 28 114 Appendix D: Potential Overhead Considerations . . . . . . . . . . 29 115 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 118 1 Background 120 To assess performance problems, measurements based on optional 121 sequence numbers and timing may be embedded in each packet. Such 122 measurements may be interpreted in real-time or after the fact. 124 As defined in RFC2460 [RFC2460], destination options are carried by 125 the IPv6 Destination Options extension header. Destination options 126 include optional information that need be examined only by the IPv6 127 node given as the destination address in the IPv6 header, not by 128 routers or other "middle boxes". This document specifies a new 129 destination option, the Performance and Diagnostic Metrics (PDM) 130 destination option. This document specifies the layout, field 131 limits, calculations, and usage of the PDM in measurement. 133 1.1 Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 1.2 Rationale for defined solution 141 The current IPv6 specification does not provide timing nor a similar 142 field in the IPv6 main header or in any extension header. The IPv6 143 Performance and Diagnostic Metrics destination option (PDM) provides 144 such fields. 146 Advantages include: 148 1. Real measure of actual transactions. 150 2. Independence from transport layer protocols. 152 3. Ability to span organizational boundaries with consistent 153 instrumentation. 155 4. No time synchronization needed between session partners 157 5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) in 158 a uniform way 160 The PDM provides the ability to determine quickly if the (latency) 161 problem is in the network or in the server (application). That is, 162 it is a fast way to do triage. For more information on background 163 and usage of PDM, see Appendix A. 165 1.3 IPv6 Transition Technologies 167 In the path to full implementation of IPv6, transition technologies 168 such as translation or tunneling may be employed. It is possible 169 that an IPv6 packet containing PDM may be dropped if using IPv6 170 transition technologies. For example, an implementation using a 171 translation technique (IPv6 to IPv4) which does not support or 172 recognize the IPv6 Destination Options extension header may simply 173 drop the packet rather than translating it without the extension 174 header. 176 2 Measurement Information Derived from PDM 178 Each packet contains information about the sender and receiver. In IP 179 protocol, the identifying information is called a "5-tuple". 181 The 5-tuple consists of: 183 SADDR : IP address of the sender 184 SPORT : Port for sender 185 DADDR : IP address of the destination 186 DPORT : Port for destination 187 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) 189 The PDM contains the following base fields: 191 PSNTP : Packet Sequence Number This Packet 192 PSNLR : Packet Sequence Number Last Received 193 DELTATLR : Delta Time Last Received 194 DELTATLS : Delta Time Last Sent 196 Other fields for storing time scaling factors are also in the PDM and 197 will be described in section 3. 199 This information, combined with the 5-tuple, allows the measurement 200 of the following metrics: 202 1. Round-trip delay 203 2. Server delay 205 2.1 Round-Trip Delay 207 Round-trip *Network* delay is the delay for packet transfer from a 208 source host to a destination host and then back to the source host. 209 This measurement has been defined, and the advantages and 210 disadvantages discussed in "A Round-trip Delay Metric for IPPM" 212 [RFC2681]. 214 2.2 Server Delay 216 Server delay is the interval between when a packet is received by a 217 device and the first corresponding packet is sent back in response. 218 This may be "Server Processing Time". It may also be a delay caused 219 by acknowledgements. Server processing time includes the time taken 220 by the combination of the stack and application to return the 221 response. The stack delay may be related to network performance. If 222 this aggregate time is seen as a problem, and there is a need to make 223 a clear distinction between application processing time and stack 224 delay, including that caused by the network, then more client based 225 measurements are needed. 227 3 Performance and Diagnostic Metrics Destination Option Layout 229 3.1 Destination Options Header 231 The IPv6 Destination Options Header is used to carry optional 232 information that needs to be examined only by a packet's destination 233 node(s). The Destination Options Header is identified by a Next 234 Header value of 60 in the immediately preceding header and is defined 235 in RFC2460 [RFC2460]. The IPv6 Performance and Diagnostic Metrics 236 Destination Option (PDM) is implemented as an IPv6 Option carried in 237 the Destination Options Header. The PDM does not require time 238 synchronization. 240 3.2 Performance and Diagnostic Metrics Destination Option 242 3.2.1 PDM Layout 244 The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) 245 contains the following fields: 247 SCALEDTLR: Scale for Delta Time Last Received 248 SCALEDTLS: Scale for Delta Time Last Sent 249 PSNTP : Packet Sequence Number This Packet 250 PSNLR : Packet Sequence Number Last Received 251 DELTATLR : Delta Time Last Received 252 DELTATLS : Delta Time Last Sent 254 The alignment for PDM is per RFC2460 [RFC2460]. 256 The PDM destination option is encoded in type-length-value (TLV) 257 format as follows: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Option Type | Option Length | ScaleDTLR | ScaleDTLS | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | PSN This Packet | PSN Last Received | 265 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Delta Time Last Received | Delta Time Last Sent | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Option Type 271 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 273 In keeping with RFC2460[RFC2460], the two high order bits of the 274 Option Type field are encoded to indicate specific processing of the 275 option; for the PDM destination option, these two bits MUST be set to 276 00. 278 The third high order bit of the Option Type specifies whether or not 279 the Option Data of that option can change en-route to the packet's 280 final destination. 282 In the PDM, the value of the third high order bit MUST be 0. 284 Option Length 286 8-bit unsigned integer. Length of the option, in octets, excluding 287 the Option Type and Option Length fields. This field MUST be set to 288 10. 290 Scale Delta Time Last Received (SCALEDTLR) 292 8-bit unsigned integer. This is the scaling value for the Delta Time 293 Last Received (DELTATLR) field. The possible values are from 0-255. 294 See Section 4 for further discussion on Timing Considerations and 295 formatting of the scaling values. 297 Scale Delta Time Last Sent (SCALEDTLS) 299 8-bit signed integer. This is the scaling value for the Delta Time 300 Last Sent (DELTATLS) field. The possible values are from 0 to 255. 302 Packet Sequence Number This Packet (PSNTP) 304 16-bit unsigned integer. This field will wrap. It is intended for 305 use while analyzing packet traces. 307 Initialized at a random number and incremented monotonically for each 308 packet of the session flow of the 5-tuple. The random number 309 initialization is intended to make it harder to spoof and insert such 310 packets. 312 Operating systems MUST implement a separate packet sequence number 313 counter per 5-tuple. 315 Packet Sequence Number Last Received (PSNLR) 317 16-bit unsigned integer. This is the PSNTP of the packet last 318 received on the 5-tuple. 320 This field is initialized to 0. 322 Delta Time Last Received (DELTATLR) 324 A 16-bit unsigned integer field. The value is set according to the 325 scale in SCALEDTLR. 327 Delta Time Last Received = (Send time packet n - Receive time packet 328 n-1) 330 Delta Time Last Sent (DELTATLS) 332 A 16-bit unsigned integer field. The value is set according to the 333 scale in SCALEDTLS. 335 Delta Time Last Sent = (Receive time packet n - Send time packet n-1) 337 3.2.2 Base Unit for Time Measurement 339 A time differential is always a whole number in a CPU; it is the unit 340 specification -- hours, seconds, nanoseconds -- that determine what 341 the numeric value means. For PDM, the base time unit is 1 attosecond 342 (asec). This allows for a common unit and scaling of the time 343 differential among all IP stacks and hardware implementations. 345 Note that PDM provides the ability to measure both time differentials 346 that are extremely small, and time differentials in a 347 Delay/Disruption Tolerant Networking (DTN) environment where the 348 delays may be very great. To store a time differential in just 16 349 bits that must range in this way will require some scaling of the 350 time differential value. 352 One issue is the conversion from the native time base in the CPU 353 hardware of whatever device is in use to some number of attoseconds. 354 It might seem this will be an astronomical number, but the conversion 355 is straightforward. It involves multiplication by an appropriate 356 power of 10 to change the value into a number of attoseconds. Then, 357 to scale the value so that it fits into DELTATLR or DELTATLS, the 358 value is shifted by of a number of bits, retaining the 16 high-order 359 or most significant bits. The number of bits shifted becomes the 360 scaling factor, stored as SCALEDTLR or SCALEDTLS, respectively. For 361 additional information of this process, including examples, please 362 see Appendix A. 364 3.3 Header Placement 366 The PDM Destination Option is placed as defined in RFC2460 [RFC2460]. 367 There may be a choice of where to place the Destination Options 368 header. If using ESP mode, please see section 3.4 of this document 369 for placement of the PDM Destination Options header. 371 For each IPv6 packet header, the PDM MUST NOT appear more than once. 372 However, an encapsulated packet MAY contain a separate PDM associated 373 with each encapsulated IPv6 header. 375 3.4 Header Placement Using IPSec ESP Mode 377 IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] 378 and is widely used. Section 3.1.1 of [RFC4303] discusses placement 379 of Destination Options Headers. 381 The placement of PDM is different depending on if ESP is used in 382 tunnel or transport mode. 384 3.4.1 Using ESP Transport Mode 386 Note that Destination Options may be placed before or after ESP or 387 both. If using PDM in ESP transport mode, PDM MUST be placed after 388 the ESP header so as not to leak information. 390 3.4.2 Using ESP Tunnel Mode 392 Note that Destination Options may be placed before or after ESP or 393 both in both the outer set of IP headers and the inner set of IP 394 headers. A tunnel endpoint that creates a new packet may decide to 395 use PDM independent of the use of PDM of the original packet to 396 enable delay measurements between the two tunnel endpoints 398 3.5 Implementation Considerations 400 3.5.1 PDM Activation 402 An implementation should provide an interface to enable or disable 403 the use of PDM. This specification recommends having PDM off by 404 default. 406 PDM MUST NOT be turned on merely if a packet is received with a PDM 407 header. The received packet could be spoofed by another device. 409 3.5.2 PDM Timestamps 411 The PDM timestamps are intended to isolate wire time from server or 412 host time, but may necessarily attribute some host processing time to 413 network latency. 415 RFC2330 [RFC2330] "Framework for IP Performance Metrics" describes 416 two notions of wire time in section 10.2. These notions are only 417 defined in terms of an Internet host H observing an Internet link L 418 at a particular location: 420 + For a given IP packet P, the 'wire arrival time' of P at H on L 421 is the first time T at which any bit of P has appeared at H's 422 observational position on L. 424 + For a given IP packet P, the 'wire exit time' of P at H on L is 425 the first time T at which all the bits of P have appeared at H's 426 observational position on L. 428 This specification does not define the exact H's observing position 429 on L. That is left for the deployment setups to define. However, the 430 position where PDM timestamps are taken SHOULD be as close to the 431 physical network interface as possible. Not all implementations will 432 be able to achieve the ideal level of measurement. 434 3.6 Dynamic Configuration Options 436 If the PDM destination options extension header is used, then it MAY 437 be turned on for all packets flowing through the host, applied to an 438 upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP 439 address only. These are at the discretion of the implementation. 441 3.7 Information Access and Storage 442 Measurement information provided by PDM may be made accessible for 443 higher layers or the user itself. Similar to activating the use of 444 PDM, the implementation may also provide an interface to indicate if 445 received 447 PDM information may be stored, if desired. If a packet with PDM 448 information is received and the information should be stored, the 449 upper layers may be notified. Furthermore, the implementation should 450 define a configurable maximum lifetime after which the information 451 can be removed as well as a configurable maximum amount of memory 452 that should be allocated for PDM information. 454 4 Security Considerations 456 PDM may introduce some new security weaknesses. 458 4.1 Resource Consumption and Resource Consumption Attacks 460 PDM needs to calculate the deltas for time and keep track of the 461 sequence numbers. This means that control blocks which reside in 462 memory may be kept at the end hosts per 5-tuple. 464 A limit on how much memory is being used SHOULD be implemented. 466 Without a memory limit, any time a control block is kept in memory, 467 an attacker can try to misuse the control blocks to cause excessive 468 resource consumption. This could be used to compromise the end host. 470 PDM is used only at the end hosts and memory is used only at the end 471 host and not at routers or middle boxes. 473 4.2 Pervasive monitoring 475 Since PDM passes in the clear, a concern arises as to whether the 476 data can be used to fingerprint the system or somehow obtain 477 information about the contents of the payload. 479 Let us discuss fingerprinting of the end host first. It is possible 480 that seeing the pattern of deltas or the absolute values could give 481 some information as to the speed of the end host - that is, if it is 482 a very fast system or an older, slow device. This may be useful to 483 the attacker. However, if the attacker has access to PDM, the 484 attacker also has access to the entire packet and could make such a 485 deduction based merely on the time frames elapsed between packets 486 WITHOUT PDM. 488 As far as deducing the content of the payload, it is conceivable that 489 an attacker could attempt to deduce the type of application in use by 490 noting the server time and payload length. Having said that, some 491 encryption algorithms attempt to obfuscate the packet length to avoid 492 just such vulnerabilities. In the future, encryption algorithms may 493 wish to obfuscate the server time as well. 495 4.3 PDM as a Covert Channel 497 PDM provides a set of fields in the packet which could be used to 498 leak data. But, there is no real reason to suspect that PDM would 499 be chosen rather than another part of the payload or another 500 Extension Header. 502 A firewall or another device could sanity check the fields within the 503 PDM but randomly assigned sequence numbers and delta times might be 504 expected to vary widely. The biggest problem though is how an 505 attacker would get access to PDM in the first place to leak data. 506 The attacker would have to either compromise the end host or have Man 507 in the Middle (MitM). It is possible that either one could change 508 the fields. But, then the other end host would get sequence numbers 509 and deltas that don't make any sense. 511 It is conceivable that someone could compromise an end host and make 512 it start sending packets with PDM without the knowledge of the host. 513 But, again, the bigger problem is the compromise of the end host. 514 Once that is done, the attacker probably has better ways to leak 515 data. 517 Having said that, if a PDM aware middle box or an implementation 518 detects some number of "nonsensical" sequence numbers it could take 519 action to block to block, discard, or alert on this traffic. 521 4.4 Timing Attacks 523 The fact that PDM can help in the separation of node processing time 524 from network latency brings value to performance monitoring. Yet, it 525 is this very characteristic of PDM which may be misused to make 526 certain new type of timing attacks against protocols and 527 implementations possible. 529 Depending on the nature of the cryptographic protocol used, it may be 530 possible to leak the long term credentials of the device. For 531 example, if an attacker is able to create an attack which causes the 532 enterprise to turn on PDM to diagnose the attack, then the attacker 533 might use PDM during that debugging time to launch a timing attack 534 against the keying material used by the cryptographic protocol. 536 An implementation may want to be sure that PDM is enabled only for 537 certain ip addresses, or only for some ports. Additionally, the 538 implementation SHOULD require an explicit restart of monitoring after 539 a certain time period (for example for 1 hour), to make sure that PDM 540 is not accidentally left on after debugging has been done etc. 542 Even so, if using PDM, a user "Consent to be Measured" SHOULD be a 543 pre-requisite for using PDM. Consent is common in enterprises and 544 with some subscription services. The actual content of "Consent to 545 be Measured" will differ by site but it SHOULD make clear that the 546 traffic is being measured for quality of service and to assist in 547 diagnostics as well as to make clear that there may be potential 548 risks of certain vulnerabilities if the traffic is captured during a 549 diagnostic session 551 5 IANA Considerations 553 This draft requests an Destination Option Type assignment with the 554 act bits set to 00 and the chg bit set to 0 from the Destination 555 Options and Hop-by-Hop Options sub-registry of Internet Protocol 556 Version 6 (IPv6) Parameters [ref to RFCs and URL below]. 558 http://www.iana.org/assignments/ipv6-parameters/ipv6- 559 parameters.xhtml#ipv6-parameters-2 561 Hex Value Binary Value Description Reference 562 act chg rest 563 ------------------------------------------------------------------- 564 TBD TBD Performance and [This draft] 565 Diagnostic Metrics 566 (PDM) 568 6 References 570 6.1 Normative References 572 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 573 Communication Layers", RFC 1122, October 1989. 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 579 (IPv6) Specification", RFC 2460, December 1998. 581 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 582 Delay Metric for IPPM", RFC 2681, September 1999. 584 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines 585 For Values In the Internet Protocol and Related Headers", BCP 37, RFC 586 2780, March 2000. 588 [RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 589 4303, December 2005. 591 6.2 Informative References 593 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 594 "Framework for IP Performance Metrics", RFC 2330, May 1998. 596 [TRAM-TCPM] Trammel, B., "Encoding of Time Intervals for the TCP 597 Timestamp Option-01", Internet Draft, July 2013. [Work in Progress] 599 Appendix A: Context for PDM 601 A.1 End User Quality of Service (QoS) 603 The timing values in the PDM embedded in the packet will be used to 604 estimate QoS as experienced by an end user device. 606 For many applications, the key user performance indicator is response 607 time. When the end user is an individual, he is generally 608 indifferent to what is happening along the network; what he really 609 cares about is how long it takes to get a response back. But this is 610 not just a matter of individuals' personal convenience. In many 611 cases, rapid response is critical to the business being conducted. 613 Low, reliable and acceptable response times are not just "nice to 614 have". On many networks, the impact can be financial hardship or can 615 endanger human life. In some cities, the emergency police contact 616 system operates over IP; law enforcement, at all levels, use IP 617 networks; transactions on our stock exchanges are settled using IP 618 networks. The critical nature of such activities to our daily lives 619 and financial well-being demand a simple solution to support response 620 time measurements. 622 A.2 Need for a Packet Sequence Number (PSN) 624 While performing network diagnostics of an end-to-end connection, it 625 often becomes necessary to isolate the factors along the network path 626 responsible for problems. Diagnostic data may be collected at 627 multiple places along the path (if possible), or at the source and 628 destination. Then, in post-collection processing, the diagnostic 629 data corresponding to each packet at different observation points 630 must be matched for proper measurements. A sequence number in each 631 packet provides sufficient basis for the matching process. If need 632 be, the timing fields may be used along with the sequence number to 633 ensure uniqueness. 635 This method of data collection along the path is of special use to 636 determine where packet loss or packet corruption is happening. 638 The packet sequence number needs to be unique in the context of the 639 session (5-tuple). 641 A.3 Rationale for Defined Solution 643 One of the important functions of PDM is to allow you to do quickly 644 dispatch the right set of diagnosticians. Within network or server 645 latency, there may be many components. The job of the diagnostician 646 is to rule each one out until the culprit is found. 648 How PDM fits into this diagnostic picture is that PDM will quickly 649 tell you how to escalate. PDM will point to either the network area 650 or the server area. Within the server latency, PDM does not tell 651 you if the bottleneck is in the IP stack or the application or buffer 652 allocation. Within the network latency, PDM does not tell you which 653 of the network segments or middle boxes is at fault. 655 What PDM does tell you is whether the problem is in the network or 656 the server. 658 A.4 Use PDM with Other Headers 660 For diagnostics, one my want to use PDM with other headers (L2, L3, 661 etc). For example, if PDM is used is by a technician (or tool) 662 looking at a packet capture, within the packet capture, they would 663 have available to them the layer 2 header, IP header (v6 or v4), TCP, 664 UCP, ICMP, SCTP or other headers. All information would be looked 665 at together to make sense of the packet flow. The technician or 666 processing tool could analyze, report or ignore the data from PDM, as 667 necessary. 669 For an example of how PDM can help with TCP retransmit problems, 670 please look at Appendix C. 672 Appendix B : Timing Considerations 674 B.1 Timing Differential Calculations 676 The time counter in a CPU is a binary whole number, representing a 677 number of milliseconds (msec), microseconds (usec) or even 678 picoseconds (psec). Representing one of these values as attoseconds 679 (asec) means multiplying by 10 raised to some exponent. Refer to this 680 table of equalities: 682 Base value = # of sec = # of asec 1000s of asec 683 --------------- ------------- ------------- ------------- 684 1 second 1 sec 10**18 asec 1000**6 asec 685 1 millisecond 10**-3 sec 10**15 asec 1000**5 asec 686 1 microsecond 10**-6 sec 10**12 asec 1000**4 asec 687 1 nanosecond 10**-9 sec 10**9 asec 1000**3 asec 688 1 picosecond 10**-12 sec 10**6 asec 1000**2 asec 689 1 femtosecond 10**-15 sec 10**3 asec 1000**1 asec 691 For example, if you have a time differential expressed in 692 microseconds, since each microsecond is 10**12 asec, you would 693 multiply your time value by 10**12 to obtain the number of 694 attoseconds. If you time differential is expressed in nanoseconds, 695 you would multiply by 10**9 to get the number of attoseconds. 697 The result is a binary value that will need to be shortened by a 698 number of bits so it will fit into the 16-bit PDM DELTA field. 700 The next step is to divide by 2 until the value is contained in just 701 16 significant bits. The exponent of the value in the last column of 702 of the table is useful here; the initial scaling factor is that 703 exponent multiplied by 10. This is the minimum number of low-order 704 bits to be shifted-out or discarded. It represents dividing the time 705 value by 1024 raised to that exponent. 707 The resulting value may still be too large to fit into 16 bits, but 708 can be normalized by shifting out more bits (dividing by 2) until the 709 value fits into the 16-bit DELTA field. The number of extra bits 710 shifted out is then added to the scaling factor. The scaling factor, 711 the total number of low-order bits dropped, is the SCALEDTL value. 713 For example: say an application has these start and finish timer 714 values (hexadecimal values, in microseconds): 716 Finish: 27C849234 usec (02:57:58.997556) 717 -Start: 27C83F696 usec (02:57:58.957718) 718 ========== ========= =============== 719 Difference 9B9E usec 00.039838 sec or 39838 usec 721 To convert this differential value to binary attoseconds, multiply 722 the number of microseconds by 10**12. Divide by 1024**4, or simply 723 discard 40 bits from the right. The result is 36232, or 8D88 in hex, 724 with a scaling factor or SCALEDTL value of 40. 726 For another example, presume the time differential is larger, say 727 32.311072 seconds, which is 32311072 usec. Each microsecond is 10**12 728 asec, so multiply by 10**12, giving the hexadecimal value 729 1C067FCCAE8120000. Using the initial scaling factor of 40, drop the 730 last 10 characters (40 bits) from that string, giving 1C067FC. This 731 will not fit into a DELTA field, as it is 25 bits long. Shifting the 732 value to the right another 9 bits results in a DELTA value of E033, 733 with a resulting scaling factor of 49. 735 When the time differential value is a small number, regardless of the 736 time unit, the exponent trick given above is not useful in 737 determining the proper scaling value. For example, if the time 738 differential is 3 seconds and you want to convert that directly, you 739 would follow this path: 741 3 seconds = 3*10**18 asec (decimal) 742 = 29A2241AF62C0000 asec (hexadecimal) 744 If you just truncate the last 60 bits, you end up with a delta value 745 of 2 and a scaling factor of 60, when what you really wanted was a 746 delta value with more significant digits. The most precision with 747 which you can store this value in 16 bits is A688, with a scaling 748 factor of 46. 750 B.2 Considerations of this time-differential representation 752 There are a few considerations to be taken into account with this 753 representation of a time differential. The first is whether there are 754 any limitations on the maximum or minimum time differential that can 755 be expressed using method of a delta value and a scaling factor. The 756 second is the amount of imprecision introduced by this method. 758 B.2.1 Limitations with this encoding method 760 The DELTATLS and DELTATLR fields store only the 16 most-significant 761 bits of the time differential value. Thus the range, excluding the 762 scaling factor, is from 0 to 65535, or a maximum of 2**16-1. This 763 method is further described in [TRAM-TCPM]. 765 The actual magnitude of the time differential is determined by the 766 scaling factor. SCALEDTLR and SCALEDTLS are 8-bit unsigned integers, 767 so the scaling factor ranges from 0 to 255. The smallest number that 768 can be represented would have a value of 1 in the delta field and a 769 value of 0 in the associated scale field. This is the representation 770 for 1 attosecond. Clearly this allows PDM to measure extremely small 771 time differentials. 773 On the other end of the scale, the maximum delta value is 65535, or 774 FFFF in hexadecimal. If the maximum scale value of 255 is used, the 775 time differential represented is 65535*2**255, which is over 3*10**55 776 years, essentially, forever. So there appears to be no real 777 limitation to the time differential that can be represented. 779 B.2.2 Loss of precision induced by timer value truncation 781 As PDM specifies the DELTATLR and DELTATLS values as 16-bit unsigned 782 integers, any time the precision is greater than those 16 bits, there 783 will be truncation of the trailing bits, with an accompanying loss of 784 precision in the value. 786 Any time differential value smaller than 65536 asec can be stored 787 exactly in DELTATLR or DELTATLS, because the representation of this 788 value requires at most 16 bits. 790 Since the time differential values in PDM are measured in 791 attoseconds, the range of values that would be truncated to the same 792 encoded value is 2**(Scale)-1 asec. 794 For example, the smallest time differential that would be truncated 795 to fit into a delta field is 797 1 0000 0000 0000 0000 = 65536 asec 799 This value would be encoded as a delta value of 8000 (hexadecimal) 800 with a scaling factor of 1. The value 802 1 0000 0000 0000 0001 = 65537 asec 804 would also be encoded as a delta value of 8000 with a scaling factor 805 of 1. This actually is the largest value that would be truncated to 806 that same encoded value. When the scale value is 1, the value range 807 is calculated as 2**1 - 1, or 1 asec, which you can see is the 808 difference between these minimum and maximum values. 810 The scaling factor is defined as the number of low-order bits 811 truncated to reduce the size of the resulting value so it fits into a 812 16-bit delta field. If, for example, you had to truncate 12 bits, the 813 loss of precision would depend on the bits you truncated. The range 814 of these values would be 816 0000 0000 0000 = 0 asec 818 to 819 1111 1111 1111 = 4095 asec 821 So the minimum loss of precision would be 0 asec, where the delta 822 value exactly represents the time differential, and the maximum loss 823 of precision would be 4095 asec. As stated above, the scaling factor 824 of 12 means the maximum loss of precision is 2**12-1 asec, or 4095 825 asec. 827 Compare this loss of precision to the actual time differential. The 828 range of actual time differential values that would incur this loss 829 of precision is from 831 1000 0000 0000 0000 0000 0000 0000 = 2**27 asec or 134217728 asec 832 to 833 1111 1111 1111 1111 1111 1111 1111 = 2**28-1 asec or 268435455 asec 835 Granted, these are small values, but the point is, any value between 836 these two values will have a maximum loss of precision of 4095 asec, 837 or about 0.00305% for the first value, as encoded, and at most 838 0.001526% for the second. These maximum-loss percentages are 839 consistent for all scaling values. 841 Appendix C: Sample Packet Flows 843 C.1 PDM Flow - Simple Client Server 845 Following is a sample simple flow for the PDM with one packet sent 846 from Host A and one packet received by Host B. The PDM does not 847 require time synchronization between Host A and Host B. The 848 calculations to derive meaningful metrics for network diagnostics are 849 shown below each packet sent or received. 851 C.1.1 Step 1 853 Packet 1 is sent from Host A to Host B. The time for Host A is set 854 initially to 10:00AM. 856 The time and packet sequence number are saved by the sender 857 internally. The packet sequence number and delta times are sent in 858 the packet. 860 Packet 1 862 +----------+ +----------+ 863 | | | | 864 | Host | ----------> | Host | 865 | A | | B | 866 | | | | 867 +----------+ +----------+ 869 PDM Contents: 871 PSNTP : Packet Sequence Number This Packet: 25 872 PSNLR : Packet Sequence Number Last Received: - 873 DELTATLR : Delta Time Last Received: - 874 SCALEDTLR: Scale of Delta Time Last Received: 0 875 DELTATLS : Delta Time Last Sent: - 876 SCALEDTLS: Scale of Delta Time Last Sent: 0 878 Internally, within the sender, Host A, it must keep: 880 Packet Sequence Number of the last packet sent: 25 881 Time the last packet was sent: 10:00:00 883 Note, the initial PSNTP from Host A starts at a random number. In 884 this case, 25. The time in these examples is shown in seconds for 885 the sake of simplicity. 887 C.1.2 Step 2 889 Packet 1 is received at Host B. Its time is set to one hour later 890 than Host A. In this case, 11:00AM 892 Internally, within the receiver, Host B, it must note: 894 Packet Sequence Number of the last packet received: 25 895 Time the last packet was received : 11:00:03 897 Note, this timestamp is in Host B time. It has nothing whatsoever to 898 do with Host A time. The Packet Sequence Number of the last packet 899 received will become PSNLR which will be sent out in the packet sent 900 by Host B in the next step. The time last received will be used to 901 calculate the DELTALR value to be sent out in the packet sent by Host 902 B in the next step. 904 C.1.3 Step 3 906 Packet 2 is sent by Host B to Host A. Note, the initial packet 907 sequence number (PSNTP) from Host B starts at a random number. In 908 this case, 12. Before sending the packet, Host B does a calculation 909 of deltas. Since Host B knows when it is sending the packet, and it 910 knows when it received the previous packet, it can do the following 911 calculation: 913 Sending time : packet 2 - receive time : packet 1 915 The result of this calculation is called: Delta Time Last Received 916 (DELTATLR) 918 Note, both sending time and receive time are saved internally in Host 919 B. They do not travel in the packet. Only the Delta is in the 920 packet. 922 Assume that within Host B is the following: 924 Packet Sequence Number of the last packet received: 25 925 Time the last packet was received: 11:00:03 926 Packet Sequence Number of this packet: 12 927 Time this packet is being sent: 11:00:07 929 Now a delta value to be sent out in the packet can be calculated. 930 DELTATLR becomes: 932 4 seconds = 11:00:07 - 11:00:03 = 3782DACE9D900000 asec 934 This is the derived metric: Server Delay. The time and scaling 935 factor must be converted; in this case, the time differential is 936 DE0B, and the scaling factor is 2E, or 46 in decimal. Then, these 937 values, along with the packet sequence numbers will be sent to Host A 938 as follows: 940 Packet 2 942 +----------+ +----------+ 943 | | | | 944 | Host | <---------- | Host | 945 | A | | B | 946 | | | | 947 +----------+ +----------+ 949 PDM Contents: 951 PSNTP : Packet Sequence Number This Packet: 12 952 PSNLR : Packet Sequence Number Last Received: 25 953 DELTATLR : Delta Time Last Received: DE0B (4 seconds) 954 SCALEDTLR: Scale of Delta Time Last Received: 2E (46 decimal) 955 DELTATLS : Delta Time Last Sent: - 956 SCALEDTLS: Scale of Delta Time Last Sent: 0 958 The metric left to be calculated is the Round-Trip Delay. This will 959 be calculated by Host A when it receives Packet 2. 961 C.1.4 Step 4 963 Packet 2 is received at Host A. Remember, its time is set to one 964 hour earlier than Host B. Internally, it must note: 966 Packet Sequence Number of the last packet received: 12 967 Time the last packet was received : 10:00:12 969 Note, this timestamp is in Host A time. It has nothing whatsoever to 970 do with Host B time. 972 So, now, Host A can calculate total end-to-end time. That is: 974 End-to-End Time = Time Last Received - Time Last Sent 976 For example, packet 25 was sent by Host A at 10:00:00. Packet 12 was 977 received by Host A at 10:00:12 so: 979 End-to-End time = 10:00:12 - 10:00:00 or 12 (Server and Network RT 980 delay combined). This time may also be called total Overall Round- 981 Trip Time (RTT) which includes Network RTT and Host Response Time. 983 This derived metric we will call Delta Time Last Sent (DELTATLS) 985 Round trip delay can now be calculated. The formula is: 987 Round trip delay = (Delta Time Last Sent - Delta Time Last Received) 988 Or: 990 Round trip delay = 12 - 4 or 8 992 Now, the only problem is that at this point all metrics are in Host A 993 only and not exposed in a packet. To do that, we need a third packet. 995 Note: this simple example assumes one send and one receive. That 996 is done only for purposes of explaining the function of the PDM. In 997 cases where there are multiple packets returned, one would take the 998 time in the last packet in the sequence. The calculations of such 999 timings and intelligent processing is the function of post-processing 1000 of the data. 1002 C.1.5 Step 5 1004 Packet 3 is sent from Host A to Host B. 1006 +----------+ +----------+ 1007 | | | | 1008 | Host | ----------> | Host | 1009 | A | | B | 1010 | | | | 1011 +----------+ +----------+ 1013 PDM Contents: 1015 PSNTP : Packet Sequence Number This Packet: 26 1016 PSNLR : Packet Sequence Number Last Received: 12 1017 DELTATLR : Delta Time Last Received: 0 1018 SCALEDTLS: Scale of Delta Time Last Received 0 1019 DELTATLS : Delta Time Last Sent: A688 (scaled value) 1020 SCALEDTLR: Scale of Delta Time Last Received: 30 (48 decimal) 1022 To calculate Two-Way Delay, any packet capture device may look at 1023 these packets and do what is necessary. 1025 C.2 Other Flows 1027 What has been discussed so far is a simple flow with one packet sent 1028 and one returned. Let's look at how PDM may be useful in other 1029 types of flows. 1031 C.2.1 PDM Flow - One Way Traffic 1033 The flow on a particular session may not be a send-receive paradigm. 1034 Let us consider some other situations. In the case of a one-way 1035 flow, one might see the following: 1037 Note: The time is expressed in generic units for simplicity. That 1038 is, these values do not represent a number of attoseconds, 1039 microseconds or any other real units of time. 1041 Packet Sender PSN PSN Delta Time Delta Time 1042 This Packet Last Recvd Last Recvd Last Sent 1043 ===================================================================== 1044 1 Server 1 0 0 0 1045 2 Server 2 0 0 5 1046 3 Server 3 0 0 12 1047 4 Server 4 0 0 20 1049 What does this mean and how is it useful? 1051 In a one-way flow, only the Delta Time Last Sent will be seen as 1052 used. Recall, Delta Time Last Sent is the difference between the 1053 send of one packet from a device and the next. This is a measure of 1054 throughput for the sender - according to the sender's point of view. 1055 That is, it is a measure of how fast is the application itself (with 1056 stack time included) able to send packets. 1058 How might this be useful? If one is having a performance issue at 1059 the client and sees that packet 2, for example, is sent after 5 time 1060 units from the server but takes 10 times that long to arrive at the 1061 destination, then one may safely conclude that there are delays in 1062 the path other than at the server which may be causing the delivery 1063 issue of that packet. Such delays may include the network links, 1064 middle-boxes, etc. 1066 Now, true one-way traffic is quite rare. What people often mean by 1067 "one-way" traffic is an application such as FTP where a group of 1068 packets (for example, a TCP window size worth) is sent, then the 1069 sender waits for acknowledgment. This type of flow would actually 1070 fall into the "multiple-send" traffic model. 1072 C.2.2 PDM Flow - Multiple Send Traffic 1074 Assume that two packets are sent for each ACK from the server. For 1075 example, a TCP flow will do this, per RFC1122 [RFC1122] Section- 1076 4.2.3. 1078 Packet Sender PSN PSN Delta Time Delta Time 1079 This Packet Last Recvd Last Recvd Last Sent 1080 ===================================================================== 1081 1 Server 1 0 0 0 1082 2 Server 2 0 0 5 1083 3 Client 1 2 20 0 1084 4 Server 3 1 10 15 1086 How might this be used? 1088 Notice that in packet 3, the client has a value of Delta Time Last 1089 received of 20. Recall that Delta Time Last Received is the Send 1090 time of packet 3 - receive time of packet 2. So, what does one know 1091 now? In this case, Delta Time Last Received is the processing time 1092 for the Client to send the next packet. 1094 How to interpret this depends on what is actually being sent. 1095 Remember, PDM is not being used in isolation, but to supplement the 1096 fields found in other headers. Let's take some examples: 1098 1. Client is sending a standalone TCP ACK. One would find this by 1099 looking at the payload length in the IPv6 header and the TCP 1100 Acknowledgement field in the TCP header. So, in this case, the 1101 client is taking 20 units to send back the ACK. This may or may not 1102 be interesting. 1104 2. Client is sending data with the packet. Again, one would find 1105 this by looking at the payload length in the IPv6 header and the TCP 1106 Acknowledgement field in the TCP header. So, in this case, the 1107 client is taking 20 units to send back data. This may represent 1108 "User Think Time". Again, this may or may not be interesting, in 1109 isolation. But, if there is a performance problem receiving data at 1110 the server, then taken in conjunction with RTT or other packet timing 1111 information, this information may be quite interesting. 1113 Of course, one also needs to look at the PSN Last Received field to 1114 make sure of the interpretation of this data. That is, to make 1115 sure that the Delta Last Received corresponds to the packet of 1116 interest. 1118 The benefits of PDM are that such information is now available in a 1119 uniform manner for all applications and all protocols without 1120 extensive changes required to applications. 1122 C.2.3 PDM Flow - Multiple Send with Errors 1124 Let us now look at a case of how PDM may be able to help in a case of 1125 TCP retransmission and add to the information that is sent in the TCP 1126 header. 1128 Assume that three packets are sent with each send from the server. 1130 From the server, this is what is seen. 1132 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 1133 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 1134 ===================================================================== 1135 1 Server 1 0 0 0 123 100 1136 2 Server 2 0 0 5 223 100 1137 3 Server 3 0 0 5 333 100 1139 The client, however, does not receive all the packets. From the 1140 client, this is what is seen for the packets sent from the server. 1142 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 1143 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 1144 ===================================================================== 1145 1 Server 1 0 0 0 123 100 1146 2 Server 3 0 0 5 333 100 1148 Let's assume that the server now retransmits the packet. (Obviously, 1149 a duplicate acknowledgment sequence for fast retransmit or a 1150 retransmit timeout would occur. To illustrate the point, these 1151 packets are being left out.) 1153 So, then if a TCP retransmission is done, then from the client, this 1154 is what is seen for the packets sent from the server. 1156 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 1157 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 1158 ===================================================================== 1159 1 Server 4 0 0 30 223 100 1161 The server has resent the old packet 2 with TCP sequence number of 1162 223. The retransmitted packet now has a PSN This Packet value of 4. 1164 The Delta Last Sent is 30 - the time between sending the packet with 1165 PSN of 3 and this current packet. 1167 Let's say that packet 4 is lost again. Then, after some amount of 1168 time (RTO) then the packet with TCP sequence number of 223 is resent. 1170 From the client, this is what is seen for the packets sent from the 1171 server. 1173 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 1174 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 1175 ===================================================================== 1176 1 Server 5 0 0 60 223 100 1178 If now, this packet arrives at the destination, one has a very good 1179 idea that packets exist which are being sent from the server as 1180 retransmissions and not arriving at the client. This is because the 1181 PSN of the resent packet from the server is 5 rather than 4. If we 1182 had used TCP sequence number alone, we would never have seen this 1183 situation. The TCP sequence number in all situations is 223. 1185 This situation would be experienced by the user of the application 1186 (the human being actually sitting somewhere) as a "hangs" or long 1187 delay between packets. On large networks, to diagnose problems such 1188 as these where packets are lost somewhere on the network, one has to 1189 take multiple traces to find out exactly where. 1191 The first thing is to start with doing a trace at the client and the 1192 server. So, we can see if the server sent a particular packet and 1193 the client received it. If the client did not receive it, then we 1194 start tracking back to trace points at the router right after the 1195 server and the router right before the client. Did they get these 1196 packets which the server has sent? This is a time consuming 1197 activity. 1199 With PDM, we can speed up the diagnostic time because we may be able 1200 to use only the trace taken at the client to see what the server is 1201 sending. 1203 Appendix D: Potential Overhead Considerations 1205 One might wonder as to the potential overhead of PDM. First, PDM is 1206 entirely optional. That is, a site may choose to implement PDM or 1207 not as they wish. If they are happy with the costs of PDM vs. the 1208 benefits, then the choice should be theirs. 1210 Below is a table outlining the potential overhead in terms of 1211 additional time to deliver the response to the end user for various 1212 assumed RTTs. 1214 Bytes RTT Bytes Bytes New Overhead 1215 in Packet Per Millisec in PDM RTT 1216 ===================================================================== 1217 1000 1000 milli 1 16 1016.000 16.000 milli 1218 1000 100 milli 10 16 101.600 1.600 milli 1219 1000 10 milli 100 16 10.160 .160 milli 1220 1000 1 milli 1000 16 1.016 .016 milli 1222 Below are some examples of actual RTTs for packets traversing large 1223 enterprise networks. The first example is for packets going to 1224 multiple business partners. 1226 Bytes RTT Bytes Bytes New Overhead 1227 in Packet Per Millisec in PDM RTT 1228 ===================================================================== 1229 1000 17 milli 58 16 17.360 .360 milli 1231 The second example is for packets at a large enterprise customer 1232 within a data center. Notice that the scale is now in microseconds 1233 rather than milliseconds. 1235 Bytes RTT Bytes Bytes New Overhead 1236 in Packet Per Microsec in PDM RTT 1237 ===================================================================== 1238 1000 20 micro 50 16 20.320 .320 micro 1240 As with other diagnostic tools, such as packet traces, a certain 1241 amount of processing time will be required to create and process PDM. 1242 Since PDM is lightweight (has only a few variables), we expect the 1243 processing time to be minimal. 1245 Acknowledgments 1247 The authors would like to thank Keven Haining, Al Morton, Brian 1248 Trammel, David Boyes, Bill Jouris, Richard Scheffenegger, and Rick 1249 Troth for their comments and assistance. We would also like to thank 1250 Tero Kivinen and Jouni Korhonen for their detailed and perceptive 1251 reviews. 1253 Authors' Addresses 1255 Nalini Elkins 1256 Inside Products, Inc. 1257 36A Upper Circle 1258 Carmel Valley, CA 93924 1259 United States 1260 Phone: +1 831 659 8360 1261 Email: nalini.elkins@insidethestack.com 1262 http://www.insidethestack.com 1264 Robert M. Hamilton 1265 Chemical Abstracts Service 1266 A Division of the American Chemical Society 1267 2540 Olentangy River Road 1268 Columbus, Ohio 43202 1269 United States 1270 Phone: +1 614 447 3600 x2517 1271 Email: rhamilton@cas.org 1272 http://www.cas.org 1274 Michael S. Ackermann 1275 Blue Cross Blue Shield of Michigan 1276 P.O. Box 2888 1277 Detroit, Michigan 48231 1278 United States 1279 Phone: +1 310 460 4080 1280 Email: mackermann@bcbsm.com 1281 http://www.bcbsm.com