Large-Scale Measurement of Broadband Performance
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).