draft-ietf-ippm-6man-pdm-option-08.txt   draft-ietf-ippm-6man-pdm-option-09.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 1, 2017 February 28, 2017 Expires: September 14, 2017 March 13, 2017
IPv6 Performance and Diagnostic Metrics (PDM) Destination Option IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
draft-ietf-ippm-6man-pdm-option-08 draft-ietf-ippm-6man-pdm-option-09
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 3, line 13 skipping to change at page 3, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 4 1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 4
1.3 Need for a Packet Sequence Number (PSN) . . . . . . . . . . 5 1.3 Need for a Packet Sequence Number (PSN) . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 7
2 Measurement Information Derived from PDM . . . . . . . . . . . . 6 2 Measurement Information Derived from PDM . . . . . . . . . . . . 7
2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Performance and Diagnostic Metrics Destination Option Layout . . 7 3 Performance and Diagnostic Metrics Destination Option Layout . . 8
3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 8
3.2 Performance and Diagnostic Metrics Destination Option . . . 7 3.2 Performance and Diagnostic Metrics Destination Option . . . 8
3.2.1 PDM Layout . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1 PDM Layout . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 9 3.2.2 Base Unit for Time Measurement . . . . . . . . . . . . . 10
3.2.3 Considerations of this time-differential 3.2.3 Considerations of this time-differential
representation . . . . . . . . . . . . . . . . . . . . . 10 representation . . . . . . . . . . . . . . . . . . . . . 11
3.2.3.1 Limitations with this encoding method . . . . . . . 10 3.2.3.1 Limitations with this encoding method . . . . . . . 11
3.2.3.2 Loss of precision induced by timer value 3.2.3.2 Loss of precision induced by timer value
truncation . . . . . . . . . . . . . . . . . . . . . 11 truncation . . . . . . . . . . . . . . . . . . . . . 12
3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 12 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 12 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 13
3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 12 3.4.1 Using ESP Transport Mode . . . . . . . . . . . . . . . . 13
3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 13 3.4.2 Using ESP Tunnel Mode . . . . . . . . . . . . . . . . . 14
3.5 Implementation Considerations . . . . . . . . . . . . . . . 14 3.5 Implementation Considerations . . . . . . . . . . . . . . . 15
3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 14 3.5.1 PDM Activation . . . . . . . . . . . . . . . . . . . . . 15
3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 14 3.5.2 PDM Timestamps . . . . . . . . . . . . . . . . . . . . . 15
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 16
4.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 15 3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 15 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 16
4.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 16 4.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 16
4.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 17
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 4.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 17
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4 Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . 18
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18
6.2 Informative References . . . . . . . . . . . . . . . . . . . 18 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A : Timing Time Differential Calculations . . . . . . . . 18 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
Appendix B: Sample Packet Flows . . . . . . . . . . . . . . . . . 19 6.2 Informative References . . . . . . . . . . . . . . . . . . . 19
B.1 PDM Flow - Simple Client Server . . . . . . . . . . . . . . 19 Appendix A : Timing Time Differential Calculations . . . . . . . . 20
B.1.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix B: Sample Packet Flows . . . . . . . . . . . . . . . . . 21
B.1.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.1 PDM Flow - Simple Client Server . . . . . . . . . . . . . . 21
B.1.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.1.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . 21
B.1.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . 22 B.1.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 22
B.1.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . 23 B.1.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.2 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . 23 B.1.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.2.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . 23 B.1.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.2.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . 24
B.2.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . 25 B.2 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix C: Potential Overhead Considerations . . . . . . . . . . 27 B.2.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 B.2.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 B.2.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . 27
Appendix C: Potential Overhead Considerations . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 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
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 5, line 40 skipping to change at page 5, line 42
1.4 Rationale for defined solution 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. So, we
define the IPv6 Performance and Diagnostic Metrics destination option define the IPv6 Performance and Diagnostic Metrics destination option
(PDM). (PDM).
Advantages include: Advantages include:
1. Real measure of actual transactions 1. Real measure of actual transactions.
2. Independence from transport layer protocols
3. Ability to span organizational boundaries with consistent 2. Independence from transport layer protocols.
instrumentation
4. No time synchronization needed between session partners 3. Ability to span organizational boundaries with consistent
5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) instrumentation.
in a uniform way
4. No time synchronization needed between session partners
5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) in
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). More problem is in the network or in the server (application). That is,
intermediate measurements may be needed if the host or network it is a fast way to do triage.
discrimination is not sufficient. At the client, TCP/IP stack time
vs. application time may still need to be broken out by client One of the important functions of PDM is to allow you to do quickly
software. 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 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
would be looked at together to make sense of the packet flow. The would be looked at together to make sense of the packet flow. The
skipping to change at page 14, line 12 skipping to change at page 15, line 18
transport layer (TCP, UDP, etc) ports etc in the inner header, but transport layer (TCP, UDP, etc) ports etc in the inner header, but
will be specific to the ESP flow. will be specific to the ESP flow.
If PDM information for the inner packet is desired, the original host If PDM information for the inner packet is desired, the original host
sending the inner packet needs to put PDM header in the tunneled sending the inner packet needs to put PDM header in the tunneled
packet, and then the PDM information will be specific for that packet, and then the PDM information will be specific for that
stream. stream.
3.5 Implementation Considerations 3.5 Implementation Considerations
3.5.1 PDM Activation
The PDM destination options extension header MUST be explicitly The PDM destination options extension header MUST be explicitly
turned on by each stack on a host node by administrative action. The turned on by each stack on a host node by administrative action. The
default value of PDM is off. default value of PDM is off.
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
The PDM timestamps are intended to isolate wire time from server or
host time, but may necessarily attribute some host processing time to
network latency.
RFC2330 [RFC2330] "Framework for IP Performance Metrics" describes
two notions of wire time in section 10.2. These notions are only
defined in terms of an Internet host H observing an Internet link L
at a particular location:
+ For a given IP packet P, the 'wire arrival time' of P at H on L
is the first time T at which any bit of P has appeared at H's
observational position on L.
+ For a given IP packet P, the 'wire exit time' of P at H on L is
the first time T at which all the bits of P have appeared at H's
observational position on L.
This specification does not define the exact H's observing position
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
physical network interface as possible. Not all implementations will
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 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
upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP
skipping to change at page 17, line 45 skipping to change at page 19, line 30
[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
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
Values In the Internet Protocol and Related Headers", BCP 37, RFC For 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.
6.2 Informative References 6.2 Informative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"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 : Timing Time 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:
skipping to change at page 25, line 4 skipping to change at page 26, line 49
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
3 Client 1 2 20 0 3 Client 1 2 20 0
4 Server 3 1 10 15 4 Server 3 1 10 15
How might this be used?
How might this be used?
Notice that in packet 3, the client has a value of Delta Time Last Notice that in packet 3, the client has a value of Delta Time Last
received of 20. Recall that Delta Time Last Received is the Send received of 20. Recall that Delta Time Last Received is the Send
time of packet 3 - receive time of packet 2. So, what does one know time of packet 3 - receive time of packet 2. So, what does one know
now? In this case, Delta Time Last Received is the processing time now? In this case, Delta Time Last Received is the processing time
for the Client to send the next packet. for the Client to send the next packet.
How to interpret this depends on what is actually being sent. How to interpret this depends on what is actually being sent.
Remember, PDM is not being used in isolation, but to supplement the Remember, PDM is not being used in isolation, but to supplement the
fields found in other headers. Let's take some examples: fields found in other headers. Let's take some examples:
skipping to change at page 28, line 24 skipping to change at page 30, line 24
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
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 for his detailed and perceptive review. Tero Kivinen and Jouni Korhonen for their detailed and perceptive
reviews.
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
 End of changes. 16 change blocks. 
60 lines changed or deleted 119 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/