Skip to main content

Terminology for Large-Scale Measurement of Broadband Performance (LMAP) Platforms
draft-eardley-lmap-terminology-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 Philip Eardley , Al Morton , Marcelo Bagnulo , Trevor Burbridge
Last updated 2013-04-12
RFC stream (None)
Formats
Additional resources
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-eardley-lmap-terminology-00
Network Working Group                                         P. Eardley
Internet-Draft                                                        BT
Intended status: Standards Track                               A. Morton
Expires: October 14, 2013                                      AT&T Labs
                                                              M. Bagnulo
                                                                    UC3M
                                                            T. Burbridge
                                                                      BT
                                                          April 12, 2013

Terminology for Large-Scale Measurement of Broadband Performance (LMAP)
                               Platforms
                   draft-eardley-lmap-terminology-00

Abstract

   This documents defines terminology for Large Scale Measurement
   Platforms.

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 October 14, 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

Eardley, et al.         Expires October 14, 2013                [Page 1]
Internet-Draft              LMAP Terminology                  April 2013

   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.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  LMAP Terminology  . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Commentary and notes  . . . . . . . . . . . . . . . . . . . .   6
   5.  Security considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   This document defines terminology for LMAP (in Section 3).  Since
   'raw' terminology is reader-unfriendly, Section 2 provides an initial
   idea of the terminology by explaining how LMAP works whilst using the
   terms.  Section 4 provides some commentary on the terminology,
   including a comparison with that in [RFC2330].

   Please note that defined terms are capitalized.

2.  Summary

   A Measurement Task is an act that yields a single Measurement Result.
   An Active Measurement Task involves a Measurement Agent injecting
   test packet(s) into the network destined for another Measurement
   Agent and measuring some performance or reliability parameter
   associated with the transfer.  The generic version of the Measurement
   Task is the Measurement Method; in other words the Measurement Task
   is the instantiation of the Measurement Method at a specific time and
   place.

   For example, a Measurement Method might be the injection of a UDP
   packet by one Measurement Agent destined for another Measurement
   Agent, which immediately reflects the UDP packet back to the first
   Measurement Agent, which measures the round trip latency.  The
   associated Measurement Task might be: the injection of a UDP packet
   by the Measurement Agent at 138.246.23.109 destined for the
   Measurement Agent at 138.145.75.32 at UTC 13:01 and 58.6 seconds on
   2013-06-15, with the second Measurement Agent immediately reflecting
   the UDP packet back to the source, which measures the associated
   round trip latency (using a second timestamp associated with
   arrival).

Eardley, et al.         Expires October 14, 2013                [Page 2]
Internet-Draft              LMAP Terminology                  April 2013

   A Metric is a parameter of interest that is related to the
   performance and reliability of the Internet.  For example, "UDP
   latency".  Typically the value of a Metric is assessed as simply the
   average of several Measurement Results.  However a Derived Metric
   consists of some combination of various Measurement Results.  For
   example, the delay variation of a path can be assessed by subtracting
   two values of one-way delay [RFC3393], or the bulk transport capacity
   might be assessed by combining several different parameters as
   suggested in [I-D.mathis-ippm-model-based-metrics].

   How and when to perform the Measurement Task and report the
   Measurement Result is defined by the Instruction, which the
   Controller sends to the Measurement Agent.  Whilst the Instruction
   may define a single Measurement Task, more typically it defines a
   series of Measurement Tasks, all based on the same Measurement Method
   and carried out at regular times according to a Measurement Schedule.
   The Measurement Result of the former is likely to be reported
   immediately, whilst Measurement Results of the latter will be sent at
   regular time intervals, as defined by the Report Schedule.  The
   Instruction consists of:

   o  The Measurement Method: typically this is defined by a reference
      in a well-known registry (for example, 'how to measure UDP
      latency')

   o  The configuration of parameters left open by the Measurement
      Method (for example, the addresses of the two Measurement Agents)

   o  The Measurement Schedule (for example, start at 0400 UTC, repeat
      every 500 ms, end at 0403 UTC)

   o  Any environmental constraints (for example, do not perform the
      Measurement Task if there is cross-traffic)

   o  The above bullets effectively define a series of Measurement Tasks

   o  The definition of the Report.  Typically the Report includes every
      single Measurement Result (since the last Report), but it may
      instead be a statistic (such as their average).  Typically the
      Report also includes other relevant information, for example an
      'echo' of the Measurement Method, configuration parameters and
      schedule.

   o  The configuration of parameters associated with the Report (for
      example, the address of the Collector to which the Report is sent)

   o  The Report Schedule (for example, send once a day at 01:00 hours)

Eardley, et al.         Expires October 14, 2013                [Page 3]
Internet-Draft              LMAP Terminology                  April 2013

   The Control Protocol and Report Protocol define the delivery of the
   Instruction and the Report (respectively); they consist of a Data
   Model (the semantics and structure of the information, in a
   particular language such as JSON or YANG) and a transport protocol
   (such as HTTP or NETCONF).

3.  LMAP Terminology

   Active Measurement Method (Task): A type of Measurement Method (Task)
   that involves two Measurement Agents, where one Measurement Agent
   injects test packet(s) into the network destined for another
   Measurement Agent and which involves one of the Measurement Agents
   measuring some performance or reliability parameter associated with
   the transfer of the packet(s).

   Collector: A function that receives a Report from a Complete
   Measurement Agent.  Colloquially, a Collector is a physical device
   that performs this function.

   Complete Measurement Agent (Complete-MA): A type of Measurement Agent
   that additionally includes functionality that receives an Instruction
   from a Controller and reports Results to a Collector

   Controller: A function that provides a Complete-MA with an
   Instruction.  Colloquially, a Controller is a physical device that
   performs this function.

   Control Protocol: The definition of how the Instruction is delivered
   from a Controller to a Complete-MA; a Data Model plus a transport
   protocol.

   Data Model: The implementation of an Information Model in a
   particular data modelling language.

   Derived Metric: A Metric that is a combination of other Metrics, and/
   or a combination of the same Metric measured over different parts of
   the network, or at different times.

   Information Model: The abstract definition of either the Instruction
   or the Report; the semantics of the fields and their arrangement (the
   order they appear in and any hierarchy).

   Instruction: The description of Measurement Tasks to perform and the
   details of the Report to send; a specific instance of the Data Model.
   The Instruction is sent by a Controller to a Complete-MA.

Eardley, et al.         Expires October 14, 2013                [Page 4]
Internet-Draft              LMAP Terminology                  April 2013

   Measurement Agent (MA): The function that performs a Measurement
   Task.  Colloquially, a Measurement Agent is a physical device that
   performs this function.

   Measurement Method: The process for assessing the value of a Metric;
   the process of measuring some performance or reliability parameter;
   the generalisation of a Measurement Task.

   Measurement Result: The output of a single Measurement Task (the
   value obtained for the parameter of interest, or metric)

   Measurement Schedule: the schedule for performing a series of
   Measurement Tasks

   Measurement Task: The act that yields a single Measurement Result;
   the act consisting of the (single) operation of the Measurement
   Method at a particular time and with all its parameters set to
   specific values

   Metric: The quantity related to the performance and reliability of
   the Internet that we'd like to know the value of, and that is
   carefully specified.

   Passive Measurement Method (Task): A Measurement Method (Task) in
   which a Measurement Agent observes existing traffic at a specific
   measurement point, but does not inject test packet(s).

   Remote Measurement Agent (Remote-MA): A type of Measurement Agent
   that does not receive an Instruction from a Controller and does not
   send a Report to a Collector; it may receive control messages and
   test packet(s) from a Complete-MA and may reply to the Complete-MA,
   as defined by the Measurement Method.

   Report: The Measurement Results and other associated information (as
   defined by the Instruction); a specific instance of the Data Model.
   The Report is sent by a Complete-MA to a Collector

   Report Protocol: The definition of how the Report is delivered from a
   Complete-MA to a Collector; a Data Model plus a transport protocol.

   Report Schedule: the schedule for sending a series of Reports to a
   Collector.

Eardley, et al.         Expires October 14, 2013                [Page 5]
Internet-Draft              LMAP Terminology                  April 2013

4.  Commentary and notes

   To avoid confusion the word 'Measurement' is only used as an
   adjective.

   It is worth explaining how the terms defined here compare with those
   in [RFC2330], "Framework for IP Performance Metrics".  The definition
   of Metric is taken from RFC2330.  The definition of Measurement
   Method is (we believe) equivalent in RFC2330's terms to a measurement
   methodology for a singleton metric.  A set of Measurement Tasks
   defined by a Measurement Schedule relates to RFC2330's concept of a
   sample metric.

   If a Measurement Method is used multiple times under identical or
   similar conditions, it should result in a consistent value for the
   Metric.

   A Measurement Method may be a more specific version of another
   Measurement Method.  For example,
   [I-D.bagnulo-ippm-new-registry-independent] defines UDP latency as a
   round trip delay [RFC2681] with the packet type set to UDP.

   A registry, as proposed in
   [I-D.bagnulo-ippm-new-registry-independent], would be a registry of
   Measurement Methods and their associated Metrics.  A Passive
   Measurement Method (Task) involves only one MA, which therefore must
   be a Complete-MA; for example, it measures the mix of applications.
   An Active Measurement Method (Task) involves another MA (typically a
   Remote-MA).  It is possible that some Active Measurement Methods
   (Tasks) involve more than two MAs; for example, to measure 'latency
   under load' test traffic may be sent between two MAs whilst a third
   MA generates the load (cross-traffic).  In these circumstances the
   definition of Active Measurement Method (Task) may need a small
   adjustment.  This is for later study.

   The WG makes the assumption that a Complete-MA receives Instruction
   from only a single Controller at any point in time (however it may
   Report to more than one Collector).

   By definition a Remote-MA does not interact with a Controller or
   Collector.  A Remote-MA will typically respond to the test packet(s)
   from the Complete-MA.  For example, it may echo a UDP packet, or
   measure the amount of loss of the test packets and then send the
   Measurement Results to the Complete-MA.

   The MA is implemented either in specialised hardware or as code on
   general purpose devices like a PC, tablet or smartphone.  Note that a
   Remote-MA may not have specific LMAP or IPPM functionality.  For

Eardley, et al.         Expires October 14, 2013                [Page 6]
Internet-Draft              LMAP Terminology                  April 2013

   example, to assess DNS response time a Complete-MA sends DNS requests
   to a standard DNS server.

   A Controller can send an Instruction for immediate action, containing
   a one-off Measurement Task.  This is in addition to the more typical
   scenario of a series of Measurement Tasks carried out on a regular
   schedule, with the Measurement Results reported periodically.

   It may be sensible for an Instruction to be able to refer to more
   than one Measurement Method.  This is for further study.

   The right set of Information Models is for further study - for
   example, perhaps there should be three Information Models, with one
   containing all the scheduling information.  Also, note that different
   fields of the Information Models may be relevant for different
   Measurement Methods.

   The Control Protocol defines the Data Model and so effectively
   defines the Instruction.  The Instruction includes: the Measurement
   Method; values for the parameters that the Measurement Method leaves
   open (configuration); when to perform the Measurement Tasks (the
   Measurement Schedule); any environmental conditions (such as "don't
   perform the Measurement Task if there is end user traffic present");
   the Report Protocol, which includes its Data Model; when to send a
   Report (the Report Schedule); where to send the Report (the address
   of the Collector) and values for any other parameters that the Report
   Protocol leaves open (configuration).  This is for discussion.

   Typically the Report includes every single Measurement Result, but it
   may instead be a statistic (such as their average).  The latter may
   be useful when the bandwidth between the MA and Collector is severely
   constrained and/or the full set of Measurement Results provides
   little extra information.

   The Report includes: the Measurement Results (or statistic based on
   them); the details of the Measurement Tasks (essentially a copy of
   much of the Instruction, for example the Measurement Method, the
   configuration parameters and the time at which each Measurement
   Result was obtained); and other relevant information known by the
   Complete-MA (such as the line's speed, the version of the MA, and the
   amount of cross-traffic during the measurement).  Again this is very
   much for discussion.

   A proposal for a Control Protocol based on HTTP is currently under
   development.  There are already Internet drafts describing a Control
   Protocol based on NETCONF and a Report Protocol based on IPFIX.

Eardley, et al.         Expires October 14, 2013                [Page 7]
Internet-Draft              LMAP Terminology                  April 2013

   The Broadband Forum defines a Management Server [http://
   datatracker.ietf.org/liaison/1243/]: "Manages and configures a
   physical device or network element.  Examples include a TR-069 ACS
   (Auto-Configuration Server), or an EMS (Element Management System)."
   At the moment we assume that the Broadband Forum will specify this
   function and so assume it is out of scope of LMAP.  Such an
   initialisation function seems essential for a large-scale measurement
   system.  There must be some automated way to associate a complete-MA
   to its Controller and Collector, including authentication
   credentials, to re-arrange such associations over time, and to pull
   the plug on rogue MAs.

5.  Security considerations

   There are no security considerations needed in a memo that only
   defines terminology.

6.  IANA Considerations

   There are no IANA considerations in this memo.

7.  Acknowledgments

8.  Informative References

   [I-D.bagnulo-ippm-new-registry-independent]
              Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
              A. Morton, "A registry for commonly used metrics.
              Independent registries", draft-bagnulo-ippm-new-registry-
              independent-00 (work in progress), January 2013.

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

   [I-D.mathis-ippm-model-based-metrics]
              Mathis, M. and A. Morton, "Model Based Internet
              Performance Metrics", draft-mathis-ippm-model-based-
              metrics-01 (work in progress), February 2013.

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

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

Eardley, et al.         Expires October 14, 2013                [Page 8]
Internet-Draft              LMAP Terminology                  April 2013

Authors' Addresses

   Phil Eardley
   British Telecom
   Adastral Park, Martlesham Heath
   IPswitch
   ENGLAND

   Email: philip.eardley@bt.com

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

   Email: acmorton@att.com

   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
   IPswitch
   ENGLAND

   Email: trevor.burbridge@bt.com

Eardley, et al.         Expires October 14, 2013                [Page 9]