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


           Terminology for Large MeAsurement Platforms (LMAP)
                   draft-eardley-lmap-terminology-02

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 January 12, 2014.

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



Eardley, et al.         Expires January 12, 2014                [Page 1]


Internet-Draft              LMAP Terminology                   July 2013


   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
     3.1.  Other potentially useful terminology  . . . . . . . . . .   6
   4.  Commentary and notes  . . . . . . . . . . . . . . . . . . . .   6
   5.  Security considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  History . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  from -00 to -01:  . . . . . . . . . . . . . . . . . . . .   9
     8.2.  from -01 to -02 . . . . . . . . . . . . . . . . . . . . .  10
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This document, in Section 3, defines terminology for LMAP.  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 (for example) a Measurement Agent
   injecting test packet(s) into the network destined for a Measurement
   Peer 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 a Measurement Agent destined for a Measurement Peer, which
   immediately reflects the UDP packet back to the 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 192.0.2.0 destined for the Measurement Peer at 198.51.100.0 at UTC
   13:01 and 58.6 seconds on 2013-06-15, with the Measurement Peer
   immediately reflecting the UDP packet back to the source, which



Eardley, et al.         Expires January 12, 2014                [Page 2]


Internet-Draft              LMAP Terminology                   July 2013


   measures the associated round trip latency (using a second timestamp
   associated with arrival).

   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, a path delay might be assessed by adding several component
   delays, 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 the following items (which effectively define
   a series of Measurement Tasks):

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

   2.  The configuration of parameters left open by the Measurement
       Method (for example, the addresses of the Measurement Agent and
       Measurement Peer)

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

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

   5.  How and when to send a report:

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




Eardley, et al.         Expires January 12, 2014                [Page 3]


Internet-Draft              LMAP Terminology                   July 2013


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

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

   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 data modeling language such as a JSON schema language 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 a Measurement Agent and a Measurement Peer (or possibly
   Peers), where either the Measurement Agent or the Measurement Peer
   injects test packet(s) into the network destined for the other, and
   which involves one of them measuring some performance or reliability
   parameter associated with the transfer of the packet(s).

   Bootstrap Protocol: A protocol that initialises a Measurement Agent
   with the information necessary to talk to a Controller.

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

   Controller: A function that provides a Measurement Agent with
   Instruction(s).  Colloquially, a Controller is a physical device that
   performs this function.

   Control Protocol: The protocol delivering Instruction(s) from a
   Controller to a Measurement Agent.

   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 protocol-neutral definition of the semantics
   of either the Instruction or the Report.






Eardley, et al.         Expires January 12, 2014                [Page 4]


Internet-Draft              LMAP Terminology                   July 2013


   Instruction: The description of Measurement Tasks to perform and the
   details of the Report to send.  The Instruction is sent by a
   Controller to a Measurement Agent.

   Measurement Agent (MA): The function that receives Instructions from
   a Controller, performs Measurement Tasks (perhaps in concert with a
   Measurement Peer) and reports Measurement Results to a Collector.
   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 Peer: The function that receives control messages and
   test packets from a Measurement Agent and may reply to the
   Measurement Agent as defined by the Measurement Method.

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

   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 Measurement Agent to a Collector.

   Report Protocol: The protocol delivering Report(s) from a Measurement
   Agent to a Collector.

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





Eardley, et al.         Expires January 12, 2014                [Page 5]


Internet-Draft              LMAP Terminology                   July 2013


3.1.  Other potentially useful terminology

   The following terms have also been suggested and will be included
   above, assuming they prove useful during the early stages of the LMAP
   work.

   Cycle-ID: A tag that is sent by the Controller in an Instruction and
   echoed by the MA in its Report; Measurement Results with the same
   Cycle-ID are expected to be comparable.

   Environmental Constraint: A parameter that is measured as part of the
   Measurement Task, its value determining whether the rest of the
   Measurement Task proceeds.

   Group-ID: An identifier of a group of MAs.

   Measurement Parameter: A parameter whose value is left open by the
   Measurement Method.

   Measurement Suppression: a type of Instruction that stops
   (suppresses) Measurement Tasks.

   Report Channel: a specific Report Schedule and Collector

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



Eardley, et al.         Expires January 12, 2014                [Page 6]


Internet-Draft              LMAP Terminology                   July 2013


   Measurement Methods and their associated Metrics.  A Passive
   Measurement Method (Task) involves only a Measurement Agent; for
   example, it measures the mix of applications.  An Active Measurement
   Method (Task) also involves a Measurement Peer.  It is possible that
   some Active Measurement Methods (Tasks) involve additional
   Measurement Agent(s) or Measurement Peer(s); for example, one way to
   measure 'latency under load' may be to send test traffic between a
   Measurement Agent and Measurement Peer whilst a second Measurement
   Peer generates the load (cross-traffic).

   The consensus is that the LMAP working group should assume that a
   Measurement Agent receives Instruction from only a single Controller
   at any point in time (however it may Report to more than one
   Collector).

   By definition a Measurement Peer does not interact with a Controller
   or Collector.  A Measurement Peer will typically respond to the test
   packet(s) from the Measurement Agent.  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 Measurement Agent.

   The Measurement Agent is implemented either in specialised hardware
   or as code on general purpose devices like a PC, tablet or
   smartphone.  Note that a Measurement Peer may not have specific LMAP
   or IPPM functionality.  For example, to assess DNS response time a
   Measurement Agent 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.

   [RFC3444] discusses the difference between an Information Model and
   Data Model.  An Informational Model "model[s] managed objects at a
   conceptual level, independent of any specific implementations or
   protocols used to transport the data ... it defines relationships
   between managed objects".  A Data Model is "defined at a lower level
   of abstraction and includes many details ... and include[s] protocol-
   specific constructs."  Multiple Data Models can be derived from a
   single Information Model, since a conceptual/abstract model can be
   implemented in different ways.  An Informational Model is for
   designers and operators, whilst a Data Model is for implementors.

   An Information Model can be divided into different parts and sub-
   parts, to allow the values in each part and sub-part to be updated



Eardley, et al.         Expires January 12, 2014                [Page 7]


Internet-Draft              LMAP Terminology                   July 2013


   independently.  For example, one part could be contain the
   Instruction Information and another the Reporting Information.  The
   Instruction could contain sub-parts for configuring Measurement Tasks
   and for setting Measurement Schedules (which may be updated at
   different times and frequencies).  This is discussed in
   [information-model]

   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 Measurement Agent 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
   Measurement Agent (such as the line's speed, the version of the
   Measurement Agent, 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.

   The job of a Bootstrap Protocol is to provide an automated way to
   associate a Measurement Agent to its Controller, including
   authentication credentials.  Similarly, there should be a way to pull
   the plug on rogue Measurement Agents.  The current consensus on the
   LMAP mailing list is that the working group should define the
   bootstrap process but not a protocol.  The reason is that it could be
   done in many different ways, depending on the device and the
   measurement system, for instance: loaded at manufacture, updated
   locally via USB port, or orchestrated via a protocol (which may be
   defined by organisations other than the IETF, for example, the
   Broadband Forum).



Eardley, et al.         Expires January 12, 2014                [Page 8]


Internet-Draft              LMAP Terminology                   July 2013


   The purpose of the Cycle-ID is to allow the data analysis tools to
   identify easily Measurement Results that are expected to be
   comparable, typically because the associated Measurement Tasks all
   operate the same Measurement Method with the same values for its
   parameters.  This set of Measurement Tasks could be termed the
   Measurement Cycle.

   An example of an Environmental Constraint is "no end-user traffic".
   The Measurement Agent could measure the amount of end-user traffic
   over the previous 10 seconds; if there is none then it uploads a file
   to the Measurement Peer, whilst if the end-user is active then it
   defers the upload.

   The Report Channel contains the details of one collector (including
   location and security information such as the certificate), and the
   timing for the report (when to report the results).  Each Report
   Channel is also given a local short name by which it can be
   referenced from a Measurement Schedule.

   The Group-ID identifies a group of interest to which a MA belongs.
   For example the group could represent an ISP, broadband product,
   technology, market classification, geographic region, or a
   combination of multiple such characteristics.  A MA can remain
   anonymous by including its Group-ID (and not its own identifier) in
   the Reports it sends.

   Measurement Suppression is used to over-ride the Measurement
   Schedule.  A Controller uses Measurement Suppresion to stop a MA
   making measurements for a defined or indefinite period.  For
   discussion of Measurement Suppression, see [information-model]

5.  Security considerations

   There are no security considerations in this memo.

6.  IANA Considerations

   There are no IANA considerations in this memo.

7.  Acknowledgments

   We thank participants on the LMAP mailing list for their input,
   especially Juergen Schoenwaelder for his detailed review.

8.  History

8.1.  from -00 to -01:




Eardley, et al.         Expires January 12, 2014                [Page 9]


Internet-Draft              LMAP Terminology                   July 2013


   'Complete Measurement Agent' replaced by 'Measurement Agent', and
   'Remote Measurement Agent' replaced by 'Measurement Peer'.

   Bootstrap protocol added

   Section 3.1 added, with terms Cycle-ID, Measurement Parameter and
   Environmental Constraints

   Adjustments to terms for: Active Measurement Method (Task), Control
   Protocol, Information Model, Instruction, Report Protocol.

8.2.  from -01 to -02

   Added to Section 3.1 the terms Group-ID, Measurement Suppression and
   Report Channel, as these are used in [information-model]

   Other minor clarifications.

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

   [information-model]
              Burbridge, T., Eardley, P., Bagnulo, M., and J.
              Schoenwaelder, "Information Model for Large-Scale
              Measurement Platforms (LMAP)", , <http://tools.ietf.org/
              html/draft-burbridge-lmap-information-model>.

Authors' Addresses






Eardley, et al.         Expires January 12, 2014               [Page 10]


Internet-Draft              LMAP Terminology                   July 2013


   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


   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















Eardley, et al.         Expires January 12, 2014               [Page 11]