Large-Scale Measurement of Broadband Performance
charter-ietf-lmap-01

Document Charter Large-Scale Measurement of Broadband Performance WG (lmap)
Title Large-Scale Measurement of Broadband Performance
Last updated 2013-06-28
State Approved
WG State Active
IESG Responsible AD Benoit Claise
Charter Edit AD Benoit Claise
Send notices to (None)

Charter
charter-ietf-lmap-01

The Large-Scale Measurement of Broadband Performance (LMAP) working group
standardizes the LMAP measurement system for performance measurements of
broadband access devices such as home and enterprise edge routers, personal
computers, mobile devices, set top box, whether wired or wireless.

Measuring portions of the Internet on a large scale is essential for accurate
characterizations of performance over time and geography, for network diagnostic
investigations by providers and their users, and for collecting information to
support public policy development. The goal is to have the measurements (made
using the same metrics and mechanisms)
 for a large number of points on the Internet, and to have the results collected
and stored in the same form.
 
The LMAP working group is chartered to specify an information model, the
associated data models, and select/extend one or more protocols for the secure
communication: 
1.      A Control Protocol, from a Controller to instruct Measurement Agents
what performance metrics to measure, when to measure them, how/when to report
the measurement results to a Collector,
2.      A Report Protocol, for a Measurement Agent to report the results to the
Collector. 
The data models should be extensible for new and additional measurements. LMAP
will consider re-use of existing data models languages.

A key assumption constraining the initial work is that the measurement system is
under the control of a single organization (for example, an Internet Service
Provider or a regulator). However, the components of an LMAP measurement system
can be deployed in administrative domains that are not owned by the measuring
organization. Thus, the system of functions deployed by a single organization
constitutes a single LMAP domain which may span ownership or other
administrative boundaries. 

The LMAP architecture will allow for measurements that utilize either IPv4 or
IPv6, or possibly both. Devices containing Measurement Agents may have several
interfaces using different link technologies. Multiple address families and
interfaces must be considered in the Control and Report protocols.

It is assumed that different organization's LMAP measurement domains can
overlap, and that active measurement packets appear along with normal user
traffic when crossing another organization's network. There is no requirement to
specify a mechanism for coordination between the LMAP measurements in
overlapping domains (for instance a home network with MAs on the home gateway,
set top box and laptop). In principle, there are no restrictions on the type of
device in which the MA function resides. 

Both active and passive measurements are in scope, although there may be
differences in their applicability to specific use cases, or in the security
measures needed according to the threats specific to each measurement category.
LMAP will not standardize performance metrics.

The LMAP WG will consider privacy as a core requirement and will ensure that by
default measurement and collection mechanisms and protocols standardized 
operate in a privacy-sensitive manner, for example, ensuring that measurements
are not personally identifying except where permission for such has been granted
by identified subjects. Note that this does not mean that all uses of LMAP need
to turn on all privacy features but it does mean that privacy features do need
to be at least well-defined.

Standardizing control of end users Measurement Agents is out of scope.
However, end users can obtain an MA to run measurement tasks if desired and
report their results to whomever they want, most likely the supplier of the MA.
This provides for user-initiated on-demand measurement, which is an important
component of the ISP use case.

Inter-organization communication of results is out of scope of the LMAP
charter.

The management protocol to bootstrap the MAs in measurement devices is out of
scope of the LMAP charter. 

Service parameters, such as product category, can be useful to decide which
measurements to run and how to interpret the results. These parameters are
already gathered and stored by existing operations systems. 
Discovering the service parameters on the MAs or sharing the service parameters
between MAs are out of the scope. However, if the service parameters are
available to the MAs, they could be reported with the measurement results in the
Report Protocol.

Deciding the set of measurements to run is a business decision and is out of
scope of the LMAP charter.

Protection against the intentional or malicious insertion of inaccuracies into
the overall system or measurement process (sometimes known as "gaming the
system") is outside the scope of work. 

The LMAP working group will coordinate with other standards bodies working in
this area (e.g., BBF, IEEE 802.16, ETSI) regarding the information model, and
with other IETF working groups in the areas of data models, protocols, multiple
interface management, and measurement of performance metrics.

The LMAP WG will produce the following work items:

1. The LMAP Framework - provides common terminology, basic architecture
elements, and justifies the simplifying constraints
2. The LMAP Use Cases - provides the motivating use cases as a basis for the
work
3. Information Model, the abstract definition of the information carried from
the Controller to the MA and the information carried from the MA to the
Collector. It includes
   * The metric(s) that can be measured and values for its parameters such as
the Peer MA participating in the measurement and the desired environmental
conditions (for example, only conduct the measurement when there is no user
traffic observed)
  * The schedule: when the measurement should be run and how the results should
be reported (when and to which Collector) 
  * The report: the metric(s) measured and when, the actual result, and
supporting metadata such as location. Result reports may be organized in batches
or may be reported immediately, such as for an on-demand measurement.
4. The Control protocol and the associated data model: The definition of how
instructions are delivered from a Controller to a MA; this includes a Data Model
consistent with the Information Model plus a transport protocol.  This may be a
simple instruction - response protocol, and LMAP will specify how it operates
over an existing protocol (to be selected, perhaps REST-style HTTP(s) or
NETCONF).
5. The Report protocol and the associated data model: The definition of how the
Report is delivered from a MA to a Collector; this includes a Data Model
consistent with the Information Model plus a transport protocol (to be selected,
perhaps REST-style HTTP(s) or IPFIX).