Skip to main content

IPPM Considerations for the IPv6 PDM Extension Header
draft-elkins-ippm-pdm-metrics-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Nalini Elkins , William Jouris
Last updated 2013-10-03
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-elkins-ippm-pdm-metrics-00
INTERNET-DRAFT                                                 N. Elkins
Intended Status: Proposed Standard                             W. Jouris
                                                         Inside Products
Expires: April 2014                                      October 3, 2013

         IPPM Considerations for the IPv6 PDM Extension Header
                    draft-elkins-ippm-pdm-metrics-00

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

Copyright and License Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.
 

Elkins                   Expires April 14, 2014                 [Page 1]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

   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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2 Packet Identification Data . . . . . . . . . . . . . . . . .  4
     1.3 Data in the PDM Destination Option Header  . . . . . . . . .  5
   2  Metrics Derived from the PDM Destination Option . . . . . . . .  5
   3 Base Derived Metrics . . . . . . . . . . . . . . . . . . . . . .  5
     3.1 One-Way Delay  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . .  6
     3.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.0 Sample Implementation Flow . . . . . . . . . . . . . . . . .  6
     4.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
 

Elkins                   Expires April 14, 2014                 [Page 2]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

     4.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5 Derived Metrics : Advanced . . . . . . . . . . . . . . . . . . . 10
     5.1 Advanced Derived Metrics : Triage  . . . . . . . . . . . . . 10
     5.2 Advanced Derived Metrics : Network Diagnostics . . . . . . . 11
       5.2.1 Retransmit Duplication (RD)  . . . . . . . . . . . . . . 11
       5.2.2 ACK Lag (AL) . . . . . . . . . . . . . . . . . . . . . . 12
       5.2.3 Third-party Connection Reset (TPCR)  . . . . . . . . . . 12
       5.2.4 Potential Hang (PH)  . . . . . . . . . . . . . . . . . . 12
     5.3 Advanced Metrics : Session Classification  . . . . . . . . . 13
   6  Security Considerations . . . . . . . . . . . . . . . . . . . . 13
   7  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13
   9  Acknowledgments  .. . . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

 

Elkins                   Expires April 14, 2014                 [Page 3]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

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-tictoc-pdm-ntp-usage-00
   [ACKPDM], draft-elkins-6man-ipv6-pdm-dest-option-02 [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.

 

Elkins                   Expires April 14, 2014                 [Page 4]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

   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.) 

1.2 Data in the PDM Destination Option Header  

   The data contained in the PDM is as follows:

                 PSNTP : Packet Sequence Number This Packet   
                 TSTP  : Timestamp This Packet                
                 PSNLR : Packet Sequence Number Last Received 
                 TSLR  : Timestamp Last Received           

   The metrics which may be derived from these fields will be discussed
   in the following sections.

2  Metrics Derived from the PDM Destination Option

   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.

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
 

Elkins                   Expires April 14, 2014                 [Page 5]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

   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.0 Sample Implementation Flow

   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-02 [ELKPDM].

   Time synchronization is required between Host A and Host B. See
   draft-ackermann-tictoc-pdm-ntp-usage-00 [ACKPDM] 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    
          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 

   Packet 1 is sent from Host A to Host B.  The time for Host A is set
 

Elkins                   Expires April 14, 2014                 [Page 6]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

   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 

   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
   sent when the response to packet 1 is sent by Host B.

              Packet 1 Received

                    +----------+             +----------+
                    |          |             |          |
                    |   Host   | ----------> |   Host   | 
                    |    A     |             |    B     |
                    |          |             |          |
                    +----------+             +----------+

 

Elkins                   Expires April 14, 2014                 [Page 7]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

                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 

   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:

                  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
 

Elkins                   Expires April 14, 2014                 [Page 8]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

   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

   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:   -
                  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
 

Elkins                   Expires April 14, 2014                 [Page 9]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

   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 

   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 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.

5.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.

 

Elkins                   Expires April 14, 2014                [Page 10]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

5.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.

5.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.
 

Elkins                   Expires April 14, 2014                [Page 11]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

   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.   

5.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.

5.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. 

Elkins                   Expires April 14, 2014                [Page 12]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

5.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.

5.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
      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.

6  Security Considerations

   There are no security considerations.

7  IANA Considerations

   There are no IANA considerations.

8  References

8.1  Normative References

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2679]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
              Delay Metric for IPPM", RFC 2679, September 1999.

Elkins                   Expires April 14, 2014                [Page 13]
INTERNET DRAFT         elkins-ippm-pdm-metrics-00           October 2013

   [RFC2681]  Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
              Delay Metric for IPPM", RFC 2681, September 1999.

   [ACKPDM]  Ackermann, M., "draft-ackermann-tictoc-pdm-ntp-usage-00",
              Internet Draft, September 2013.

   [ELKPDM]  Elkins, N., "draft-elkins-6man-ipv6-pdm-dest-option-02",
              Internet Draft, September 2013.

   [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

9 Acknowledgments

              The authors would like to thank Al Morton, David Boyes,
              Mike Ackermann, Keven Haining, Sigfrido Perdomo 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
              http://www.insidethestack.com

Elkins                   Expires April 14, 2014                [Page 14]