[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         M. Bagnulo
Internet-Draft                                                      UC3M
Intended status: Standards Track                            T. Burbridge
Expires: January 15, 2014                                             BT
                                                             S. Crawford
                                                                SamKnows
                                                              P. Eardley
                                                                      BT
                                                               A. Morton
                                                               AT&T Labs
                                                           July 14, 2013


                  A registry for commonly used metrics
                   draft-bagnulo-ippm-new-registry-01

Abstract

   This document creates a registry for commonly used metrics, defines
   the rules for assignments in the new registry and performs initial
   allocations.  This document proposes one particular registry
   structure with a single registry with multiple sub-registries.  A
   companion document draft-bagnulo-ippm-new-registry-independent
   explores an alternative structure with independent registries for
   each of the fields involved.  .

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 15, 2014.









Bagnulo, et al.         Expires January 15, 2014                [Page 1]


Internet-Draft              Metrics Registry                   July 2013


Copyright Notice

   Copyright (c) 2013 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
   2.  The commonly used metrics registry  . . . . . . . . . . . . .   4
     2.1.  The metrics registry  . . . . . . . . . . . . . . . . . .   5
     2.2.  The Scheduling registry . . . . . . . . . . . . . . . . .   5
     2.3.  The Environment registry  . . . . . . . . . . . . . . . .   6
     2.4.  The Output type registry  . . . . . . . . . . . . . . . .   6
   3.  Initial assignment for the Scheduling registry  . . . . . . .   6
     3.1.  Common parameter definitions  . . . . . . . . . . . . . .   6
     3.2.  Poisson scheduling  . . . . . . . . . . . . . . . . . . .   7
     3.3.  Periodic scheduling . . . . . . . . . . . . . . . . . . .   7
     3.4.  Singleton scheduling  . . . . . . . . . . . . . . . . . .   8
   4.  Initial assignments for the Output Type registry  . . . . . .   8
     4.1.  Raw . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Xth percentile interval . . . . . . . . . . . . . . . . .   9
     4.3.  Xth percentile mean . . . . . . . . . . . . . . . . . . .   9
   5.  Initial assignments for the Environment registry  . . . . . .   9
     5.1.  Undefined . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  No cross traffic  . . . . . . . . . . . . . . . . . . . .  10
   6.  Initial assignments for the Metric registry . . . . . . . . .  11
     6.1.  Comment . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  UDP related metrics . . . . . . . . . . . . . . . . . . .  11
       6.2.1.  No cross traffic, raw, Poisson, UDP latency metric  .  12
       6.2.2.  No cross traffic, 99th percentile mean, Poisson, UDP
               latency metric  . . . . . . . . . . . . . . . . . . .  13
       6.2.3.  No cross traffic, 99th percentile interval, Poisson,
               UDP latency metric  . . . . . . . . . . . . . . . . .  14
       6.2.4.  No cross traffic, Poisson UDP packet-loss ratio
               metric  . . . . . . . . . . . . . . . . . . . . . . .  15
     6.3.  ICMP related metrics  . . . . . . . . . . . . . . . . . .  16
       6.3.1.  No cross traffic, Periodic, ICMP packet-loss ratio
               metric  . . . . . . . . . . . . . . . . . . . . . . .  16



Bagnulo, et al.         Expires January 15, 2014                [Page 2]


Internet-Draft              Metrics Registry                   July 2013


     6.4.  DNS related metrics . . . . . . . . . . . . . . . . . . .  17
       6.4.1.  DNS latency metric  . . . . . . . . . . . . . . . . .  18
     6.5.  VoIP related metrics  . . . . . . . . . . . . . . . . . .  19
       6.5.1.  No cross traffic, raw, Periodic, UDP latency metric .  20
       6.5.2.  No cross traffic, raw, Periodic, UDP loss metric  . .  21
       6.5.3.  No cross traffic, raw, Periodic, UDP, PDV metric  . .  22
       6.5.4.  No cross traffic, Periodic, UDP PDV:99.9 metric . . .  24
       6.5.5.  No cross traffic, Periodic UDP packet-loss ratio
               metric  . . . . . . . . . . . . . . . . . . . . . . .  25
   7.  Security considerations . . . . . . . . . . . . . . . . . . .  26
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  26
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  26
     10.2.  Informative References . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1.  Introduction

   This document creates a registry for commonly used metrics.  In order
   to do that, it creates a number of namespaces whose values will be
   recorded by the registry and will uniquely and precisely identify
   metrics.

   The motivation for having such registry is to allow a controller to
   request a measurement agent to execute a measurement using a specific
   metric.  Such request can be performed using any control protocol
   that refers to the value assigned to the specific metric in the
   registry.  Similarly, the measurement agent can report the results of
   the measurement and by referring to the metric value it can
   unequivocally identify the metric that the results correspond to.

   There was a previous attempt to define a metric registry RFC 4148
   [RFC4148].  However, it was obsoleted by RFC 6248 [RFC6248] because
   it was "found to be insufficiently detailed to uniquely identify IPPM
   metrics... [there was too much] variability possible when
   characterizing a metric exactly" which led to the RFC4148 registry
   having "very few users, if any".

   Our approach learns from this, by tightly defining each entry in the
   registry with only a few parameters open for each.  The idea is that
   the entries in the registry represent different measurement tests,
   whilst the parameters set things like source and destination
   addresses that don't change the fundamental nature of the test.  The
   downside of this approach is that it could result in an explosion in
   the number of entries in the registry.  We believe that less is more
   in this context - it is better to have a reduced set of useful
   metrics rather than a large set of metrics with questionable



Bagnulo, et al.         Expires January 15, 2014                [Page 3]


Internet-Draft              Metrics Registry                   July 2013


   usefulness.  Therefore this document defines that the registry only
   includes commonly used metrics that are well defined; hence we
   require both specification required AND expert review policies for
   the assignment of values in the registry.

   There are a couple of side benefits of having such registry.  First
   the registry could serve as an inventory of useful and used metrics,
   that are normally supported by different implementations of
   measurement agents.  Second, the results of the metrics would be
   comparable even if they are performed by different implementations
   and in different networks, as the metric is properly defined.

   The registry forms part of a Measurement Plan {do you prefer the term
   'Characterization Plan', 'control framework' or 'test schedule'?}. It
   describes various factors that need to be set by the party
   controlling the measurements, for example: specific values for the
   parameters associated with the selected registry entry (for instance,
   source and destination addresses); and how often the measurement is
   made.  The Measurement Plan might look something like: "Dear
   measurement agent: Please start test DNS(example.com) and
   RTT(server.com,150) every day at 2000 GMT.  Run the DNS test 5 times
   and the RTT test 50 times.  Do that when the network is idle.
   Generate both raw results and 99th percentile mean.  Send measurement
   results to collector.com in IPFIX format".  The Measurement Plan
   depends on the requirements of the controlling party.  For instance
   the broadband consumer might want a one-off measurement made
   immediately to one specific server; a regulator might want the same
   measurement made once a day until further notice to the 'top 10'
   servers; whilst an operator might want a varying series of tests
   (some of which will be beyond those defined in the registry) as
   determined from time to time by their operational support system.
   While the registries defined in this document help to define the
   Measurement Plan its full specification falls outside the scope of
   this document.

2.  The commonly used metrics registry

   In this section we define the registry for commonly used metrics.  It
   is composed by the following sub-registries:

   o  Scheduling registry

   o  Environment registry

   o  Output-type registry

   o  Metric registry




Bagnulo, et al.         Expires January 15, 2014                [Page 4]


Internet-Draft              Metrics Registry                   July 2013


   The rationale for the registry structure is to allow flexibility but
   yet precise definition of metrics.  The metric registry is the
   fundamental registry and the other are auxiliary registries that
   define values for different fields in the metric registry.

2.1.  The metrics registry

   Each entry for the metrics registry contain the following
   information:

   o  Identifier: A text string that uniquely identifies the metric

   o  Name: The name of the metric

   o  Environment: A value from the Environment registry

   o  Output-type: A value from the Output-type registry

   o  Scheduling: A value form the Scheduling registry

   o  Reference: The specification where the metric is defined

   The policy for the assignments in the metric registry is both
   specification required AND expert review.  This means that in order
   to create an entry for the metric value a specification defining the
   metric is required and when that happens, the request for allocation
   will be reviewed by an expert.

   The specification must define the input parameters for the metric as
   well as the output of the metric.  The metric must be well defined,
   in the sense that two independent implementations must produce
   uniform and comparable results.

   The expert review must make sure that the proposed metric is
   operationally useful.  This means that the metric has proven to be
   useful in operational/real scenarios.

2.2.  The Scheduling registry

   Each entry for the scheduling registry contain the following
   information:

   o  Value: The name of the scheduling

   o  Reference: the specification where the scheduling is defined

   The scheduling defines the scheduling strategy for the metric.
   Simplest is Singleton scheduling, where an atomic measurement is



Bagnulo, et al.         Expires January 15, 2014                [Page 5]


Internet-Draft              Metrics Registry                   July 2013


   made.  Other strategies make a series of atomic measurements in a
   "sample" or "stream", with the schedule defining the timing between
   each distinct measurement.  Each atomic measurement could consist of
   sending a single packet (such as a DNS request) or sending several
   packets (for example a webpage).  A scheduling strategy requires
   input parameter(s).  Assignment in this registry follows the
   specification required policy.

2.3.  The Environment registry

   Each entry for the environment registry contain the following
   information:

   o  Value: The name of the environment

   o  Reference: the specification where the environment is defined

   The environment defines the conditions where the metric is expected
   to be used.  It does not define the metric itself, but the context
   where the metric is executed.  Assignment in this registry follows
   the specification required policy.

2.4.  The Output type registry

   Each entry for the output type registry contain the following
   information:

   o  Value: The name of the output type

   o  Reference: the specification where the output type is defined

   The output type define the type of output that the metric produces.
   It can be the raw results or it can be some form of statistic.
   Assignment in this registry follows the specification required
   policy.  The specification of the output type must define the format
   of the output.  Note that if two types of statistic are required from
   the same test (for example, both "Xth percentile mean" and "Raw")
   then a new output type must be defined ("Xth percentile mean AND
   Raw").

3.  Initial assignment for the Scheduling registry

3.1.  Common parameter definitions

   Although each IPPM RFC defines individual parameters and uses them
   consistently, the parameter names are not completely consistent
   across the RFC set.  For example, the variable "dT" is used in
   several different ways.  This memo uses one set of parameter names,



Bagnulo, et al.         Expires January 15, 2014                [Page 6]


Internet-Draft              Metrics Registry                   July 2013


   and the reader is cautioned to map the names according to their
   definitions.

   We define some parameters that are used by several types of
   scheduling:

   o  T0: time to begin a test

   o  Tf: time to end a test

   T0 and Tf are both in seconds and use the date (yyyy-mm-dd) and NTP
   64 bit timestamp.  T0 includes any control handshaking before the
   test stream or singleton.  Tf is the time the last test data is sent.

   As a result, we have:

   o  Time when test devices may close the test socket: Tf + Waiting
      Time (the time to wait before declaring a packet lost is fixed for
      each metric)

   o  Total duration of the test: Tf - T0 + Waiting Time

3.2.  Poisson scheduling

   The values for this entry are as follows:

   o  Value: Poisson

   o  Reference: draft-bagnulo-ippm-new-registry

   The Poisson scheduling is defined in section 11.1.1 of RFC 2330
   [RFC2330] and needs input parameters:

   o  T0 and Tf: defined above

   o  lambda: the parameter defining the Poisson distribution.  Lambda
      is the mean number of distinct measurements per second in the
      sample.

3.3.  Periodic scheduling

   The values for this entry are as follows:

   o  Value: Periodic

   o  Reference: draft-bagnulo-ippm-new-registry





Bagnulo, et al.         Expires January 15, 2014                [Page 7]


Internet-Draft              Metrics Registry                   July 2013


   The Periodic sampling is defined in RFC 3432 [RFC3432].  The
   additional input parameters for the metric required by Periodic
   scheduling are:

   o  T0 and Tf: defined above

      *  Note that with Periodic sampling, T0 MUST NOT be strictly
         periodic with other tests of the same type.  RFC 3432 [RFC3432]
         requires randomized start times and describes one way to
         accomplish this.  Also, the duration of the test MUST be
         limited.

   o  incT: the time in seconds between one distinct event and the next,
      where events typically result in repeating singleton measurements
      of various types (illustrated below).

      *  for a periodic stream this is the time between packets in the
         sample, first bit to first bit

      *  for measurements on a process this is the time between the
         first packets of the process, for example first bit to first
         bit of the SYN in a TCP 3-way handshake

3.4.  Singleton scheduling

   The values for this entry are as follows:

   o  Value: singleton

   o  Reference: draft-bagnulo-ippm-new-registry

   The singleton scheduling covers the case when an atomic metric is
   performed as per RFC 2330 [RFC2330].  The additional input parameter
   for the metric required by Singleton scheduling is:

   o  T0: defined above

4.  Initial assignments for the Output Type registry

4.1.  Raw

   The values for this entry are as follows:

   o  Value: Raw

   o  Reference: draft-bagnulo-ippm-new-registry





Bagnulo, et al.         Expires January 15, 2014                [Page 8]


Internet-Draft              Metrics Registry                   July 2013


   The results of the metric are delivered in the exact way they are
   produced by the measurements without any further processing or
   filtering.

4.2.  Xth percentile interval

   The values for this entry are as follows:

   o  Value: Xth percentile interval

   o  Reference: draft-bagnulo-ippm-new-registry

   The additional input parameter for the metric is:

   o  X: the percentile (e.g, if the X input parameter is 99, then the
      output will be the 99th percentile interval.)

   The output when using this Output type will be a a couple of values,
   expressed in the same units as the raw output, that is the Xth
   percentile interval, as defined in section 1.3 of RFC 2330 [RFC2330].

4.3.  Xth percentile mean

   The values for this entry are as follows:

   o  Value: Xth percentile mean

   o  Reference: draft-bagnulo-ippm-new-registry

   The additional input parameter for the metric is

   o  X: the percentile (e.g, if the X input parameter is 99, then the
      output will be the 99th percentile mean.)

   The output when using this Output type will be a single value,
   expressed in the same units as the raw output, that is the mean of
   the sample only considering the values contained in the Xth
   percentile interval, as defined in RFC 2330 [RFC2330].

5.  Initial assignments for the Environment registry

5.1.  Undefined

   The values for this entry are as follows:

   o  Value: Undefined

   o  Reference: draft-bagnulo-ippm-new-registry



Bagnulo, et al.         Expires January 15, 2014                [Page 9]


Internet-Draft              Metrics Registry                   July 2013


   The undefined environment is the case where no additional environment
   settings are defined to perform the metric.

5.2.  No cross traffic

   The values for this entry are as follows:

   o  Value: No cross-traffic

   o  Reference: draft-bagnulo-ippm-new-registry

   It is often important that there is no other traffic than the one
   generated by the measurement itself while doing the measurement.  The
   reasons for this are two-folded, first, it is sometimes important
   that the traffic created by the measurement doesn't impact the
   experience of the users of the measured resource.  Second it is
   sometimes important that no other traffic interferes with the
   measurement.  This can be ensured by checking that the level of user
   traffic is either zero or low enough to be confident that it won't
   impact or be impacted by the measurement.

   The "No cross traffic" condition is satisfied when, during the 5
   seconds preceding measurement of the metric:

   o  the level of traffic flowing through the interface that will be
      used to send measurement packets in either direction is less than
      a threshold value of 1% of the line rate of the aforementioned
      interface.

   The "cross traffic" measurement is made at the interface, associated
   with the measurement agent, that user traffic flows across.  For
   example, if the probe is attached to the home gateway, then the
   interface is the service demarcation point where the subscriber
   connects their private equipment or network to the subscribed
   service.

   Note that the No-cross traffic condition is defined only for the link
   directly attached to the measurement agent initiating the
   measurement.  There is nothing mentioned about cross traffic on other
   parts of the path used by measurement packets.  In the case the
   bottleneck of the path is other link than the one directly attached
   to the device running the measurement agent, it may affect and be
   affected by the measurement even if the No cross traffic as defined
   here holds.

   DISCUSSION





Bagnulo, et al.         Expires January 15, 2014               [Page 10]


Internet-Draft              Metrics Registry                   July 2013


   o  clarify whether traffic for each direction is less than threshold,
      or the sum

   o  current SamKnows probes measure cross-traffic before the
      measurement of the metric.  Another approach would be to measure
      cross-traffic during the time the metric is measured.  Or a hybrid
      approach.  These would either be separate environment entries, or
      parameterise the existing one.

   o  current SamKnows probes define a fixed threshold. it could be a
      parameter

   o  could ignore broadcast traffic (think SamKnows includes)

   o  It would be possible to define this a bit more precisely as
      follows:

         The "No cross-traffic" condition is defined for active
         measurements.  The measurement agent runs in a device that has
         one or more interfaces.  In active measurements, the
         measurement agent sends one or more packets.  Lets call if0 the
         interface through with the packets resulting from the
         measurement are sent through.  The no cross traffic condition
         is fulfilled when during the 5 seconds prior sending each of
         the packets of the measurement:

         +  The traffic incoming through if0 that does not belong to the
            measurement is lower than 1% of the line rate of if0

         +  The traffic coming through the rest of the interfaces
            towards if0 is less than 1% of the line rate of if0.

6.  Initial assignments for the Metric registry

6.1.  Comment

   Need to work through that we only define T0 and Tf (and not T, dT).

6.2.  UDP related metrics

   RFC 2681 [RFC2681] defines a Round-trip delay metric and RFC 6673
   [RFC6673] defines a Round-trip packet loss metric.  We build on these
   two metrics by specifying several of the open parameters to precisely
   define several metrics for measuring UDP latency and packet loss.
   All the UDP related metrics defined in this section use the
   following:

   P-Type:



Bagnulo, et al.         Expires January 15, 2014               [Page 11]


Internet-Draft              Metrics Registry                   July 2013


   o  IPv4 header values:

      *  DSCP: set to 0

      *  TTL set to 255

      *  Protocol: Set to 17 (UDP)

   o  UDP header values:

      *  Checksum: the checksum must be calculated

   o  Payload

      *  Sequence number: 8-byte integer

      *  Timestamp: 8 byte integer.  Expressed as 64-bit NTP timestamp
         as per section 6 of RFC 5905 [RFC5905]

      *  No padding

   Timeout: 3 seconds

6.2.1.  No cross traffic, raw, Poisson, UDP latency metric

   We define the No cross traffic, raw, Poisson, UDP latency metric as
   follows:

   o  Identifier: TBD1

   o  Name: No cross-traffic, raw, Poisson, UDP latency

   o  Environment: No cross-traffic, access measurement

   o  Output type: raw

   o  Scheduling: Poisson

   o  Reference: draft-bagnulo-ippm-new-registry

   The methodology for this metric is defined as Type-P-Round-trip-
   Delay-Poisson-Stream in RFC 2681 [RFC2681] using the P-Type and
   Timeout defined above.

   The input parameters for this metric are:

   o  Source IP Address




Bagnulo, et al.         Expires January 15, 2014               [Page 12]


Internet-Draft              Metrics Registry                   July 2013


   o  Destination IP Address

   o  Source UDP port

   o  Destination UDP port

   o  Initial time T

   o  Duration dT

   o  Rate lambda

   The output of this metric is a list of elements.  Each element
   corresponds to one packet sent.  Each element contains the timestamp
   of the sent packet and the time when the echo was received.

6.2.2.  No cross traffic, 99th percentile mean, Poisson, UDP latency
        metric

   The methodology for this metric is defined as Type-P-Round-trip-
   Delay-Poisson-Stream in RFC 2681 [RFC2681] using the P-Type and
   Timeout defined above.  However, the output of the metric is not the
   raw output, but the 99th percentile mean statistic.

   The input parameters for this metric are:

   o  Identifier: TBD2

   o  Name: No cross-traffic, 99th percentile mean, Poisson, UDP latency

   o  Environment: No cross-traffic, access measurement

   o  Output type: Xth percentile mean

   o  Scheduling: Poisson

   o  Reference: draft-bagnulo-ippm-new-registry

   The methodology for this metric is defined in RFC 2681 [RFC2681]
   using the P-Type and Timeout defined above.

   The input parameters for this metric are:

   o  Source IP Address

   o  Destination IP Address

   o  Source UDP port



Bagnulo, et al.         Expires January 15, 2014               [Page 13]


Internet-Draft              Metrics Registry                   July 2013


   o  Destination UDP port

   o  Initial time T

   o  Duration dT

   o  Rate lambda

   o  Xth percentile: 99

   The output of this metric is a single value that corresponds to the
   99th percentile mean of the results.

6.2.3.  No cross traffic, 99th percentile interval, Poisson, UDP latency
        metric

   The methodology for this metric is defined as Type-P-Round-trip-
   Delay-Poisson-Stream in RFC 2681 [RFC2681] using the P-Type and
   Timeout defined above.  However, the output of the metric is not the
   raw output, but the 99th percentile interval statistic.

   The input parameters for this metric are:

   o  Identifier: TBD3

   o  Name: No cross-traffic, 99th percentile interval, Poisson, UDP
      latency

   o  Environment: No cross-traffic, access measurement

   o  Output type: Xth percentile interval

   o  Scheduling: Poisson

   o  Reference: draft-bagnulo-ippm-new-registry

   The methodology for this metric is defined in RFC 2681 [RFC2681]
   using the P-Type and Timeout defined above.

   The input parameters for this metric are:

   o  Source IP Address

   o  Destination IP Address

   o  Source UDP port

   o  Destination UDP port



Bagnulo, et al.         Expires January 15, 2014               [Page 14]


Internet-Draft              Metrics Registry                   July 2013


   o  Initial time T

   o  Duration dT

   o  Rate lambda

   o  Xth percentile: 99

   The output of this metric is a single value that corresponds to the
   99th percentile interval of the results.

6.2.4.  No cross traffic, Poisson UDP packet-loss ratio metric

   We define the No cross traffic, Poisson, UDP packet-loss ratio metric
   as follows:

   o  Identifier: TBD4

   o  Name: No cross-traffic, Poisson, UDP packet-loss ratio

   o  Environment: No cross-traffic, access measurement

   o  Output type: Xth percentile mean

   o  Scheduling: Poisson

   o  Reference: draft-bagnulo-ippm-new-registry

   This metric is defined as Type-P-Round-trip-Loss-Poisson-Ratio in RFC
   6673 [RFC6673] using the P-Type and Timeout defined above.

   The input parameters for this metric are:

   o  Source IP Address

   o  Destination IP Address

   o  Source UDP port

   o  Destination UDP port

   o  Initial time T

   o  Duration dT

   o  Rate lambda

   o  X percentile: 100



Bagnulo, et al.         Expires January 15, 2014               [Page 15]


Internet-Draft              Metrics Registry                   July 2013


   The output of this metric is a single value that corresponds to the
   ratio of loss packets divided by the total number of packets sent.

6.3.  ICMP related metrics

   RFC 6673 [RFC6673] defines a Round-trip packet loss metric.  We build
   on that metrics by specifying several of the open parameters to
   precisely define a metric for measuring ICMP packet loss.  The ICMP
   related metric defined in this document use the following:

   P-Type:

   o  IPv4 header values:

      *  DSCP: set to 0

      *  TTL set to 255

      *  Protocol: Set to 1 (ICMP)

   o  ICMP header values:

      *  Type: 8 (Echo request)

      *  Code: 0

   Observation: reply packets will contain an ICMP type of 0 Echo reply.

   Timeout: 3 seconds

6.3.1.  No cross traffic, Periodic, ICMP packet-loss ratio metric

   We define the No cross traffic, Periodic, ICMP packet-loss ratio
   metric as follows:

   o  Identifier: TBD6

   o  Name: No cross-traffic, Periodic, ICMP packet-loss ratio

   o  Environment: No cross-traffic, access measurement

   o  Output type: Xth percentile mean

   o  Scheduling: Periodic

   o  Reference: draft-bagnulo-ippm-new-registry





Bagnulo, et al.         Expires January 15, 2014               [Page 16]


Internet-Draft              Metrics Registry                   July 2013


   This metric is defined as Type-P-Round-trip-Loss-Periodic-Ratio in
   RFC 6673 [RFC6673] using the P-Type and Timeout defined above.

   The input parameters for this metric are:

   o  Source IP Address

   o  Destination IP Address

   o  Initial time T

   o  End Time Tf

   o  dt (the interval allowed for sample start times)

   o  Inter-packet time: incT

   o  X percentile: 100

   The output of this metric is a single value that corresponds to the
   ratio of loss packets divided by the total number of packets sent.

6.4.  DNS related metrics

   RFC 2681 [RFC2681] defines a Round-trip delay metric.  We build on
   that metric by specifying several of the open parameters to precisely
   define a metric for measuring DNS latency.  The metric uses the
   following parameters:

   P-Type:

   o  IPv4 header values:

      *  DSCP: set to 0

      *  TTL set to 255

      *  Protocol: Set to 17 (UDP)

   o  UDP header values:

      *  Source port: 53

      *  Destination port: 53

      *  Checksum: the checksum must be calculated





Bagnulo, et al.         Expires January 15, 2014               [Page 17]


Internet-Draft              Metrics Registry                   July 2013


   o  Payload: The payload contains a DNS message as defined in RFC 1035
      [RFC1035] with the following values:

      *  The DNS header section contains:

         +  QR: set to 0 (Query)

         +  OPCODE: set to 0 (standard query)

         +  AA: not set

         +  TC: not set

         +  RD: set to one (recursion desired)

         +  RA: not set

         +  RCODE: not set

         +  QDCOUNT: set to one (only one entry)

         +  ANCOUNT: not set

         +  NSCOUNT: not set

         +  ARCOUNT: not set

      *  The Question section contains:

         +  QNAME: the FQDN provided as input for the test

         +  QTYPE: the query type provided as input for the test

         +  QCLASS: set to IN

      *  The other sections do not contain any Resource Records.

   Observation: reply packets will contain a DNS response and may
   contain RRs.

   Timeout: 3 seconds

6.4.1.  DNS latency metric

   We define the DNS latency metric as follows:

   o  Identifier: TBD7




Bagnulo, et al.         Expires January 15, 2014               [Page 18]


Internet-Draft              Metrics Registry                   July 2013


   o  Name: DNS latency

   o  Environment: Undefined

   o  Output type: raw

   o  Scheduling: Singleton

   o  Reference: draft-bagnulo-ippm-new-registry

   The methodology for this metric is defined as Type-P-Round-trip-Delay
   in RFC 2681 [RFC2681] using the P-Type and Timeout defined above.

   The input parameters for this metric are:

   o  Source IP Address

   o  Destination IP Address (the address of the DNS server to be
      tested)

   o  QTYPE: A RR

   o  FQDN: a valid FQDN that will be queried for.

   o  Time T

   The output of this metric is the timestamp when the packet was sent
   and the delay that it took to receive a response.  Please note that
   any DNS response is valid, including no records in the answer.
   (Should we be more explicit about what is the output when there is no
   reply packet received?)

6.5.  VoIP related metrics

   [RFC2679] defines a one-way delay metric and [RFC2680] defines a one-
   way packet loss metric.  IPPM has derived a general packet delay
   variation metric in [RFC3393], which we apply as recommended in
   section 4.2 of [RFC5481].  We build on these specifications by
   specifying several of the open parameters to precisely define several
   metrics for measuring Voice over IP (VoIP) delay, delay variation,
   and packet loss.  All the VoIP related metrics defined in this
   section use the following:

   Type-P:

   o  IPv4 header values:

      *  DSCP: set to 0 (I think we move this to the sub-sections)



Bagnulo, et al.         Expires January 15, 2014               [Page 19]


Internet-Draft              Metrics Registry                   July 2013


      *  TTL set to 255

      *  Protocol: Set to 17 (UDP)

   o  UDP header values:

      *  Checksum: the checksum must be calculated

   o  Payload - suffcient octets to emulate a VoIP audio payload,
      including the an RTP header if desired, the actual test protocol
      will populate the payload with a measurement header containing
      fields such as:

      *  Sequence number:

      *  Timestamp:

      *  Random bit pattern:

   Waiting Time to declare a packet lost: 5 seconds

   Periodic Stream Description:

   o  Nominal inter-packet interval incT=20ms (first bit to first bit)

6.5.1.  No cross traffic, raw, Periodic, UDP latency metric

   We define the No cross traffic, raw, Periodic, UDP latency metric as
   follows:

   o  Identifier: TBD641

   o  Name: No cross-traffic, raw, Periodic, UDP latency

   o  Environment: No cross-traffic, access measurement

   o  Output type: raw

   o  Scheduling: Periodic

   o  Reference: draft-bagnulo-ippm-new-registry

   The methodology for this metric is defined as Type-P-One-way-Delay-
   Periodic-Stream in section 4 of [RFC3432], including parameters from
   section 3 of [RFC3432] and using the Type-P and Waiting Time defined
   above in section 6.4.

   The input parameters for this metric are:



Bagnulo, et al.         Expires January 15, 2014               [Page 20]


Internet-Draft              Metrics Registry                   July 2013


   o  Source IP Address

   o  Destination IP Address

   o  Source UDP port

   o  Destination UDP port

   o  Beginning of testing interval, T

   o  Initial time T0 (including a random offset from the beginning of
      T)

   o  Ending time Tf

   Variable aspects of Type-P are:

   o  DSCP value

   o  UDP Payload length

   The output of this metric is a list of elements.  Each element
   corresponds to one packet sent.  Each element contains the timestamp
   of the sent packet and the time when the packet was received at the
   destination (from which the one-way delay can be calculated).  The
   methodology's sequence number MAY be included.  For packets which do
   not arrive prior to the Waiting Time, the received timestamp for that
   packet SHOULD be indicated as "not available", or post-processing may
   be applied to enforce the constant Waiting Time to exclude long-
   delayed packets and lost packets from further analysis.

6.5.2.  No cross traffic, raw, Periodic, UDP loss metric

   We define the No cross traffic, raw, Periodic, UDP loss metric as
   follows:

   o  Identifier: TBD642

   o  Name: No cross-traffic, raw, Periodic, UDP latency

   o  Environment: No cross-traffic, access measurement

   o  Output type: raw

   o  Scheduling: Periodic

   o  Reference: draft-bagnulo-ippm-new-registry




Bagnulo, et al.         Expires January 15, 2014               [Page 21]


Internet-Draft              Metrics Registry                   July 2013


   The methodology for this metric is identical to Type-P-One-way-Delay-
   Periodic-Stream in section 4 of [RFC3432], including parameters from
   section 3 of [RFC3432] and using the Type-P and Waiting Time defined
   above in section 6.4.

   The input parameters for this metric are:

   o  Source IP Address

   o  Destination IP Address

   o  Source UDP port

   o  Destination UDP port

   o  Beginning of testing interval, T

   o  Initial time T0 (including a random offset from the beginning of
      T)

   o  Ending time Tf

   Variable aspects of Type-P are:

   o  DSCP value

   o  UDP Payload length

   The output of this metric is a list of elements.  Each element
   corresponds to one packet sent.  Each element contains the timestamp
   of the sent packet and the time when the packet was received at the
   destination (from which the one-way delay can be calculated).  The
   methodology's sequence number MAY be included.  For packets which do
   not arrive prior to the Waiting Time, the received timestamp for that
   packet SHOULD be indicated as "not available", or post-processing may
   be applied to enforce the constant Waiting Time to exclude long-
   delayed packets and lost packets from further analysis.

   Note that the same raw output format MAY serve both loss and delay
   metrics.

6.5.3.  No cross traffic, raw, Periodic, UDP, PDV metric

   We define the No cross traffic, Periodic, UDP Packet Delay Variation
   metric as follows:

   o  Identifier: TBD643




Bagnulo, et al.         Expires January 15, 2014               [Page 22]


Internet-Draft              Metrics Registry                   July 2013


   o  Name: No cross-traffic, Periodic, UDP PDV

   o  Environment: No cross-traffic, access measurement

   o  Output type: raw

   o  Scheduling: Periodic

   o  Reference: draft-bagnulo-ippm-new-registry

   The methodology for the delay singletons from which this metric is
   derived take the first steps defined as Type-P-One-way-Delay-
   Periodic-Stream in section 4 of [RFC3432], including parameters from
   section 3 of [RFC3432] and using the Type-P and Waiting Time defined
   above in section 6.4.  This collects the one-way delay singletons.

   The next step in the methodology follows from sections 2 and 3 of
   [RFC3393] (which describes how to use a selection function to
   determine pairs of packets to derive PDV) and section 4.2 of
   [RFC5481], where the packet with the minimum delay is specified as a
   fixed member of the pair.

   The input parameters for this metric are:

   o  Source IP Address

   o  Destination IP Address

   o  Source UDP port

   o  Destination UDP port

   o  Beginning of testing interval, T

   o  Initial time T0 (including a random offset from the beginning of
      T)

   o  Ending time Tf

   Variable aspects of Type-P are:

   o  DSCP value

   o  UDP Payload length

   The output of this metric is a list of triples (3 elements).  Each
   element corresponds to one packet in the sample.  Each element
   contains the one way delay of the first packet in the pair, the one



Bagnulo, et al.         Expires January 15, 2014               [Page 23]


Internet-Draft              Metrics Registry                   July 2013


   way delay of the second packet in the pair (having minimum delay),
   and the variation in transmission time calculated for packet with
   sequence number i as PDV(i) = D(i)-D(min).  The methodology's
   sequence number MAY be included.  For packets which do not arrive
   prior to the Waiting Time, the delay for that packet and its PDV
   SHOULD be indicated as "not available" (following section 4.1 of
   [RFC3393]).

6.5.4.  No cross traffic, Periodic, UDP PDV:99.9 metric

   We define the No cross traffic, Periodic, UDP Packet Delay Variation
   (99.9 percentile) metric as follows:

   o  Identifier: TBD644

   o  Name: No cross-traffic, Periodic, UDP PDV:99.9

   o  Environment: No cross-traffic, access measurement

   o  Output type: 99.9 percentile

   o  Scheduling: Periodic

   o  Reference: draft-bagnulo-ippm-new-registry

   The methodology for the delay singletons from which this metric is
   derived take the first steps defined as Type-P-One-way-Delay-
   Periodic-Stream in section 4 of [RFC3432], including parameters from
   section 3 of [RFC3432] and using the Type-P and Waiting Time defined
   above in section 6.4.  This collects the one-way delay singletons.

   The next step in the methodology follows from sections 2 and 3 of
   [RFC3393] (which describes how to use a selection function to
   determine pairs of packets to derive PDV) and section 4.2 of
   [RFC5481], where the packet with the minimum delay is specified as a
   fixed member of the pair.

   The input parameters for this metric are:

   o  Source IP Address

   o  Destination IP Address

   o  Source UDP port

   o  Destination UDP port

   o  Beginning of testing interval, T



Bagnulo, et al.         Expires January 15, 2014               [Page 24]


Internet-Draft              Metrics Registry                   July 2013


   o  Initial time T0 (including a random offset from the beginning of
      T)

   o  Ending time Tf

   Variable aspects of Type-P are:

   o  DSCP value

   o  UDP Payload length

   The output of this metric is a single value corresponding to the
   99.9th percentile of PDV.  For packets which do not arrive prior to
   the Waiting Time, the delay for that packet and its PDV SHOULD be
   indicated as "not available" (following section 4.1 of [RFC3393]).
   If the 99.9th percentile of singletons corresponds to packet whose
   delay and PDV are "not available", then the output of this metric is
   "not available".

6.5.5.  No cross traffic, Periodic UDP packet-loss ratio metric

   We define the No cross traffic, Periodic, UDP packet-loss ratio
   metric as follows:

   o  Identifier: TBD645

   o  Name: No cross-traffic, Periodic, UDP packet-loss ratio

   o  Environment: No cross-traffic, access measurement

   o  Output type: X percentile mean

   o  Scheduling: Periodic

   o  Reference: draft-bagnulo-ippm-new-registry

   This metric is defined as Type-P-One-way-Loss-Average in Section 4.1
   of[RFC2680] using the Type-P and Waiting Time defined in section 6.4
   above.

   The input parameters for this metric are:

   o  Source IP Address

   o  Destination IP Address

   o  Source UDP port




Bagnulo, et al.         Expires January 15, 2014               [Page 25]


Internet-Draft              Metrics Registry                   July 2013


   o  Destination UDP port

   o  Beginning of testing interval, T

   o  Initial time T0 (including a random offset from the beginning of
      T)

   o  Ending time Tf

   o  X percentile mean: 100

   Variable aspects of Type-P are:

   o  DSCP value

   o  UDP Payload length

   The output of this metric is one value that corresponds to the ratio
   of lost packets divided by the total number of packets sent.  This
   can be calculated from the singleton elements of section 6.4.2 above,
   assigning the logical value "0" to packets with a valid one-way delay
   and the value "1" to all packets whose one-way delay is recorded as
   "not available".  As section 4.1 of [RFC2680] indicates, the average
   of all the logical values is the ratio of lost to total packets.

7.  Security considerations

   TBD

8.  IANA Considerations

   TBD

9.  Acknowledgments

   We would like to thank Henning Schulzrinne for many constructive
   comments and input on early versions of this document.

10.  References

10.1.  Normative References

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330, May
              1998.






Bagnulo, et al.         Expires January 15, 2014               [Page 26]


Internet-Draft              Metrics Registry                   July 2013


   [RFC3432]  Raisanen, V., Grotefeld, G., and A. Morton, "Network
              performance measurement with periodic streams", RFC 3432,
              November 2002.

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

   [RFC6673]  Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673,
              August 2012.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

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

   [RFC2680]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
              Packet Loss Metric for IPPM", RFC 2680, September 1999.

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

   [RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
              Applicability Statement", RFC 5481, March 2009.

10.2.  Informative References

   [RFC4148]  Stephan, E., "IP Performance Metrics (IPPM) Metrics
              Registry", BCP 108, RFC 4148, August 2005.

   [RFC6248]  Morton, A., "RFC 4148 and the IP Performance Metrics
              (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April
              2011.

Authors' Addresses











Bagnulo, et al.         Expires January 15, 2014               [Page 27]


Internet-Draft              Metrics Registry                   July 2013


   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN

   Phone: 34 91 6249500
   Email: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es


   Trevor Burbridge
   British Telecom
   Adastral Park, Martlesham Heath
   Ipswich
   ENGLAND

   Email: trevor.burbridge@bt.com


   Sam Crawford
   SamKnows

   Email: sam@samknows.com


   Philip Eardley
   British Telecom
   Adastral Park, Martlesham Heath
   Ipswich
   ENGLAND

   Email: philip.eardley@bt.com


   Al Morton
   AT&T Labs
   200 Laurel Avenue South
   Middletown, NJ
   USA

   Email: acmorton@att.com









Bagnulo, et al.         Expires January 15, 2014               [Page 28]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/