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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/