Large-Scale Measurement of Broadband Performance
charter-ietf-lmap-00-00
Document | Proposed charter | Large-Scale Measurement of Broadband Performance WG (lmap) Snapshot | |
---|---|---|---|
Title | Large-Scale Measurement of Broadband Performance | ||
Last updated | 2013-05-29 | ||
State | Not currently under review | ||
WG | State | BOF | |
IESG | Responsible AD | Benoît Claise | |
Charter edit AD | (None) | ||
Send notices to | (None) |
Measuring portions of the Internet on a large scale is vital 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 ultimate goal is to have the same measurements for a
large number of points on the Internet, conducted according to the same
characterization plan, and to have the results collected and stored in the same form.
Many measurement systems that exist today use proprietary, custom-designed
mechanisms to coordinate their Measurement Agents (MAs) deployed across
networks, to communicate between MAs and measurement Controllers, and to transfer
results to measurement Collectors.
Standardizing these mechanisms (Control protocol, Report protocol, and
corresponding data models) will make it possible to incorporate interoperable
measurement communications into home and enterprise edge routers, personal
computers, mobile devices and other networking devices, whether wired or wireless.
Standards will help these management capabilities become more pervasive and
facilitate measurement results that are directly comparable.
The Large-Scale Measurement of Broadband Performance (LMAP) working group is
chartered to determine the form of data models and select/extend one or more
protocols for the communications between the Measurement Agents' (MAs) function
and their Controller function and Collector function. These three functions comprise the
LMAP measurement system.
The standardized LMAP mechanisms will allow a Controller to instruct MAs what
performance metrics to measure, when to measure them, how/when to report the
measurement results to a Collector, and then for the MA to report the results to the
Collector. The primary products of the working group are the data models that define
the measurement instructions and reports, and protocols for securely delivering these
data models to/from the MAs. Data models should be extensible for new and additional
measurements.
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 MAs 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. In the initial chartering phase, 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 hub, 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. At a high
level, LMAP systems are agnostic to the measurements and results, and extensible to
incorporate evolution in the measurement area, but the details such as the data
models must be standardized to match the measurements.
Inter-organization communication of results is not addressed in the LMAP system and
is deferred to bi-lateral agreements.
Many measurement aspects are already within the charter of IPPM. These include
standardized definitions of performance metrics, MA-to-MA measurement protocols,
and a registry of frequently-used metrics and parameter settings so they can be
identified in an efficient and consistent fashion. Neither the definition of the new
metrics and methods of measurement, nor the post-processing and analysis of results
falls within the remit of LMAP.
The case where an end user can independently perform network diagnostic
measurements (beyond their private network) is not directly in scope, recognizing that
users have many opportunities to do this today.
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.
Another area that is out of scope is the management protocol to bootstrap the MAs in
measurement devices, although a bootstrapping process may be described and
conducted in many ways, such as configuration during manufacture or with a local
USB interface.
Discovering the service parameters on the MAs or sharing the service parameters
between MAs are out of the scope of the LMAP charter.
However, if the service parameters are available to the MAs, they could be combined
with the measurement results in the Report Protocol.
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. Deciding the set of
measurements to run is a business decision and is out of scope.
Exhaustive protection against all possibilities of gaming the measurements - where
gaming is defined as intentionally (and perhaps
maliciously) inserting inaccuracy into the overall system or measurement process - is
beyond the scope of work. Some protections are lawyer problems, not engineering
problems. However, the working group may include protections that do not add
significant complexity, as determined by working group consensus.
The LMAP working group will coordinate with other standards bodies working in this
area (e.g., BBF, IEEE 802.16, ETSI), and other IETF working groups in the areas of
data models, protocols, multiple interface management, and measurement of
performance metrics.
LMAP will consider re-use of existing protocols and data model languages in its efforts
to produce the following work items:
- The LMAP Framework - provides common terminology and justifies the simplifying constraints
- The LMAP Use Cases - provides the motivating use cases as a basis for the work
- 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) to 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. - 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 is 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). - 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).
The WG will decide later whether protocols and data models (for Control, respectively
Report) will be defined in one or separated documents.