Fwd: WG Review: Large-Scale Measurement of Broadband Performance (lmap)

Fri Jun 14 23:04:39 UTC 2013

Dear all,

FYI.
Please your feedback to the IETF mailing list, or directly to Joel (in 
the cc) and me

Regards, Benoit

-------- Original Message --------
Subject: 	WG Review: Large-Scale Measurement of Broadband Performance 
(lmap)
Date: 	Fri, 14 Jun 2013 08:41:55 -0700
From: 	The IESG <iesg-secretary at ietf.org>
Reply-To: 	ietf at ietf.org
To: 	IETF-Announce <ietf-announce at ietf.org>
CC: 	lmap WG <lmap at ietf.org>

A new IETF working group has been proposed in the Operations and
Management Area. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list (iesg
at ietf.org) by 2013-06-24.

Large-Scale Measurement of Broadband Performance (lmap)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
   Benoit Claise <bclaise at cisco.com>

Mailing list
   Address: lmap at ietf.org
   To Subscribe: http://www.ietf.org/mailman/listinfo/lmap
   Archive: http://www.ietf.org/mail-archive/web/lmap

Charter:

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

Milestones:

Sep 2013  Initial WG I-D for the LMAP Framework including terminology
Sep 2013  Initial WG I-D for the LMAP Use cases
Dec 2013  Submit the LMAP Framework I-D to the IESG for consideration as
           Informational RFC
Dec 2013  Submit I-D on the LMAP Use cases to the IESG for consideration
           as Informational RFC
Jan 2014  Initial WG I-D for LMAP Information models
Apr 2014  Initial WG I-D for the Control protocol
Apr 2014  Initial WG I-D for the Report protocol
Apr 2014  Initial WG I-D for a Data model for LMAP control information
Apr 2014  Initial WG I-D for a Data model for LMAP report information
Jul 2014  Submit the LMAP Information models I-D to the IESG for
           consideration as Standards track RFC
Dec 2014  Submit the Control protocol I-D to the IESG for consideration
           as Standards track RFC
Dec 2014  Submit the Report protocol I-D to the IESG for consideration
           as Standards track RFC
Dec 2014  Submit the Data model for LMAP control I-D to the IESG for
           consideration as Standards track RFC
Dec 2014  Submit the Data model for LMAP report I-D to the IESG for
           consideration as Standards track RFC