Skip to main content

Rate Measurement Test Protocol Problem Statement

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7497.
Author Al Morton
Last updated 2015-02-05 (Latest revision 2015-01-09)
Replaces draft-morton-ippm-rate-problem
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Bill Cerveny
Shepherd write-up Show Last changed 2015-01-30
IESG IESG state Became RFC 7497 (Informational)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Spencer Dawkins
Send notices to,,,
IANA IANA review state IANA OK - No Actions Needed
Network Working Group                                          A. Morton
Internet-Draft                                                 AT&T Labs
Intended status: Informational                           January 9, 2015
Expires: July 13, 2015

            Rate Measurement Test Protocol Problem Statement


   This memo presents an access rate-measurement problem statement for
   test protocols to measure IP Performance Metrics.  Key rate
   measurement test protocol aspects include the ability to control
   packet characteristics on the tested path, such as asymmetric rate
   and asymmetric packet size.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

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

   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 July 13, 2015.

Copyright Notice

   Copyright (c) 2015 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
   ( in effect on the date of

Morton                    Expires July 13, 2015                 [Page 1]
Internet-Draft           Rate Problem Statement             January 2015

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Purpose and Scope . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Active Rate Measurement . . . . . . . . . . . . . . . . . . .   5
   4.  Measurement Method Categories . . . . . . . . . . . . . . . .   7
   5.  Test Protocol Control & Generation Requirements . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Operational Considerations  . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   There are many possible rate measurement scenarios.  This memo
   describes one rate measurement problem and presents a rate-
   measurement problem statement for test protocols to measure IP
   Performance Metrics (IPPM).

   When selecting a form of access to the Internet, subscribers are
   interested in the performance characteristics of the various
   alternatives.  Standardized measurements can be a basis for
   comparison between these alternatives.  There is an underlying need
   to coordinate measurements that support such comparisons, and test
   control protocols to fulfill this need.  The figure below depicts
   some typical measurement points of access networks.

   User     /====== Fiber =======  Access Node \
   Device -|------ Copper -------  Access Node -|-- Infrastructure -- GW
   or Host  \------ Radio -------  Access Node /

   The access-rate scenario or use case has received wide-spread
   attention of Internet access subscribers and seemingly all Internet
   industry players, including regulators.  This problem is being
   approached with many different measurement methods.

Morton                    Expires July 13, 2015                 [Page 2]
Internet-Draft           Rate Problem Statement             January 2015

2.  Purpose and Scope

   The scope and purpose of this memo is to define the measurement
   problem statement for test protocols conducting access rate
   measurement on production networks.  Relevant test protocols include
   [RFC4656] and [RFC5357], but the problem is stated in a general way
   so that it can be addressed by any existing test protocol, such as

   This memo discusses possibilities for methods of measurement, but
   does not specify exact methods which would normally be part of the
   solution, not the problem.

   We are interested in access measurement scenarios with the following

   o  The Access portion of the network is the focus of this problem
      statement.  The user typically subscribes to a service with bi-
      directional access partly described by rates in bits per second.
      The rates may be expressed as raw capacity or restricted capacity
      as described in [RFC6703].  These are the quantities that must be
      measured according to one or more standard metrics, and for which
      measurement methods must also be agreed as a part of the solution.

   o  Referring to the reference path illustrated below and defined in
      [I-D.ietf-ippm-lmap-path], possible measurement points include a
      Subscriber's host, the access service demarcation point, Intra IP
      access where a globally routable address is present, or the
      gateway between the measured access network and other networks.

   Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
   device     Net #1     Net #2    Demarc.    Access     GW     GRA GW

               GRA = Globally Routable Address, GW = Gateway

   o  Rates at some links near the edge of the provider's network can
      often be several orders of magnitude less than link rates in the
      aggregation and core portions of the network.

   o  Asymmetrical access rates on ingress and egress are prevalent.

   o  In many scenarios of interest, extremely large scale of access
      services requires low complexity devices participating at the user
      end of the path, and those devices place limits on clock and
      control timing accuracy.

   This problem statement assumes that the most-likely bottleneck device
   or link is adjacent to the remote (user-end) measurement device, or

Morton                    Expires July 13, 2015                 [Page 3]
Internet-Draft           Rate Problem Statement             January 2015

   is within one or two router/switch hops of the remote measurement

   Other use cases for rate measurement involve situations where the
   packet switching and transport facilities are leased by one operator
   from another and the link capacity available cannot be directly
   determined (e.g., from device interface utilization).  These
   scenarios could include mobile backhaul, Ethernet Service access
   networks, and/or extensions of layer 2 or layer 3 networks.  The
   results of rate measurements in such cases could be employed to
   select alternate routing, investigate whether capacity meets some
   previous agreement, and/or adapt the rate of traffic sources if a
   capacity bottleneck is found via the rate measurement.  In the case
   of aggregated leased networks, available capacity may also be
   asymmetric.  In these cases, the tester is assumed to have a sender
   and receiver location under their control.  We refer to this scenario
   below as the aggregated leased network case.

   This memo describes protocol support for active measurement methods,
   consistent with the IPPM working group's traditional charter.  Active
   measurements require synthetic traffic streams dedicated to testing,
   and do not make measurements on user traffic.  See section 2 of
   [RFC2679], where the concept of a stream is first introduced in IPPM
   literature as the basis for collecting a sample (defined in section
   11 of [RFC2330]).

   As noted in [RFC2330] the focus of access traffic management may
   influence the rate measurement results for some forms of access, as
   it may differ between user and test traffic if the test traffic has
   different characteristics, primarily in terms of the packets
   themselves (see section 13 of [RFC2330] for the considerations on
   packet type, or Type-P).

   There are several aspects of Type-P where user traffic may be
   examined and selected for special treatment that may affect
   transmission rates.  Without being exhaustive, the possibilities

   o  Packet length

   o  IP addresses

   o  Transport protocol (e.g. where TCP packets may be routed
      differently from UDP)

   o  Transport Protocol port numbers

Morton                    Expires July 13, 2015                 [Page 4]
Internet-Draft           Rate Problem Statement             January 2015

   This issue requires further discussion when specific solutions/
   methods of measurement are proposed, but for this problem statement
   it is sufficient to identify the problem and indicate that the
   solution may require an extremely close emulation of user traffic, in
   terms of one or more factors above.

   Although the user may have multiple instances of network access
   available to them, the primary problem scope is to measure one form
   of access at a time.  It is plausible that a solution for the single
   access problem will be applicable to simultaneous measurement of
   multiple access instances, but treatment of this scenario is beyond
   the current scope this document.

   A key consideration is whether active measurements will be conducted
   with user traffic present (In-Service testing), or not present (Out-
   of-Service testing), such as during pre-service testing or
   maintenance that interrupts service temporarily.  Out-of-Service
   testing includes activities described as "service commissioning",
   "service activation", and "planned maintenance".  Opportunistic In-
   Service testing when there is no user traffic present (e.g., outside
   normal business hours) throughout the test interval is essentially
   equivalent to Out-of-Service testing.  Both In-Service and Out-of-
   Service testing are within the scope of this problem.

   It is a non-goal to solve the measurement protocol specification
   problem in this memo.

   It is a non-goal to standardize methods of measurement in this memo.
   However, the problem statement mandates support for one category of
   rate measurement methods in the test protocol and adequate control
   features for the methods in the control protocol (assuming the
   control and test protocols are separate).

3.  Active Rate Measurement

   This section lists features of active measurement methods needed to
   measure access rates in production networks.

   Coordination between source and destination devices through control
   messages and other basic capabilities described in the methods of
   IPPM RFCs [RFC2679][RFC2680], and assumed for test protocols such as
   [RFC5357] and [RFC4656], are taken as given.

   Most forms of active testing intrude on user performance to some
   degree, especially In-Service testing.  One key tenet of IPPM methods
   is to minimize test traffic effects on user traffic in the production
   network.  Section 5 of [RFC2680] lists the problems with high
   measurement traffic rates ("too much traffic"), and the most relevant

Morton                    Expires July 13, 2015                 [Page 5]
Internet-Draft           Rate Problem Statement             January 2015

   for rate measurement is the tendency for measurement traffic to skew
   the results, followed by the possibility of introducing congestion on
   the access link.  Section 4 of [RFC3148] provides additional
   considerations.  The user of protocols for In-Service testing MUST
   respect these traffic constraints.  Obviously, categories of rate
   measurement methods that use less active test traffic than others
   with similar accuracy are preferred for In-Service testing, and the
   specifications of this memo encourage traffic reduction through
   asymmetric control capabilities.

   Out-of-Service tests where the test path shares no links with In-
   Service user traffic, have none of the congestion or skew concerns.
   Both types should address practical matters common to all test
   efforts, such as conducting measurements within a reasonable time
   from the tester's point of view, and ensuring that timestamp accuracy
   is consistent with the precision needed for measurement [RFC2330].
   Out-of-Service tests where some part of the test path is shared with
   In-Service traffic MUST respect the In-Service constraints described

   The intended metrics to be measured have strong influence over the
   categories of measurement methods required.  For example, using the
   terminology of [RFC5136], it may be possible to measure a Path
   Capacity Metric while In-Service if the level of background (user)
   traffic can be assessed and included in the reported result.

   The measurement *architecture* MAY be either of one-way (e.g.,
   [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity
   aspects of end-user or aggregated access measurement clearly favor
   two-way (with low-complexity user-end device and round-trip results
   collection, as found in [RFC5357]).  However, the asymmetric rates of
   many access services mean that the measurement system MUST be able to
   evaluate performance in each direction of transmission.  In the two-
   way architecture, both end devices MUST include the ability to launch
   test streams and collect the results of measurements in both (one-
   way) directions of transmission (this requirement is consistent with
   previous protocol specifications, and it is not a unique problem for
   rate measurements).

   The following paragraphs describe features for the roles of test
   packet SENDER, RECEIVER, and results REPORTER.


   Generate streams of test packets with various characteristics as
   desired (see Section 4).  The SENDER MAY be located at the user end
   of the access path or elsewhere in the production network, such as at
   one end of an aggregated leased network segment.

Morton                    Expires July 13, 2015                 [Page 6]
Internet-Draft           Rate Problem Statement             January 2015


   Collect streams of test packets with various characteristics (as
   described above), and make the measurements necessary to support rate
   measurement at the receiving end of an access or aggregated leased
   network segment.


   Use information from test packets and local processes to measure
   delivered packet rates, and prepare results in the required format
   (the REPORTER role may be combined with another role, most likely the

4.  Measurement Method Categories

   A protocol that addresses the rate measurement problem MUST serve the
   test stream generation and measurement functions (SENDER and
   RECEIVER).  The follow-up phase of analyzing the measurement results
   to produce a report is outside the scope of this problem and memo

   For the purposes of this problem statement, we categorize the many
   possibilities for rate measurement stream generation as follows;

   1.  Packet pairs, with fixed intra-pair packet spacing and fixed or
       random time intervals between pairs in a test stream.

   2.  Multiple streams of packet pairs, with a range of intra-pair
       spacing and inter-pair intervals.

   3.  One or more packet ensembles in a test stream, using a fixed
       ensemble size in packets and one or more fixed intra-ensemble
       packet spacings (including zero spacing, meaning that back-to-
       back burst ensembles and constant rate ensembles fall in this

   4.  One or more packet chirps (a set of packets with specified
       characteristics), where inter-packet spacing typically decreases
       between adjacent packets in the same chirp and each pair of
       packets represents a rate for testing purposes.

   The test protocol SHALL support test packet ensemble generation
   (category 3), as this appears to minimize the demands on measurement
   accuracy.  Other stream generation categories are OPTIONAL.

Morton                    Expires July 13, 2015                 [Page 7]
Internet-Draft           Rate Problem Statement             January 2015

   For all supported categories, the following is a list of additional
   variables that the protocol(s) MUST be able to specify, control, and

   a.  Variable payload lengths among packet streams

   b.  Variable length (in packets) among packet streams or ensembles

   c.  Variable IP header markings among packet streams

   d.  Choice of UDP transport and variable port numbers, OR, choice of
       TCP transport and variable port numbers for two-way architectures
       only, OR BOTH.  See below for additional requirements on TCP
       transport generation.

   e.  Variable number of packet-pairs, ensembles, or streams used in a
       test session.

   The ability to revise these variables during an established test
   session is OPTIONAL, as multiple test sessions could serve the same
   purpose.  Another OPTIONAL feature is the ability to generate streams
   with VLAN tags and other markings.

   For measurement systems employing TCP as the transport protocol, the
   ability to generate specific stream characteristics requires a sender
   with the ability to establish and prime the connection such that the
   desired stream characteristics are allowed.  See Mathis' work in
   progress for more background [I-D.ietf-ippm-model-based-metrics].

   Beyond simple connection handshake and options establishment, an
   "open-loop" TCP sender requires the SENDER ability to:

   o  generate TCP packets with well-formed headers (all fields valid),
      including Acknowledgement aspects.

   o  produce packet streams at controlled rates and variable inter-
      packet spacings, including packet ensembles (back-to-back at
      server rate).

   o  continue the configured sending stream characteristics despite all
      control indications except receive window exhaust.

   The corresponding TCP RECEIVER performs normally, having some ability
   to configure the receive window sufficiently large so as to allow the
   SENDER to transmit at will (up to a configured target).

   It may also be useful (for diagnostic purposes) to provide a control
   for Bulk Transfer Capacity measurement with fully-specified (and

Morton                    Expires July 13, 2015                 [Page 8]
Internet-Draft           Rate Problem Statement             January 2015

   congestion-controlled) TCP senders and receivers, as envisioned in
   [RFC3148], but this would be a brute-force assessment which does not
   follow the conservative tenets of IPPM measurement [RFC2330].

   Measurements for each UDP test packet transferred between SENDER and
   RECEIVER MUST be compliant with the singleton measurement methods
   described in IPPM RFCs [RFC2679][RFC2680].  The time-stamp
   information or loss/arrival status for each packet MUST be available
   for communication to the REPORTER function.

5.  Test Protocol Control & Generation Requirements

   In summary, the test protocol must support the measurement features
   described in the sections above.  This requires:

   1.  Communicating all test variables to the SENDER and RECEIVER

   2.  Results collection in a one-way architecture

   3.  Remote device control for both one-way and two-way architectures

   4.  Asymmetric packet rates in a two-way measurement architecture, or
       coordinated one-way test capabilities with the same effect
       (asymmetric rates may be achieved through directional control of
       packet rate or packet size)

   The ability to control and generate asymmetric rates in a two-way
   architecture is REQUIRED.  Two-way architectures are RECOMMENDED to
   include control and generation capability for both asymmetric and
   symmetric packet sizes, because packet size often matters in the
   scope of this problem and test systems SHOULD be equipped to detect
   directional size dependency through comparative measurements.

   Asymmetric packet size control is indicated when the result of a
   measurement may depend on the size of the packets used in each
   direction, i.e. when any of the following conditions hold:

   o  there is a link in the path with asymmetrical capacity in opposite
      directions (in combination with one or more of the conditions
      below, but their presence or specific details may be unknown to
      the tester),

   o  there is a link in the path which aggregates (or divides) packets
      into link-level frames, and may have a capacity that depends on
      packet size, rate, or timing,

   o  there is a link in the path where transmission in one direction
      influences performance in the opposite direction,

Morton                    Expires July 13, 2015                 [Page 9]
Internet-Draft           Rate Problem Statement             January 2015

   o  there is a device in the path where transmission capacity depends
      on packet header processing capacity (in other words, the capacity
      is sensitive to packet size),

   o  the target application stream is nominally MTU size packets in one
      direction vs. ACK stream in the other, (noting that there are a
      vanishing number of symmetrical-rate application streams for which
      rate measurement is wanted or interesting, but such streams might
      have some relevance at this time),

   o  the distribution of packet losses is critical to rate assessment,

   and possibly other circumstances revealed by measurements comparing
   streams with symmetrical size and asymmetrical size.

   Implementations may support control and generation for only symmetric
   packet sizes when none of the above conditions hold.

   The test protocol SHOULD enable measurement of the [RFC5136] Capacity
   metric, either Out-of-Service, In-Service, or both.  Other [RFC5136]
   metrics are OPTIONAL.

6.  Security Considerations

   The security considerations that apply to any active measurement of
   live networks are relevant here as well.  See [RFC4656] and

   There may be a serious issue if a proprietary Service Level Agreement
   involved with the access network segment provider were somehow leaked
   in the process of rate measurement.  To address this, test protocols
   SHOULD NOT convey this information in a way that could be discovered
   by unauthorized parties.

7.  Operational Considerations

   All forms of testing originate traffic on the network, through their
   communications for control and results collection, or from dedicated
   measurement packet streams, or both.  Testing traffic primarily falls
   in one of two categories, subscriber traffic or network management
   traffic.  There is an on-going need to engineer networks so that
   various forms of traffic are adequately served, and publication of
   this memo does not change this need.  Service subscribers and
   authorized users SHOULD obtain their network operator's or service
   provider's permission before conducting tests.  Likewise, a service
   provider or third party SHOULD obtain the subscriber's permission to
   conduct tests, since they might temporarily reduce service quality.

Morton                    Expires July 13, 2015                [Page 10]
Internet-Draft           Rate Problem Statement             January 2015

   Subscribers, their service providers and network operators, and
   sometimes third parties, all seek to measure network performance.
   Capacity testing with active traffic often affects the packet
   transfer performance of streams traversing shared components of the
   test path, to some degree.  The degradation can be minimized by
   scheduling such tests infrequently, and restricting the amount of
   measurement traffic required to assess capacity metrics.  As a
   result, occasional short-duration estimates with minimal traffic are
   preferred to measurements based on frequent file transfers of many
   Megabytes with similar accuracy.  New measurement methodologies
   intended for standardization should be evaluated individually for
   potential operational issues.  However, the scheduled frequency of
   testing is as important as the methods used (and schedules are not
   typically submitted for standardization).

   The new test protocol feature of asymmetrical packet size generation
   in two-way testing is recommended in this memo.  It can appreciably
   reduce the load and packet processing demands of each test and
   therefore reduce the likelihood of degradation in one direction of
   the tested path.  Current IETF standardized test protocols do not
   possess the asymmetric size generation capability with two-way

8.  IANA Considerations

   This memo makes no requests of IANA.

9.  Acknowledgements

   Dave McDysan provided comments and text for the aggregated leased use
   case.  Yaakov Stein suggested many considerations to address,
   including the In-Service vs. Out-of-Service distinction and its
   implication on test traffic limits and protocols.  Bill Cerveny,
   Marcelo Bagnulo, Kostas Pentikousis (a persistent reviewer), and
   Joachim Fabini have contributed insightful, clarifying comments that
   made this a better draft.  Barry Constantine also provided
   suggestions for clarification.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

Morton                    Expires July 13, 2015                [Page 11]
Internet-Draft           Rate Problem Statement             January 2015

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

   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protocol
              (OWAMP)", RFC 4656, September 2006.

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, October 2008.

   [RFC6703]  Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
              IP Network Performance Metrics: Different Points of View",
              RFC 6703, August 2012.

10.2.  Informative References

              Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
              A. Morton, "A Reference Path and Measurement Points for
              Large-Scale Measurement of Broadband Performance", draft-
              ietf-ippm-lmap-path-07 (work in progress), October 2014.

              Mathis, M. and A. Morton, "Model Based Bulk Performance
              Metrics", draft-ietf-ippm-model-based-metrics-03 (work in
              progress), July 2014.

   [RFC3148]  Mathis, M. and M. Allman, "A Framework for Defining
              Empirical Bulk Transfer Capacity Metrics", RFC 3148, July

   [RFC5136]  Chimento, P. and J. Ishac, "Defining Network Capacity",
              RFC 5136, February 2008.

   [RFC6812]  Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare,
              S., and E. Yedavalli, "Cisco Service-Level Assurance
              Protocol", RFC 6812, January 2013.

Author's Address

Morton                    Expires July 13, 2015                [Page 12]
Internet-Draft           Rate Problem Statement             January 2015

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

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192

Morton                    Expires July 13, 2015                [Page 13]