Terminology for Large MeAsurement Platforms (LMAP)
draft-eardley-lmap-terminology-01
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Philip Eardley , Al Morton , Marcelo Bagnulo , Trevor Burbridge | ||
| Last updated | 2013-05-02 | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| 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-01
Network Working Group P. Eardley
Internet-Draft BT
Intended status: Standards Track A. Morton
Expires: November 03, 2013 AT&T Labs
M. Bagnulo
UC3M
T. Burbridge
BT
May 02, 2013
Terminology for Large MeAsurement Platforms (LMAP)
draft-eardley-lmap-terminology-01
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 November 03, 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
Eardley, et al. Expires November 03, 2013 [Page 1]
Internet-Draft LMAP Terminology May 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 . . . . . . . . . . 5
4. Commentary and notes . . . . . . . . . . . . . . . . . . . . 6
5. Security considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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
measures the associated round trip latency (using a second timestamp
associated with arrival).
Eardley, et al. Expires November 03, 2013 [Page 2]
Internet-Draft LMAP Terminology May 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, 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)
The Report consists of following items:
1. 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.
2. The configuration of parameters associated with the Report (for
example, the address of the Collector to which the Report is
sent)
Eardley, et al. Expires November 03, 2013 [Page 3]
Internet-Draft LMAP Terminology May 2013
3. 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 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.
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.
Eardley, et al. Expires November 03, 2013 [Page 4]
Internet-Draft LMAP Terminology May 2013
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.
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.
Eardley, et al. Expires November 03, 2013 [Page 5]
Internet-Draft LMAP Terminology May 2013
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.
Measurement Parameter: A parameter whose value is left open by the
Measurement Method.
Environmental Constraint: A parameter that is measured as part of the
Measurement Task, its value determining whether the rest of the
Measurement Task proceeds.
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 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).
Eardley, et al. Expires November 03, 2013 [Page 6]
Internet-Draft LMAP Terminology May 2013
The consensus seems to be that the proposed LMAP working group should
make the assumption 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.
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 Measurement Agent and
Collector is severely constrained and/or the full set of Measurement
Results provides little extra information.
Eardley, et al. Expires November 03, 2013 [Page 7]
Internet-Draft LMAP Terminology May 2013
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 seems to be that the prospective working group
should define the bootstrap process but not a protocol. The reason
is that 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).
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.
5. Security considerations
There are no security considerations in this memo.
6. IANA Considerations
There are no IANA considerations in this memo.
7. Acknowledgments
Eardley, et al. Expires November 03, 2013 [Page 8]
Internet-Draft LMAP Terminology May 2013
We thank participants on the LMAP mailing list for their input,
especially Juergen Schoenwaelder for his detailed review.
8. History
from -00 to -01:
'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.
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.
Authors' Addresses
Philip Eardley
British Telecom
Adastral Park, Martlesham Heath
Ipswich
ENGLAND
Email: philip.eardley@bt.com
Eardley, et al. Expires November 03, 2013 [Page 9]
Internet-Draft LMAP Terminology May 2013
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 November 03, 2013 [Page 10]