draft-ietf-ippm-6man-pdm-option-06.txt   draft-ietf-ippm-6man-pdm-option-07.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: March 27, 2017 September 23, 2016 Expires: August 10, 2017 February 6, 2017
IPv6 Performance and Diagnostic Metrics (PDM) Destination Option IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
draft-ietf-ippm-6man-pdm-option-06 draft-ietf-ippm-6man-pdm-option-07
Abstract Abstract
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. An measurements may be interpreted in real-time or after the fact. An
implementation of the existing IPv6 Destination Options extension implementation of the existing IPv6 Destination Options extension
header, the Performance and Diagnostic Metrics (PDM) Destination header, the Performance and Diagnostic Metrics (PDM) Destination
Options extension header as well as the field limits, calculations, Options extension header as well as the field limits, calculations,
and usage of the PDM in measurement are included in this document. and usage of the PDM in measurement are included in this document.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph
3: This document is subject to BCP 78 and the IETF Trust's Legal 3: This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
1.3 Need for a Packet Sequence Number . . . . . . . . . . . . . 5 1.3 Need for a Packet Sequence Number . . . . . . . . . . . . . 5
1.4 Rationale for defined solution . . . . . . . . . . . . . . . 5 1.4 Rationale for defined solution . . . . . . . . . . . . . . . 5
1.5 PDM Works in Collaboration with Other Headers . . . . . . . 6 1.5 PDM Works in Collaboration with Other Headers . . . . . . . 6
1.6 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6 1.6 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6
2 Measurement Information Derived from PDM . . . . . . . . . . . . 6 2 Measurement Information Derived from PDM . . . . . . . . . . . . 6
2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Performance and Diagnostic Metrics Destination Option Layout . . 7 3 Performance and Diagnostic Metrics Destination Option Layout . . 7
3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7
3.2 Performance and Diagnostic Metrics Destination Option . . . 7 3.2 Performance and Diagnostic Metrics Destination Option . . . 7
3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1 PDM Layout . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 11 3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 10
3.5 Implementation Considerations . . . . . . . . . . . . . . . 12 3.2.3 Considerations of this time-differential
3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 12 representation . . . . . . . . . . . . . . . . . . . . . 10
3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3.1 Limitations with this encoding method . . . . . . . 11
4 Considerations of Timing Representation . . . . . . . . . . . . 12 3.2.3.2 Loss of precision induced by timer value
4.1 Encoding the Delta-Time Values . . . . . . . . . . . . . . . 12 truncation . . . . . . . . . . . . . . . . . . . . . 11
4.2 Timer registers are different on different hardware . . . . 13 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Timer Units on Other Systems . . . . . . . . . . . . . . . . 13 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 13
4.4 Time Base . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 13
4.5 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 14 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 14
4.6 Limitations with this encoding method . . . . . . . . . . . 15 3.5 Implementation Considerations . . . . . . . . . . . . . . . 14
4.7 Lack of precision induced by timer value truncation . . . . 16 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 15
5 PDM Flow - Simple Client Server . . . . . . . . . . . . . . . . 17 3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4 PDM Flow - Simple Client Server . . . . . . . . . . . . . . . . 15
5.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 22 5 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 23 5.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 20
6.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 24 5.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 21
7 Potential Overhead Considerations . . . . . . . . . . . . . . . 26 5.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 22
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 27 6 Potential Overhead Considerations . . . . . . . . . . . . . . . 23
8.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 27 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 24
8.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 27 7.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 24
8.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 28 7.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 25
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28 7.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 25
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 26
10.1 Normative References . . . . . . . . . . . . . . . . . . . 29 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26
10.2 Informative References . . . . . . . . . . . . . . . . . . 29 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2 Informative References . . . . . . . . . . . . . . . . . . . 27
Appendix A : Timing Considerations . . . . . . . . . . . . . . . . 28
A.1 Time Differential Calculations . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
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
include optional information that need be examined only by the IPv6 include optional information that need be examined only by the IPv6
skipping to change at page 4, line 46 skipping to change at page 4, line 50
not just a matter of individuals' personal convenience. In many not just a matter of individuals' personal convenience. In many
cases, rapid response is critical to the business being conducted. cases, rapid response is critical to the business being conducted.
When the end user is a device (e.g. with the Internet of Things), 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 what matters is the speed with which requested data can be
transferred -- specifically, whether the requested data can be transferred -- specifically, whether the requested data can be
transferred in time to accomplish the desired actions. This can be transferred in time to accomplish the desired actions. This can be
important when the relevant external conditions are subject to rapid important when the relevant external conditions are subject to rapid
change. change.
Low, reliable and acceptable responses times are not just "nice to Low, reliable and acceptable response times are not just "nice to
have". On many networks, the impact can be financial hardship or have". On many networks, the impact can be financial hardship or can
endanger human life. In some cities, the emergency police contact endanger human life. In some cities, the emergency police contact
system operates over IP, law enforcement uses TCP/IP networks, system operates over IP; law enforcement, at all levels, use IP
transactions on our stock exchanges are settled using IP networks. networks; transactions on our stock exchanges are settled using IP
networks. The critical nature of such activities to our daily lives
The critical nature of such activities to our daily lives and and financial well-being demand a simple solution to support response
financial well-being demand a simple solution to support response
time measurements. time measurements.
1.3 Need for a Packet Sequence Number 1.3 Need for a Packet Sequence Number
While performing network diagnostics of an end-to-end connection, it While performing network diagnostics of an end-to-end connection, it
often becomes necessary to isolate the factors along the network path often becomes necessary to isolate the factors along the network path
responsible for problems. Diagnostic data may be collected at responsible for problems. Diagnostic data may be collected at
multiple places along the path (if possible), or at the source and multiple places along the path (if possible), or at the source and
destination. Then, in post-collection processing, the diagnostic destination. Then, in post-collection processing, the diagnostic
data corresponding to each packet at different observation points data corresponding to each packet at different observation points
skipping to change at page 5, line 45 skipping to change at page 5, line 48
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
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) 5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc)
in a uniform way in a uniform way
The PDM provides the ability to quickly determine if the (latency) The PDM provides the ability to determine quickly if the (latency)
problem is in the network or in the server (application). More problem is in the network or in the server (application). More
intermediate measurements may be needed if the host or network intermediate measurements may be needed if the host or network
discrimination is not sufficient. At the client, TCP/IP stack time discrimination is not sufficient. At the client, TCP/IP stack time
vs. applications time may still need to be broken out by client vs. application time may still need to be broken out by client
software. software.
1.5 PDM Works in Collaboration with Other Headers 1.5 PDM Works in Collaboration with Other Headers
The purpose of the PDM is not to supplant all the variables present 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 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 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, (or tool) looking at a packet capture. Within the packet capture,
they would have available to them the layer 2 header, IP header (v6 they would have available to them the layer 2 header, IP header (v6
or v4), TCP, UCP, ICMP, SCTP or other headers. All information or v4), TCP, UCP, ICMP, SCTP or other headers. All information
skipping to change at page 6, line 48 skipping to change at page 7, line 5
DPORT : Port for destination DPORT : Port for destination
PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.)
The PDM contains the following base fields: The PDM contains the following base fields:
PSNTP : Packet Sequence Number This Packet PSNTP : Packet Sequence Number This Packet
PSNLR : Packet Sequence Number Last Received PSNLR : Packet Sequence Number Last Received
DELTATLR : Delta Time Last Received DELTATLR : Delta Time Last Received
DELTATLS : Delta Time Last Sent DELTATLS : Delta Time Last Sent
Other fields for scaling and time base are also in the PDM and will Other fields for storing time scaling factors are also in the PDM and
be described in section 3. will be described in section 3.
This information, combined with the 5-tuple, allows the measurement This information, combined with the 5-tuple, allows the measurement
of the following metrics: of the following metrics:
1. Round-trip delay 1. Round-trip delay
2. Server delay 2. Server delay
2.1 Round-Trip Delay 2.1 Round-Trip Delay
Round-trip *Network* delay is the delay for packet transfer from a Round-trip *Network* delay is the delay for packet transfer from a
skipping to change at page 7, line 46 skipping to change at page 7, line 49
The IPv6 Destination Options Header is used to carry optional The IPv6 Destination Options Header is used to carry optional
information that needs to be examined only by a packet's destination information that needs to be examined only by a packet's destination
node(s). The Destination Options Header is identified by a Next node(s). The Destination Options Header is identified by a Next
Header value of 60 in the immediately preceding header and is defined Header value of 60 in the immediately preceding header and is defined
in RFC2460 [RFC2460]. The IPv6 Performance and Diagnostic Metrics in RFC2460 [RFC2460]. The IPv6 Performance and Diagnostic Metrics
Destination Option (PDM) is an implementation of the Destination Destination Option (PDM) is an implementation of the Destination
Options Header. The PDM does not require time synchronization. Options Header. The PDM does not require time synchronization.
3.2 Performance and Diagnostic Metrics Destination Option 3.2 Performance and Diagnostic Metrics Destination Option
3.2.1 PDM Layout
The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) The IPv6 Performance and Diagnostic Metrics Destination Option (PDM)
contains the following fields: contains the following fields:
TIMEBASE : Base timer unit
SCALEDTLR: Scale for Delta Time Last Received SCALEDTLR: Scale for Delta Time Last Received
SCALEDTLS: Scale for Delta Time Last Sent SCALEDTLS: Scale for Delta Time Last Sent
PSNTP : Packet Sequence Number This Packet PSNTP : Packet Sequence Number This Packet
PSNLR : Packet Sequence Number Last Received PSNLR : Packet Sequence Number Last Received
DELTATLR : Delta Time Last Received DELTATLR : Delta Time Last Received
DELTATLS : Delta Time Last Sent DELTATLS : Delta Time Last Sent
The PDM destination option is encoded in type-length-value (TLV) The PDM destination option is encoded in type-length-value (TLV)
format as follows: format as follows:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |TB |ScaleDTLR | ScaleDTLS | | Option Type | Option Length | ScaleDTLR | ScaleDTLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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]
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.
Time Base Scale Delta Time Last Received (SCALEDTLR)
2-bit binary value. It will indicate the lowest granularity possible
for this device. That is, for a value of 00 in the Time Base field,
a value of 1 in the DELTA fields indicates 1 millisecond.
This field is being included so that a device may choose the
granularity which most suits its timer ticks. That is, so that it
does not have to do more work than needed to convert values required
for the PDM.
The possible values of Time Base are as follows:
00 - milliseconds
01 - microseconds
10 - nanoseconds
11 - picoseconds
Scale Delta Time Last Received (SCALEDTLR)
7-bit signed 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 -128 to Last Received (DELTATLR) field. The possible values are from 0-255.
+127. See Section 4 for further discussion on Timing Considerations See Section 4 for further discussion on Timing Considerations and
and formatting of the scaling values. formatting of the scaling values.
Scale Delta Time Last Sent (SCALEDTLS) Scale Delta Time Last Sent (SCALEDTLS)
7-bit signed integer. This is the scaling value for the Delta Time 8-bit signed integer. This is the scaling value for the Delta Time
Last Sent (DELTATLS) field. The possible values are from -128 to Last Sent (DELTATLS) field. The possible values are from 0 to 255.
+127.
Packet Sequence Number This Packet (PSNTP) Packet Sequence Number This Packet (PSNTP)
16-bit unsigned integer. This field will wrap. It is intended for 16-bit unsigned integer. This field will wrap. It is intended for
use while analyzing packet traces. use while analyzing packet traces.
Initialized at a random number and incremented monotonically for each Initialized at a random number and incremented monotonically for each
packet of the session flow of the 5-tuple. The 5-tuple consists of packet of the session flow of the 5-tuple. The 5-tuple consists of
the source and destination IP addresses, the source and destination the source and destination IP addresses, the source and destination
ports, and the upper layer protocol (ex. TCP, ICMP, etc). The ports, and the upper layer protocol (ex. TCP, ICMP, etc). The
skipping to change at page 10, line 39 skipping to change at page 10, line 18
0 - Option Data does not change en-route 0 - Option Data does not change en-route
1 - Option Data may change en-route 1 - Option Data may change en-route
The three high-order bits described above are to be treated as part The three high-order bits described above are to be treated as part
of the Option Type, not independent of the Option Type. That is, a of the Option Type, not independent of the Option Type. That is, a
particular option is identified by a full 8-bit Option Type, not just particular option is identified by a full 8-bit Option Type, not just
the low-order 5 bits of an Option Type. the low-order 5 bits of an Option Type.
3.3 Header Placement 3.2.2 Base Unit for Time Measurement
The PDM destination option MUST be placed as follows: A time differential is always a whole number in a CPU; it is the unit
specification -- hours, seconds, nanoseconds -- that determine what
the numeric value means. For PDM, we establish the base time unit as
1 attosecond (asec). This allows for a common unit and scaling of the
time differential among all IP stacks and hardware implementations.
- Before the upper-layer header or the ESP header. Note that we are trying to provide the ability to measure both time
differentials that are extremely small, and time differentials in a
DTN-type environment where the delays may be very great. To store a
time differential in just 16 bits that must range in this way will
require some scaling of the time differential value.
This follows the order defined in RFC2460 [RFC2460] One issue is the conversion from the native time base in the CPU
hardware of whatever device is in use to some number of attoseconds.
It might seem this will be an astronomical number, but the conversion
is straightforward. It involves multiplication by an appropriate
power of 10 to change the value into a number of attoseconds. Then,
to scale the value so that it fits into DELTATLR or DELTATLS, the
value is shifted by of a number of bits, retaining the 16 high-order
or most significant bits. The number of bits shifted becomes the
scaling factor, stored as SCALEDTLR or SCALEDTLS, respectively. For a
full description of this process, including examples, please see
Appendix A.
3.2.3 Considerations of this time-differential representation
There are a few considerations to be taken into account with this
representation of a time differential. The first is whether there are
any limitations on the maximum or minimum time differential that can
be expressed using method of a delta value and a scaling factor. The
second is the amount of imprecision introduced by this method.
3.2.3.1 Limitations with this encoding method
The DELTATLS and DELTATLR fields store only the 16 most-significant
bits of the time differential value. Thus the range, excluding the
scaling factor, is from 0 to 65535, or a maximum of 2**16-1. This
method is further described in [TRAM-TCPM].
The actual magnitude of the time differential is determined by the
scaling factor. SCALEDTLR and SCALEDTLS are 8-bit unsigned integers,
so the scaling factor ranges from 0 to 255. The smallest number that
can be represented would have a value of 1 in the delta field and a
value of 0 in the associated scale field. This is the representation
for 1 attosecond. Clearly this allows PDM to measure extremely small
time differentials.
On the other end of the scale, the maximum delta value is 65535, or
FFFF in hexadecimal. If the maximum scale value of 255 is used, the
time differential represented is 65535*2**255, which is over 3*10**55
years, essentially, forever. So there appears to be no real
limitation to the time differential that can be represented.
3.2.3.2 Loss of precision induced by timer value truncation
As PDM specifies the DELTATLR and DELTATLS values as 16-bit unsigned
integers, any time the precision is greater than those 16 bits, there
will be truncation of the trailing bits, with an accompanying loss of
precision in the value.
Any time differential value smaller than 65536 asec can be stored
exactly in DELTATLR or DELTATLS, because the representation of this
value requires at most 16 bits.
Since the time differential values in PDM are measured in
attoseconds, the range of values that would be truncated to the same
encoded value is 2**(Scale)-1 asec.
For example, the smallest time differential that would be truncated
to fit into a delta field is
1 0000 0000 0000 0000 = 65536 asec
This value would be encoded as a delta value of 8000 (hexadecimal)
with a scaling factor of 1. The value
1 0000 0000 0000 0001 = 65537 asec
would also be encoded as a delta value of 8000 with a scaling factor
of 1. This actually is the largest value that would be truncated to
that same encoded value. When the scale value is 1, the value range
is calculated as 2**1 - 1, or 1 asec, which you can see is the
difference between these minimum and maximum values.
The scaling factor is defined as the number of low-order bits
truncated to reduce the size of the resulting value so it fits into a
16-bit delta field. If, for example, you had to truncate 12 bits, the
loss of precision would depend on the bits you truncated. The range
of these values would be
0000 0000 0000 = 0 asec
to
1111 1111 1111 = 4095 asec
So the minimum loss of precision would be 0 asec, where the delta
value exactly represents the time differential, and the maximum loss
of precision would be 4095 asec. As stated above, the scaling factor
of 12 means the maximum loss of precision is 2**12-1 asec, or 4095
asec.
Compare this loss of precision to the actual time differential. The
range of actual time differential values that would incur this loss
of precision is from
1000 0000 0000 0000 0000 0000 0000 = 2**27 asec or 134217728 asec
to
1111 1111 1111 1111 1111 1111 1111 = 2**28-1 asec or 268435455 asec
Granted, these are small values, but the point is, any value between
these two values will have a maximum loss of precision of 4095 asec,
or about 0.00305% for the first value, as encoded, and at most
0.001526% for the second. These maximum-loss percentages are
consistent for all scaling values.
3.3 Header Placement
The PDM destination option follows the order defined in RFC2460
[RFC2460].
IPv6 header IPv6 header
Hop-by-Hop Options header Hop-by-Hop Options header
Destination Options header <-------- Destination Options header <--------
Routing header Routing header
Fragment header Fragment header
Authentication header Authentication header
Encapsulating Security Payload header Encapsulating Security Payload header
Destination Options header <------------ Destination Options header <------------
upper-layer header upper-layer header
Note that there is a choice of where to place the Destination Options Note that there is 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
skipping to change at page 11, line 28 skipping to change at page 13, line 22
Note that there is a choice of where to place the Destination Options Note that there is 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.
3.4 Header Placement Using IPSec ESP Mode 3.4 Header Placement Using IPSec ESP Mode
IP Encapsulating Security Payload (ESP) is defined in [RFC4303] and IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303]
is widely used. Section 3.1.1 of [RFC4303] discusses placement of and is widely used. Section 3.1.1 of [RFC4303] discusses placement
Destination Options Headers. Below is the diagram from [RFC4303] of Destination Options Headers.
discussing placement. PDM MUST be placed before the ESP header in
order to work. If placed before the ESP header, the PDM header will
flow in the clear over the network thus allowing gathering of
performance and diagnostic data without sacrificing security.
BEFORE APPLYING ESP The placement of PDM is different depending on if ESP is used in
tunnel or transport mode.
3.4.1 Using ESP Transport Mode
Below is the diagram from [RFC4303] discussing placement of headers.
Note that Destination Options MAY be placed before or after ESP or
both. If using PDM in ESP transport mode, PDM MUST be placed after
the ESP header so as not to leak information.
BEFORE APPLYING ESP
--------------------------------------- ---------------------------------------
IPv6 | | ext hdrs | | | IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data | | orig IP hdr |if present| TCP | Data |
--------------------------------------- ---------------------------------------
AFTER APPLYING ESP AFTER APPLYING ESP
--------------------------------------------------------- ---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
--------------------------------------------------------- ---------------------------------------------------------
|<--- encryption ---->| |<--- encryption ---->|
|<------ integrity ------>| |<------ integrity ------>|
* = if present, could be before ESP, after ESP, or both * = if present, could be before ESP, after ESP, or both
3.4.2 Using ESP Tunnel Mode
Below is the diagram from [RFC4303] discussing placement of headers.
Note that Destination Options MAY be placed before or after ESP or
both in both the outer set of IP headers and the inner set of IP
headers.
In ESP tunnel mode, PDM MAY be placed before or after the ESP header
or both.
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
------------------------------------------------------------
|<--------- encryption ---------->|
|<------------ integrity ------------>|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.
As a completely new IP packet will be made, it means that PDM
information for that packet does not contain any information from the
inner packet, i.e. the PDM information will NOT be based on the
transport layer (TCP, UDP, etc) ports etc in the inner header, but
will be specific to the ESP flow.
If PDM information for the inner packet is desired, the original host
sending the inner packet needs to put PDM header in the tunneled
packet, and then the PDM information will be specific for that
stream.
3.5 Implementation Considerations 3.5 Implementation Considerations
The PDM destination options extension header SHOULD be turned on by The PDM destination options extension header MUST be explicitly
each stack on a host node. It MAY also be turned on only in case of turned on by each stack on a host node by administrative action. The
diagnostics needed for problem resolution. default value of PDM is off.
PDM MUST NOT be turned on merely if a packet is received with a PDM
header. The received packet could be spoofed by another device.
3.6 Dynamic Configuration Options 3.6 Dynamic Configuration Options
If implemented, each operating system MUST have a default If implemented, each operating system MUST have a default
configuration parameter, e.g. diag_header_sys_default_value=yes/no. configuration parameter, e.g. diag_header_sys_default_value=yes/no.
The operating system MAY also have a dynamic configuration option to The operating system MAY also have a dynamic configuration option to
change the configuration setting as needed. 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
skipping to change at page 12, line 47 skipping to change at page 15, line 44
The question comes of when to stop keeping data or restarting the The question comes of when to stop keeping data or restarting the
numbering for a 5-tuple. For example, in the case of TCP, at some numbering for a 5-tuple. For example, in the case of TCP, at some
point, the connection will terminate. Keeping data in control blocks point, the connection will terminate. Keeping data in control blocks
forever, will have unfortunate consequences for the operating system. forever, will have unfortunate consequences for the operating system.
So, the recommendation is to use a known aging parameter such as Max So, the recommendation is to use a known aging parameter such as Max
Segment Lifetime (MSL) as defined in Transmission Control Protocol Segment Lifetime (MSL) as defined in Transmission Control Protocol
[RFC0793] to reuse or drop the control block. The choice of aging [RFC0793] to reuse or drop the control block. The choice of aging
parameter is left up to the implementation. parameter is left up to the implementation.
4 Considerations of Timing Representation 4 PDM Flow - Simple Client Server
4.1 Encoding the Delta-Time Values
This section makes reference to and expands on the document "Encoding
of Time Intervals for the TCP Timestamp Option" [TRAM-TCPM].
4.2 Timer registers are different on different hardware
One of the problems with timestamp recording is the variety of
hardware that generates the time value to be used. Different CPUs
track the time in registers of different sizes, and the most-
frequently-iterated bit could be the first on the left or the first
on the right. In order to generate some examples here it is necessary
to indicate the type of timer register being used.
As described in the "IBM z/Architecture Principles of Operation"
[IBM-POPS], the Time-Of-Day clock in a zSeries CPU is a 104-bit
register, where bit 51 is incremented approximately every
microsecond:
1
0 1 2 3 4 5 6 0
+--------+---------+---------+---------+---------+---------+--+...+
| | | | | |* | |
+--------+---------+---------+---------+---------+---------+--+...+
^ ^ ^
0 51 = 1 usec 103
To represent these values concisely a hexadecimal representation will
be used, where each digit represents 4 binary bits. Thus:
0000 0000 0000 0001 = 1 timer unit (2**-12 usec, or about 244 psec)
0000 0000 0000 1000 = 1 microsecond
0000 0000 003E 8000 = 1 millisecond
0000 0000 F424 0000 = 1 second
0000 0039 3870 0000 = 1 minute
0000 0D69 3A40 0000 = 1 hour
0001 41DD 7600 0000 = 1 day
Note that only the first 64 bits of the register are commonly
represented, as that represents a count of timer units on this
hardware. Commonly the first 52 bits are all that are displayed, as
that represents a count of microseconds.
4.3 Timer Units on Other Systems
This encoding method works the same with other hardware clock
formats. The method uses a microsecond as the basic value and allows
for large time differentials.
4.4 Time Base
This specification allows for the fact that different CPU TOD clocks
use different binary points. For some clocks, a value of 1 could
indicate 1 microsecond, whereas other clocks could use the value 1 to
indicate 1 millisecond. In the former case, the binary digits to the
right of that binary point measure 2**(-n) microseconds, and in the
latter case, 2**(-n) milliseconds.
The Time Base allows us to ensure we have a common reference, at the
very least, common knowledge of what the binary point is for the
transmitted values.
We define a base unit for the time. This is a 2-bit binary value
indicating the lowest granularity possible for this device. That is,
for a value of 00 in the Time Base field, a value of 1 in the DELTA
fields indicates 1 millisecond.
The possible values of Time Base are as follows:
00 - milliseconds
01 - microseconds
10 - nanoseconds
11 - picoseconds
Time base is not necessarily equivalent to length of one timer tick.
That is, on many, if not all, systems, the timer tick value will not
be in complete units of nanoseconds, milliseconds, etc. For example,
on an IBM zSeries machine, one timer tick (or clock unit) is 2 to the
-12th microseconds.
Therefore, some amount of conversion may be needed to approximate
Time Base units.
4.5 Timer-value scaling
As discussed in [TRAM-TCPM] we define storing not an entire time-
interval value, but just the most significant bits of that value,
along with a scaling factor to indicate the magnitude of the time-
interval value. In our case, we will use the high-order 16 bits. The
scaling value will be the number of bits in the timer register to the
right of the 16th significant bit. That is, if the timer register
contains this binary value:
1110100011010100101001010001000000000000
<-16 bits -><-24 bits ->
then, the values stored would be 1110 1000 1101 0100 in binary (E8D4
hexadecimal) for the time value and 24 for the scaling value. Note
that the displayed value is the binary equivalent of 1 second
expressed in picoseconds.
The below table represents a device which has a TimeBase of
picoseconds (or 11). The smallest and simplest value to represent is
1 picosecond; the time value stored is 1, and the scaling value is 0.
Using values from the table below, we have:
Time value in Encoded Scaling
Delta time picoseconds value decimal
--------------------------------------------------------
1 picosecond 1 1 0
1 nanosecond 3E8 3E8 0
1 microsecond F4240 F424 4
1 millisecond 3B9ACA00 3B9A 16
1 second E8D4A51000 E8D4 24
1 minute 3691D6AFC000 3691 32
1 hour cca2e51310000 CCA2 36
1 day 132f4579c980000 132F 44
365 days 1b5a660ea44b80000 1B5A 52
Sample binary values (high order 16 bits taken)
1 psec 1 0001
1 nsec 3E8 0011 1110 1000
1 usec F4240 1111 0100 0010 0100 0000
1 msec 3B9ACA00 0011 1011 1001 1010 1100 1010 0000 0000
1 sec E8D4A51000 1110 1000 1101 0100 1010 0101 0001 0000 0000 0000
4.6 Limitations with this encoding method
According to the specification in [TRAM-TCPM] the size of one such
time-interval field is limited to this 11-bit value and 5-bit
unsigned scale so that they fit into a 16 bit space. With that
limitation, the maximum value that could be stored in 16 bits is:
11-bit value Scale
============= ======
1111 1111 111 1 1111
or an encoded value of 3FF and a scale value of 31. This value, in
microseconds, corresponds to any time differential between:
|<Count of zeroes is the Scale value>|
11 1111 1111 1000 0000 0000 0000 0000 0000 0000 0000 (binary)
3 F F 8 0 0 0 0 0 0 0 (hexadecimal)
and
11 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 (binary)
3 F F F F F F F F F F (hexadecimal)
The latter time value, 3FFFFFFFFFF, converts to 50 days, 21 hours 40
minutes and 46.511103 seconds. A time differential 1 microsecond
longer won't fit into 16 bits using this encoding scheme.
Thus, PDM separates the scaling value from the interval value, giving
a full 16 bits for the interval (DELTA) values and introducing a
signed scaling value that can range from -128 to +127.
4.7 Lack of precision induced by timer value truncation
As PDM specifies the DELTA values as 16-bit unsigned values, any time
the precision is greater than those 16 bits, there will be truncation
of the trailing bits, with an obvious loss precision in the value.
Using microseconds as the Time Base, the range of values that would
be truncated to the same encoded value is 2**(Scale)-1 microseconds.
The smallest time differential that would be truncated is
1 0000 0000 0000 0000 = 65536 usec
The value
1 0000 0000 0000 0001 = 65537 usec
would be truncated to the same encoded value, which is 8000 in hex
with a Scale value of 1. When the Scale value is 1, the value range
is calculated as 2**1 - 1, or 1 microsecond, which you can see is the
difference between these minimum and maximum values.
With that in mind, let's look at that table of DELTA time values
again, where the Precision is the range from the smallest value
corresponding to this encoded value to the largest:
Time value in Encoded
Delta time microseconds value Scale Precision
1 microsecond 1 1 0 0:00.000000
1 millisecond 38E 38E 0 0:00.000000
1 second F4240 F424 4 0:00.000015
1 minute 3938700 3938 12 0:00.004095
1 hour D693A400 D693 16 0:00.065535
1 day 141DD76000 141D 24 0:16.777215
Maximum value 3FFFFFFFFFF FFFF 36 19:05:19.476735
This maximum DELTA value is nearly 52,125 days. At the greatest
value, you can be assured of accuracy within about 19 hours. More
simply, response times in the range of a few seconds can be encoded
with a loss of precision no greater than a tenth of a millisecond.
Most importantly, response times shorter than 65.5 milliseconds can
be encoded with no loss of precision.
5 PDM Flow - Simple Client Server
Following is a sample simple flow for the PDM with one packet sent 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.
Each packet, in addition to the PDM contains information on the Each packet, in addition to the PDM contains information on the
sender and receiver. As discussed before, a 5-tuple consists of: sender and receiver. As discussed before, a 5-tuple consists of:
SADDR : IP address of the sender SADDR : IP address of the sender
SPORT : Port for sender SPORT : Port for sender
DADDR : IP address of the destination DADDR : IP address of the destination
DPORT : Port for destination DPORT : Port for destination
PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP) PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP)
It should be understood that the packet identification information is It should be understood that the packet identification information is
in each packet. We will not repeat that in each of the following in each packet. We will not repeat that in each of the following
steps. steps.
5.1 Step 1 4.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 19, line 13 skipping to change at page 16, line 44
+----------+ +----------+ +----------+ +----------+
PDM Contents: PDM Contents:
PSNTP : Packet Sequence Number This Packet: 25 PSNTP : Packet Sequence Number This Packet: 25
PSNLR : Packet Sequence Number Last Received: - PSNLR : Packet Sequence Number Last Received: -
DELTATLR : Delta Time Last Received: - DELTATLR : Delta Time Last Received: -
SCALEDTLR: Scale of Delta Time Last Received: 0 SCALEDTLR: Scale of Delta Time Last Received: 0
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
TIMEBASE : Granularity of Time: 00 (Milliseconds)
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.
5.2 Step 2 4.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.
5.3 Step 3 4.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 We will call the result of this calculation: Delta Time Last Received
(DELTATLR) (DELTATLR)
That is: That is:
Delta Time Last Received = (Sending time: packet 2 - receive time: Delta Time Last Received = (Sending time: packet 2 - receive time:
packet 1) packet 1)
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
skipping to change at page 20, line 22 skipping to change at page 18, line 4
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. We can now calculate a delta value to be sent out in the packet.
DELTATLR becomes: DELTATLR becomes:
4 seconds = 11:00:07 - 11:00:03 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 calculated. Then, this value, along with the packet factor must be converted; in this case, the time differential is
sequence numbers will be sent to Host A as follows: DE0B, and the scaling factor is 2E, or 46 in decimal. Then, these
values, along with the packet sequence numbers will be sent to Host A
as follows:
Packet 2 Packet 2
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| Host | <---------- | Host | | Host | <---------- | Host |
| A | | B | | A | | B |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
PDM Contents: PDM Contents:
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: FA0 (4 seconds) DELTATLR : Delta Time Last Received: DE0B (4 seconds)
SCALEDTLR: Scale of Delta Time Last Received: 00 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
TIMEBASE : Granularity of Time: 00 (Milliseconds)
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.
5.4 Step 4 4.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 22, line 5 skipping to change at page 19, line 31
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.
5.5 Step 5 4.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 |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
PDM Contents: PDM Contents:
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: 2EE0 (12 seconds) DELTATLS : Delta Time Last Sent: A688 (scaled value)
SCALEDTLR: Scale of Delta Time Last Received: 00 SCALEDTLR: Scale of Delta Time Last Received: 30 (48 decimal)
TIMEBASE : Granularity of Time: 00 (Milliseconds)
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.
6 Other Flows 5 Other Flows
What we have discussed so far is a simple flow with one packet sent What we have discussed so far is a simple flow with one packet sent
and one returned. Let's look at how PDM may be useful in other and one returned. Let's look at how PDM may be useful in other
types of flows. types of flows.
6.1 PDM Flow - One Way Traffic 5.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
is, these values do not represent a number of attoseconds,
microseconds or any other real units of time.
Packet Sender PSN PSN Delta Time Delta Time 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
3 Server 3 0 0 12 3 Server 3 0 0 12
4 Server 4 0 0 20 4 Server 4 0 0 20
What does this mean and how is it useful? What does this mean and how is it useful?
In a one-way flow, only the Delta Time Last Sent will be seen as In a one-way flow, only the Delta Time Last Sent will be seen as
used. Recall, Delta Time Last Sent is the difference between the used. Recall, Delta Time Last Sent is the difference between the
send of one packet from a device and the next. This is a measure of send of one packet from a device and the next. This is a measure of
throughput for the sender - according to the sender's point of view. throughput for the sender - according to the sender's point of view.
That is, it is a measure of how fast is the application itself (with That is, it is a measure of how fast is the application itself (with
stack time included) able to send packets. stack time included) able to send packets.
How might this be useful? If one is having a performance issue at How might this be useful? If one is having a performance issue at
the client and sees that packet 2, for example, is sent after 5 the client and sees that packet 2, for example, is sent after 5 time
microseconds from the server but takes 3 minutes to arrive at the units from the server but takes 10 times that long to arrive at the
destination, then one may safely conclude that there are delays in destination, then one may safely conclude that there are delays in
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.
6.2 PDM Flow - Multiple Send Traffic 5.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 24, line 27 skipping to change at page 22, line 10
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 we have such information 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.
6.3 PDM Flow - Multiple Send with Errors 5.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 26, line 17 skipping to change at page 23, line 44
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.
7 Potential Overhead Considerations 6 Potential Overhead Considerations
Questions have been posed as to the potential overhead of PDM. Questions have been posed as to the potential overhead of PDM.
First, PDM is entirely optional. That is, a site may choose to First, PDM is entirely optional. That is, a site may choose to
implement PDM or not as they wish. If they are happy with the costs implement PDM or not as they wish. If they are happy with the costs
of PDM vs. the benefits, then the choice should be theirs. of PDM vs. the 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 27, line 10 skipping to change at page 24, line 32
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 Micro in PDM RTT in Packet Per Micro in PDM RTT
===================================================================== =====================================================================
1000 20 micro 50 16 20.320 .320 micro 1000 20 micro 50 16 20.320 .320 micro
8 Security Considerations 7 Security Considerations
PDM does not introduce any new security weakness. PDM may introduce some new security weaknesses.
8.1. SYN Flood and Resource Consumption Attacks 7.1. SYN Flood 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 must be kept at the
end hosts per 5-tuple. Any time a control block is kept, an end hosts per 5-tuple. Any time a control block is kept, an
attacker can try to mis-use the control blocks such that there is a attacker can try to mis-use the control blocks such that there is a
compromise of the end host. compromise of the end host.
PDM is used only at the end hosts and the control blocks are only 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, kept at the end host and not at routers or middle boxes. Remember,
PDM is an implementation of the Destination Option extension header. PDM is an implementation of the Destination Option extension header.
skipping to change at page 27, line 42 skipping to change at page 25, line 21
For PDM, the amount of data to be kept is quite small. That is, the For PDM, the amount of data to be kept is quite small. That is, the
control block is quite lightweight. Concerns about SYN Flood and control block is quite lightweight. Concerns about SYN Flood and
other type of resource consumption attacks (memory, processing power, other type of resource consumption attacks (memory, processing power,
etc) can be alleviated by having a limit on the number of control etc) can be alleviated by having a limit on the number of control
block entries. block entries.
We recommend that implementation of PDM SHOULD have a limit on the We recommend that implementation of PDM SHOULD have a limit on the
number of control block entries. number of control block entries.
8.2 Pervasive monitoring 7.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
attacker also has access to the entire packet and could make such a attacker also has access to the entire packet and could make such a
deduction based merely on the time frames elapsed between packets deduction based merely on the time frames elapsed between packets
WITHOUT PDM. WITHOUT PDM.
As far as deducing the content of the payload, it appears to us that As far as deducing the content of the payload, it appears to us that
PDM is quite unhelpful in this regard. PDM is quite unhelpful in this regard.
8.3 PDM as a Covert Channel 7.3 PDM as a Covert Channel
PDM provides a set of fields in the packet which could be used to PDM provides a set of fields in the packet which could be used to
leak data. But, there is no real reason to suspect that PDM would leak data. But, there is no real reason to suspect that PDM would
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.
skipping to change at page 28, line 39 skipping to change at page 26, line 15
and doing packet tracing for diagnostic purposes, so the changes and doing packet tracing for diagnostic purposes, so the changes
would be obvious. It is conceivable that someone could compromise would be obvious. It is conceivable that someone could compromise
an end host and make it start sending packets with PDM without the an end host and make it start sending packets with PDM without the
knowledge of the host. But, again, the bigger problem is the knowledge of the host. But, again, the bigger problem is the
compromise of the end host. Once that is done, the attacker compromise of the end host. Once that is done, the attacker
probably has better ways to leak data. probably has better ways to leak data.
Having said that, an implementation SHOULD stop using PDM if it gets Having said that, an implementation SHOULD stop using PDM if it gets
some number of "nonsensical" sequence numbers. some number of "nonsensical" sequence numbers.
9 IANA Considerations 7.4 Timing Attacks
The fact that PDM can help in the separation of node processing time
from network latency brings value to performance monitoring. Yet, it
is this very characteristic of PDM which may be misused to make
certain new type of timing attacks against protocols and
implementations possible.
Depending on the nature of the cryptographic protocol used, it may be
possible to leak the long term credentials of the device. For
example, if an attacker is able to create an attack which causes the
enterprise to turn on PDM to diagnose the attack, then the attacker
might use PDM during that debugging time to launch a timing attack
against the long term keying material used by the cryptographic
protocol.
An implementation may want to be sure that PDM is enabled only for
certain ip addresses, or only for some ports. Additionally, we
recommend that the implementation SHOULD require an explicit restart
of monitoring after a certain timeperiod (for example for 1 hour), to
make sure that PDM is not accidently left on after debugging has been
done etc.
Even so, if using PDM, we introduce the concept of user "Consent to
be Measured" as a pre-requisite for using PDM. Consent is common in
enterprises and with some subscription services. So, if with PDM, we
recommend that the user SHOULD consent to its use.
8 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)
10 References 9 References
10.1 Normative References 9.1 Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 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.
skipping to change at page 29, line 33 skipping to change at page 27, line 37
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999. Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP 37, RFC Values In the Internet Protocol and Related Headers", BCP 37, RFC
2780, March 2000. 2780, March 2000.
[RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
10.2 Informative References 9.2 Informative References
[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]
[IBM-POPS] IBM Corporation, "IBM z/Architecture Principles of Appendix A : Timing Considerations
Operation", SA22-7832, 1990-2012
11 Acknowledgments A.1 Time Differential Calculations
The time counter in a CPU is a binary whole number, representing a
number of milliseconds (msec), microseconds (usec) or even
picoseconds (psec). Representing one of these values as attoseconds
(asec) means multiplying by 10 raised to some exponent. Refer to this
table of equalities:
Base value = # of sec = # of asec 1000s of asec
--------------- ------------- ------------- -------------
1 second 1 sec 10**18 asec 1000**6 asec
1 millisecond 10**-3 sec 10**15 asec 1000**5 asec
1 microsecond 10**-6 sec 10**12 asec 1000**4 asec
1 nanosecond 10**-9 sec 10**9 asec 1000**3 asec
1 picosecond 10**-12 sec 10**6 asec 1000**2 asec
1 femtosecond 10**-15 sec 10**3 asec 1000**1 asec
For example, if you have a time differential expressed in
microseconds, since each microsecond is 10**12 asec, you would
multiply your time value by 10**12 to obtain the number of
attoseconds. If you time differential is expressed in nanoseconds,
you would multiply by 10**9 to get the number of attoseconds.
The result is a binary value that will need to be shortened by a
number of bits so it will fit into the 16-bit PDM DELTA field.
The next step is to divide by 2 until the value is contained in just
16 significant bits. The exponent of the value in the last column of
of the table is useful here; the initial scaling factor is that
exponent multiplied by 10. This is the minimum number of low-order
bits to be shifted-out or discarded. It represents dividing the time
value by 1024 raised to that exponent.
The resulting value may still be too large to fit into 16 bits, but
can be normalized by shifting out more bits (dividing by 2) until the
value fits into the 16-bit DELTA field. The number of extra bits
shifted out is then added to the scaling factor. The scaling factor,
the total number of low-order bits dropped, is the SCALEDTL value.
For example: say an application has these start and finish timer
values (hexadecimal values, in microseconds):
Finish: 27C849234 usec (02:57:58.997556)
-Start: 27C83F696 usec (02:57:58.957718)
========== ========= ===============
Difference 9B9E usec 00.039838 sec or 39838 usec
To convert this differential value to binary attoseconds, multiply
the number of microseconds by 10**12. Divide by 1024**4, or simply
discard 40 bits from the right. The result is 36232, or 8D88 in hex,
with a scaling factor or SCALEDTL value of 40.
For another example, presume the time differential is larger, say
32.311072 seconds, which is 32311072 usec. Each microsecond is 10**12
asec, so multiply by 10**12, giving the hexadecimal value
1C067FCCAE8120000. Using the initial scaling factor of 40, drop the
last 10 characters (40 bits) from that string, giving 1C067FC. This
will not fit into a DELTA field, as it is 25 bits long. Shifting the
value to the right another 9 bits results in a DELTA value of E033,
with a resulting scaling factor of 49.
When the time differential value is a small number, regardless of the
time unit, the exponent trick given above is not useful in
determining the proper scaling value. For example, if the time
differential is 3 seconds and you want to convert that directly, you
would follow this path:
3 seconds = 3*10**18 asec (decimal)
= 29A2241AF62C0000 asec (hexadecimal)
If you just truncate the last 60 bits, you end up with a delta value
of 2 and a scaling factor of 60, when what you really wanted was a
delta value with more significant digits. The most precision with
which you can store this value in 16 bits is A688, with a scaling
factor of 46.
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. Troth for their comments and assistance. We would also like to thank
Tero Kivinen for his detailed and perceptive review.
Authors' Addresses Authors' Addresses
Nalini Elkins Nalini Elkins
Inside Products, Inc. Inside Products, Inc.
36A Upper Circle 36A Upper Circle
Carmel Valley, CA 93924 Carmel Valley, CA 93924
United States United States
Phone: +1 831 659 8360 Phone: +1 831 659 8360
Email: nalini.elkins@insidethestack.com Email: nalini.elkins@insidethestack.com
http://www.insidethestack.com http://www.insidethestack.com
Robert M. Hamilton
Robert Hamilton
Chemical Abstracts Service Chemical Abstracts Service
A Division of the American Chemical Society A Division of the American Chemical Society
2540 Olentangy River Road 2540 Olentangy River Road
Columbus, Ohio 43202 Columbus, Ohio 43202
United States United States
Phone: +1 614 447 3600 x2517 Phone: +1 614 447 3600 x2517
Email: rhamilton@cas.org Email: rhamilton@cas.org
http://www.cas.org http://www.cas.org
Michael S. Ackermann Michael S. Ackermann
 End of changes. 64 change blocks. 
338 lines changed or deleted 389 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/