INTERNET-DRAFT N. Elkins
B. Jouris
Inside Products
K. Haining
U. S. Bank
M. Ackermann
Intended Status: Proposed Standard BCBS Michigan
Expires: July 2014 January 27, 2014
IPPM Considerations for the IPv6 PDM Extension Header
draft-elkins-ippm-pdm-metrics-03
Abstract
To diagnose performance and connectivity problems, metrics on real
(non-synthetic) transmission are critical for timely end-to-end
problem resolution. Such diagnostics may be real-time or after the
fact, but must not impact an operational production network. These
metrics are defined in the IPv6 Performance and Diagnostic Metrics
Destination Option (PDM). The base metrics are: packet sequence
number and packet timestamp. Other metrics may be derived from these
for use in diagnostics. This document specifies such metrics, their
calculation, and usage.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Elkins Expires July, 2014 [Page 1]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Packet Identification Data . . . . . . . . . . . . . . . . . 3
1.2 Data in the PDM Destination Option Headers . . . . . . . . . 4
2 Metrics Derived from the PDM Destination Options . . . . . . . . 4
3 Base Derived Metrics . . . . . . . . . . . . . . . . . . . . . . 5
3.1 One-Way Delay . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Sample Implementation Flow (PDM Type 1) . . . . . . . . . . . . 5
4.1 Step 1 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 6
4.2 Step 2 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 6
4.3 Step 3 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 7
4.4 Step 4 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 8
4.5 Step 5 (PDM Type 1) . . . . . . . . . . . . . . . . . . . . 9
5 Sample Implementation Flow (PDM 2) . . . . . . . . . . . . . . . 9
5.1 Step 1 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 10
5.2 Step 2 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 11
5.3 Step 3 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 11
5.4 Step 4 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 12
5.5 Step 5 (PDM Type 2) . . . . . . . . . . . . . . . . . . . . 13
6 Derived Metrics : Advanced . . . . . . . . . . . . . . . . . . . 14
6.1 Advanced Derived Metrics : Triage . . . . . . . . . . . . . 14
6.2 Advanced Derived Metrics : Network Diagnostics . . . . . . . 14
6.2.1 Retransmit Duplication (RD) . . . . . . . . . . . . . . 15
6.2.2 ACK Lag (AL) . . . . . . . . . . . . . . . . . . . . . . 16
6.2.3 Third-party Connection Reset (TPCR) . . . . . . . . . . 16
6.2.4 Potential Hang (PH) . . . . . . . . . . . . . . . . . . 16
6.3 Advanced Metrics : Session Classification . . . . . . . . . 16
7 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 17
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17
Elkins Expires July, 2014 [Page 2]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1 Normative References . . . . . . . . . . . . . . . . . . . 18
10.2 Informative References . . . . . . . . . . . . . . . . . . 18
11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Elkins Expires July, 2014 [Page 3]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
1 Introduction
To diagnose performance and connectivity problems, metrics on real
(non-synthetic) transmission are critical for timely end-to-end
problem resolution. Such diagnostics may be real-time or after the
fact, but must not impact an operational production network. These
metrics are defined in the IPv6 Performance and Diagnostic Metrics
Destination Option (PDM). The base metrics are: packet sequence
number and packet timestamp. Other metrics may be derived from these
for use in diagnostics. This document specifies such metrics, their
calculation, and usage.
For background, please see draft-ackermann-ntp-pdm-ntp-usage-00
[NTPPDM], draft-elkins-6man-ipv6-pdm-dest-option-03 [ELKPDM], draft-
elkins-v6ops-ipv6-packet-sequence-needed-01 [ELKPSN], draft-elkins-
v6ops-ipv6-pdm-recommended-usage-01 [ELKUSE], and draft-elkins-v6ops-
ipv6-end-to-end-rt-needed-01 [ELKRSP]. These drafts are companions to
this document.
As defined in RFC2460 [RFC2460], destination options are carried by
the IPv6 Destination Options extension header. Destination options
include optional information that need be examined only by the IPv6
node given as the destination address in the IPv6 header, not by
routers in between.
The PDM DOH will be carried by each packet in the network, if this is
configured. That is, the PDM DOH is optional. If the user of the OS
configures the PDM DOH to be used, then it will be carried in the
packet.
The metrics in the PDM are for 'real' data. That is, they are of the
traffic actually traveling on the network.
1.1 Packet Identification Data
Each packet contains information about the sender and receiver. In IP
protocol the identifying information is called a "5-tuple". The
flows described below are for the set of packets flowing between A
and B without consideration of any other packets sent to any other
device from Host A or Host B.
The 5-tuple consists of:
SADDR : IP address of the sender
SPORT : Port for sender
DADDR : IP address of the destination
DPORT : Port for destination
PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.)
Elkins Expires July, 2014 [Page 4]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
1.2 Data in the PDM Destination Option Headers
The IPv6 Performance and Diagnostic Metrics Destination Option (PDM)
is an implementation of the Destination Options Header (Next Header
value = 60). Two types of PDM are defined. PDM type 1 requires time
synchronization. PDM type 2 does not require time synchronization.
PDM type 1 and PDM type 2 are mutually exclusive. That is, a 5-tuple
can either both send PDM type 1 or both send PDM type 2.
PDM type 1 contains the following fields:
PSNTP : Packet Sequence Number This Packet
TSTP : Timestamp This Packet
PSNLR : Packet Sequence Number Last Received
TSLR : Timestamp Last Received
PDM type 2 contains the following fields:
PSNTP : Packet Sequence Number This Packet
PSNLR : Packet Sequence Number Last Received
DELTALR : Delta Last Received
PSNLS : Packet Sequence Number Last Sent
DELTALS : Delta Last Sent
The metrics which may be derived from these fields will be discussed
in the following sections.
2 Metrics Derived from the PDM Destination Options
A number of metrics may be derived from the data contained in the
PDM. Some are relationships between two packets, others require
analysis of multiple packets or multiple protocols.
These metrics fall into the following categories:
1. Base derived metrics
2. Metrics used for triage
3. Metrics used for network diagnostics
4. Metrics used for session classification
5. Metrics used for end user performance optimization
It must be understood that when a metric is discussed, it includes
the average, median, and other statistical variations of that metric.
In the next section, we will discuss the base metrics. In later
sections, we will discuss the more advanced metrics and their uses.
Elkins Expires July, 2014 [Page 5]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
3 Base Derived Metrics
The base metrics which may be derived from the PDM are:
1. One-way delay
2. Round-trip delay
3. Server delay
3.1 One-Way Delay
One-way delay is the time taken to traverse the path one way between
one network device to another. The path from A to B is distinguished
from the path from B to A. For many reasons, the paths may have
different characteristics and may have different delays. One-way
delay is discussed in "A One-way Delay Metric for IPPM" [RFC2679].
3.1 Round-Trip Delay
Round-trip delay is the time taken to traverse the path both ways
between one network device to another. The entire delay to travel
from A to B and B to A is used. Round-trip delay cannot tell if one
path is quite different from another. Round-trip delay is discussed
in "A Round-trip Delay Metric for IPPM" [RFC2681].
3.2 Server Delay
Server delay is the interval between when a packet is received by a
device and a subsequent packet is sent back in response. This may be
"Server Processing Time". It may also be a delay caused by
acknowledgements. Server processing time includes the time taken by
the combination of the stack and application to return the response.
4 Sample Implementation Flow (PDM Type 1)
Following is a sample simple flow with one packet sent from Host A
and one packet received by Host B. The descriptions of these fields
is in draft-elkins-6man-ipv6-pdm-dest-option-03 [ELKPDM].
Time synchronization is required between Host A and Host B. See
draft-ackermann-ntp-pdm-ntp-usage-00 [NTPPDM] for a description of
how an NTP implementation may be set up to achieve good time
synchronization.
Each packet, in addition to the PDM, contains information on the
sender and receiver. This is the 5-tuple consisting of:
SADDR : IP address of the sender
SPORT : Port for sender
Elkins Expires July, 2014 [Page 6]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
DADDR : IP address of the destination
DPORT : Port for destination
PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.)
It should be understood that the packet identification information is
in each packet. We will not repeat that in each of the following
steps.
4.1 Step 1 (PDM Type 1)
Packet 1 is sent from Host A to Host B. The time for Host A is set
initially to 10:00AM.
The timestamp and packet sequence number are sent in the PDM.
The initial PSNTP from Host A starts at a random number. In this
case, 25. The sub-second portion of the timestamp has been omitted
for the sake of simplicity.
Packet 1
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
PSNTP : Packet Sequence Number This Packet: 25
TSTP : Timestamp This Packet: 10:00:00
PSNLR : Packet Sequence Number Last Received: -
TSLR : Timestamp Last Received: -
There are no derived statistics after packet 1.
4.2 Step 2 (PDM Type 1)
Packet 1 is received by Host B. The time for Host B was synchronized
with Host A. Both were set initially to 10:00AM.
The timestamp and PSN for the received packet are placed in the PSNLR
and TSLR fields. These are from the point of view of B. That is,
they indicate when the packet from A was received and which packet it
was.
The PDM is not sent at this point. It is only prepared. It will be
Elkins Expires July, 2014 [Page 7]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
sent when the response to packet 1 is sent by Host B.
Packet 1 Received
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
PSNTP : Packet Sequence Number This Packet: -
TSTP : Timestamp This Packet: -
PSNLR : Packet Sequence Number Last Received: 25
TSLR : Timestamp Last Received: 10:00:03
At this point, the following metric may be derived: one-way delay. In
fact, we now know the one-way delay and the path. We will call this
path 1. This will be the outbound path from the point of view of
Host A and the inbound path from the point of view of Host B.
The calculation of one-way delay (path 1) is as follows:
One-way delay (path 1) = Time packet 1 was received by B - Time
Packet 1 was sent by A
If we make the substitutions from our sample case above, then:
One-way delay (path 1) = 10:00:03 - 10:00:00 or 3 seconds
4.3 Step 3 (PDM Type 1)
Packet 2 is sent from Host B to Host A. The initial PSNTP from Host
B starts at a random number. In this case, 12.
Packet 2
+----------+ +----------+
| | | |
| Host | <---------- | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
Elkins Expires July, 2014 [Page 8]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
PSNTP : Packet Sequence Number This Packet: 12
TSTP : Timestamp This Packet: 10:00:07
PSNLR : Packet Sequence Number Last Received: 25
TSLR : Timestamp Last Received: 10:00:03
After Packet 2 is sent, the following metric may be derived: server
delay.
The calculation of server delay is as follows:
Server delay = Time Packet 2 is sent by B - Time Packet 1 was
received by B
Again, making the substitutions from the sample case:
Server delay = 10:00:07 - 10:00:03 or 4 seconds
Further elaborations of server delay may be done by limiting the data
length to be greater than 1. Some protocols, for example, TCP, have
acknowledgements with a data length of 0 or keep-alive packets with a
data length of 1. An ACK may preceed the actual response data
packet. Keep-alives may be interspersed within the data flow.
4.4 Step 4 (PDM Type 1)
Packet 2 is received by Host A.
The timestamp and PSN for the received packet are placed in the PSNLR
and TSLR fields. These are from the point of view of A. That is,
they indicate when the packet from B was received and which packet it
was.
The PDM is not sent at this point. It is only prepared. It will be
sent when the NEXT packet to Host B is sent by Host A.
Packet 2 Received
+----------+ +----------+
| | | |
| Host | <---------- | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
PSNTP : Packet Sequence Number This Packet: -
Elkins Expires July, 2014 [Page 9]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
TSTP : Timestamp This Packet: -
PSNLR : Packet Sequence Number Last Received: 12
TSLR : Timestamp Last Received: 10:00:10
However, at this point, the following metric may be derived: one-way
delay (path 2).
The calculation of one-way delay (path 2) is as follows:
One-way delay (path 2) = Time packet 2 received by A - Time packet 2
sent by B
If we make the substitutions from our sample case above, then:
One-way delay (path 2) = 10:00:10 - 10:00:07 or 3 seconds
4.5 Step 5 (PDM Type 1)
Packet 3 is sent from Host A to Host B.
Packet 3
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
PSNTP : Packet Sequence Number This Packet: 26
TSTP : Timestamp This Packet: 10:00:50
PSNLR : Packet Sequence Number Last Received: 12
TSLR : Timestamp Last Received: 10:00:10
At this point the PDM flows across the network revealing the last
received timestamp and PSN.
5 Sample Implementation Flow (PDM 2)
Following is a sample simple flow for PDM type 2 with one packet sent
from Host A and one packet received by Host B. PDM type 2 does not
require time synchronization between Host A and Host B. The
calculations to derive meaningful metrics for network diagnostics is
shown below each packet sent or received.
Elkins Expires July, 2014 [Page 10]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
Each packet, in addition to the PDM contains information on the
sender and receiver. As discussed before, a 5-tuple consists of:
SADDR : IP address of the sender
SPORT : Port for sender
DADDR : IP address of the destination
DPORT : Port for destination
PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc)
It should be understood that the packet identification information is
in each packet. We will not repeat that in each of the following
steps.
5.1 Step 1 (PDM Type 2)
Packet 1 is sent from Host A to Host B. The time for Host A is set
initially to 10:00AM.
The timestamp and packet sequence number are noted by the sender
internally. The packet sequence number and timestamp are sent in the
packet.
Packet 1
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM type 2 Contents:
PSNTP : Packet Sequence Number This Packet: 25
PSNLR : Packet Sequence Number Last Received: -
DELTALR : Delta Last Received: -
PSNLS : Packet Sequence Number Last Sent: -
DELTALS : Delta Last Sent: -
Internally, within the sender, Host A, it must keep:
PSNTP : Packet Sequence Number This Packet: 25
TSTP : Timestamp This Packet: 10:00:00
Note, the initial PSNTP from Host A starts at a random number. In
this case, 25. The sub-second portion of the timestamp has been
omitted for the sake of simplicity.
Elkins Expires July, 2014 [Page 11]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
There are no derived statistics after packet 1.
5.2 Step 2 (PDM Type 2)
Packet 1 is received at Host B. His time is set to one hour later
than Host A. In this case, 11:00AM
Internally, within the receiver, Host B, it must keep:
PSNLR : Packet Sequence Number Last Received: 25
TSLR : Timestamp Last Received : 11:00:03
Note, this timestamp is in Host B time. It has nothing whatsoever to
do with Host A time.
At this point, we have no derived statistics. In PDM type 1, the
derived statistic one-way delay (path 1) could have been calculated.
In PDM type 2, this is not possible because there is no time
synchronization.
5.3 Step 3 (PDM Type 2)
Packet 2 is sent by Host B to Host A. Note, the initial PSNTP from
Host B starts at a random number. In 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 knows when it received the
previous packet, it can do the following calculation:
Sending time (packet 2) - receive time (packet 1)
We will call the result of this calculation: Delta Last Received.
That is:
DELTALR = Sending time (packet 2) - receive time (packet 1)
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
packet.
Assume that within Host B is the following:
PSNLR : Packet Sequence Number Last Received: 25
TSLR : Timestamp Last Received : 11:00:03
PSNTP : Packet Sequence Number This Packet : 12
TSTP : Timestamp This Packet : 11:00:07
Hence, DELTALR becomes:
Elkins Expires July, 2014 [Page 12]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
4 seconds = 11:00:07 - 11:00:03
Let us look at the PDM, and then we will look at the derived metrics
at this point.
Packet 2
+----------+ +----------+
| | | |
| Host | <---------- | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Type 2 Contents:
PSNTP : Packet Sequence Number This Packet: 12
PSNLR : Packet Sequence Number Last Received: 25
DELTALR : Delta Last Received: 4
PSNLS : Packet Sequence Number Last Sent: -
DELTALS : Delta Last Sent: -
After Packet 2, the following metrics may be derived:
Server delay = DELTALR
Metrics left to be calculated are the path delay for path 2. This may
be calculated when Packet 3 is sent. Clearly, if there is NO next
packet for the 5-tuple, then this value will be missing.
5.4 Step 4 (PDM Type 2)
Packet 2 is received at Host A. Remember, its time is set to one
hour earlier than Host B. It will keep internally:
PSNLR : Packet Sequence Number Last Received: 12
TSLR : Timestamp Last Received : 10:00:12
Note, this timestamp is in Host A time. It has nothing whatsoever to
do with Host B time.
At this point, we have two derived metrics:
1. Two-way delay or Round Trip time
2. Total end-to-end time
The formula for end-to-time is:
Elkins Expires July, 2014 [Page 13]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
Time Last Received - Time Last Sent
For example, packet 25 was sent by Host A at 10:00:00. Packet 12 was
received by Host A at 10:00:12 so:
End-to-End response time = 10:00:12 - 10:00:00 or 12
This derived metric we will call DELTALS or Delta Last Sent.
To calculate two-way delay, the formula is:
Two-way delay = DELTALS - DELTALR
Or:
Two-way delay = 12 - 4 or 8
Now, the only problem is that at this point all metrics are in the
Host and not exposed in a packet. To do that, we need a third packet.
5.5 Step 5 (PDM Type 2)
Packet 3 is sent from Host A to Host B.
Packet 3
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Type 2 Contents:
PSNTP : Packet Sequence Number This Packet: 26
PSNLR : Packet Sequence Number Last Received: 12
DELTALR : Delta Last Received: *
PSNLS : Packet Sequence Number Last Sent: 25
DELTALS : Delta Last Sent: 12
Elkins Expires July, 2014 [Page 14]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
6 Derived Metrics : Advanced
A number of more advanced metrics may be derived from the data
contained in the PDM. Some are relationships between two packets,
others require analysis of multiple packets. The more advanced
metrics fall into the categories shown below:
1. Metrics used for triage
2. Metrics used for network diagnostics
3. Metrics used for session classification
4. Metrics used for end user performance optimization
We will discuss each of these in turn.
6.1 Advanced Derived Metrics : Triage
In this case, triage means to distinguish between problems occurring
on the network paths or the server. The PDM provides one-way delay
and server delay. This will enable distinguishing which path is a
bottleneck as well as whether the server is a bottleneck.
6.2 Advanced Derived Metrics : Network Diagnostics
The data provided by the PDM may be used in combination with data
fields in other protocols. We will call this Inter-Protocol Network
Diagnostics (IPND).
The PDM also allows us to use only a single trace point for a number
of diagnostic situations where today we need to trace at multiple
points to get required data. In diagnostics, there is often the
question of did the end device really send the packet and it got lost
in the network or did it not send it at all.
So, what is done is that diagnostic traces are run at both client and
server to get the required data. With the data provided by the PDM,
in a number of the cases, this will not be necessary.
For example, taking PDM values along with data fields in the TCP
protocol, the following may be found:
1. Retransmit duplication (RD)
2. ACK lag (AL)
3. Third-party connection reset (TPCR)
4. Elapsed time connection reset (ETCR)
A description of these follows.
Elkins Expires July, 2014 [Page 15]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
6.2.1 Retransmit Duplication (RD)
The TCP protocol will retransmit segments given indications from the
partner that it has not received them. The retransmitted segments
contain the TCP sequence number and acknowledgement. The sequence
number is started at a random number and increased by the amount of
data sent in each packet.
Consider the following scenario. There is a packet sequence number
in the packet at the IP layer. This is in the PDM that we have
defined. The TCP sequence number already exists in the protocol.
Host A sends the following packets:
IP PSN 20, TCP SEQ 10
IP PSN 21, TCP SEQ 11
IP PSN 22, TCP SEQ 12
Host B receives:
IP PSN 20, TCP SEQ 10
IP PSN 22, TCP SEQ 12
Host B indicates to Host A to resend packet with TCP SEQ 2.
Retransmits are done at the TCP layer.
Host A sends the following packet:
IP PSN 23, TCP SEQ 11
The packet never reaches B. B waits until a timeout for retransmits
expires. It asks for the packet again.
Host A sends the following packet:
IP PSN 24, TCP SEQ 11
This time, it reaches Host B. Having the combination of PSN (as
provided in the PDM) and the TCP sequence number allows us to see
whether the problem is that the network is losing the packet or
somehow, the sender is not sending the packet correctly.
As we said before, this also allows us a single trace point rather
than at the client and server to get the required data.
Elkins Expires July, 2014 [Page 16]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
6.2.2 ACK Lag (AL)
Some protocols, such as TCP, acknowledge packets. The PDM will allow
or a calculation of rate of ACKs. Clients can be reconfigured to
optimize acknowledgements and to speed traffic flow.
6.2.3 Third-party Connection Reset (TPCR)
Connections may be aborted by a packet containing a particular flag.
In the TCP protocol, this is the RESET flag. Sometimes a third-
party, for example, a VPN router, will abort the connection. This
may happen because the router is overloaded, the traffic is too
noisy, or other reasons. This can also be quite hard to detect
because the third-party will spoof the address of the sender.
Much time can be spent by the two endpoints pointing fingers at the
other for having dropped the connection.
Such a third-party spoofer would likely not have the PDM Destination
Option. Routers and other middle boxes are not required to support
the Destination Options Extension Header. Even if a PDM DOH was
generated, it would most likely violate the pattern of PSNs and time
stamps being used. This would be a clue to the diagnostician that
the TPCR event has occurred.
6.2.4 Potential Hang (PH)
Connections may be aborted by a packet containing a particular flag.
In the TCP protocol, this is the RESET flag. Sometimes this is done
because a set amount of time has elapsed without activity. The PSN in
the PDM can be used to determine the last packet sent by the partner
and if a response is required -- a "hang" situation.
This can be distinguished from connections which are set to be
aborted after a certain period of inactivity.
6.3 Advanced Metrics : Session Classification
The PDM may be used to classify sessions as follows:
One way traffic flow
Two way traffic flow
One way traffic flow with keep-alive
Two way traffic flow with keep-alive
Multiple send traffic flow
Multiple receive traffic flow
Full duplex traffic flow
Half duplex traffic flow
Elkins Expires July, 2014 [Page 17]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
Immediate ACK data flow
Delayed ACK data flow
Proxied ACK data flow
A session classification system will assist the network
diagnostician. This system will also help in categorizing the server
delay.
7 Use Cases
The scheme outlined above can also handle the following types of
cases:
1. Host clocks not synchronized (shown above)
2. IP fragmentation
3. Multiple sends from one side (multiple segments)
4. Out of order segments
5. Retransmits
6. One-way transmit only (ex. FTP)
7. One-way transmit only
(e.g.real time transports and streaming protocols)
8. Duplicate ACKs
9. Duplicate segments
10. Delayed ACKs
11. ACKs preceeding send for another reason
12. Proxy servers
13. Full duplex traffic
14. Keep alive (0 / 1 byte segments, larger segments)
15. No response from other side
16. Drop without retransmit (real time transports)
17. Looped packets (where the same packet may pass the same point
multiple times without duplication)
18. Multihoming via SHIM6
8 Security Considerations
There are no security considerations.
9 IANA Considerations
There are no IANA considerations.
10.1 Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Elkins Expires July, 2014 [Page 18]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999.
10.2 Informative References
[NTPPDM] Ackermann, M., "draft-ackermann-ntp-pdm-ntp-usage-00",
Internet Draft, January 2014.
[ELKPDM] Elkins, N., "draft-elkins-6man-ipv6-pdm-dest-option-05",
Internet Draft, January 2014.
[ELKPSN] Elkins, N., "draft-elkins-v6ops-ipv6-packet-sequence-
needed-01", Internet Draft, September 2013.
[ELKRSP] Elkins, N., "draft-elkins-v6ops-ipv6-end-to-end-rt-needed-
01", Internet Draft, September 2013.
[ELKUSE] Elkins, N., "draft-elkins-v6ops-ipv6-pdm-recommended-usage-
01", Internet Draft, September 2013
11 Acknowledgments
The authors would like to thank Al Morton, David Boyes,
and Rick Troth for their comments and assistance.
Authors' Addresses
Nalini Elkins
Inside Products, Inc.
36A Upper Circle
Carmel Valley, CA 93924
United States
Phone: +1 831 659 8360
Email: nalini.elkins@insidethestack.com
http://www.insidethestack.com
William Jouris
Inside Products, Inc.
36A Upper Circle
Carmel Valley, CA 93924
United States
Phone: +1 925 855 9512
Email: bill.jouris@insidethestack.com
Elkins Expires July, 2014 [Page 19]
INTERNET DRAFT elkins-ippm-pdm-metrics-03 January 2014
http://www.insidethestack.com
Michael S. Ackermann
Blue Cross Blue Shield of Michigan
P.O. Box 2888
Detroit, Michigan 48231
United States
Phone: +1 310 460 4080
Email: mackermann@bcbsmi.com
http://www.bcbsmi.com
Keven Haining
US Bank
16900 W Capitol Drive
Brookfield, WI 53005
United States
Phone: +1 262 790 3551
Email: keven.haining@usbank.com
http://www.usbank.com
Elkins Expires July, 2014 [Page 20]