| Internet-Draft | ALTO for LMAP | May 2023 |
| Xie, et al. | Expires 6 November 2023 | [Page] |
Measuring broadband performance on a large scale for network diagnostics is important to providers and users, as well as for public policy. The Large-scale Measurement of Broadband Performance (LMAP) framework, information model, and protocol have been developed for measurement task dissemination, initialization, reporting and storing.¶
This document uses the ALTO protocol to provide access to large-scale network measurement results, which could be useful to constitute the ALTO cost map service and the endpoint cost service. Potential ALTO protocol extensions are also discussed to better leverage LMAP measurement results.¶
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 https://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 6 November 2023.¶
Copyright (c) 2023 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Measuring broadband performance on a large scale for network diagnostics is important to providers and users, as well as for public policy. A framework for Large-scale Measurement of Broadband Performance (LMAP) [RFC7594] has been developed to coordinate the execution of broadband measurements and the collection of measurement results across a large network scale.¶
The LMAP framework defines three basic elements: Measurement Agents(MAs), Controllers, and Collectors. Measurement Agents (MAs) initiate the actual measurements, which are called Measurement Tasks. The controller instructs one or more MAs and communicates the set of Measurement Tasks an MA should perform and when. The Collector accepts reports from the MAs with the results from their Measurement Tasks. A YANG data model [RFC7950] has been defined for LMAP platforms [RFC8194].¶
The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] provides a solution to expose network information to applications. While the ALTO server can provide an abstract and unified view to the ALTO client, it remains undefined how the ALTO server can leverage multiple systems to collection and aggregate network information.¶
This document tries to bridge the gap by proposing the ALTO protocol to access large-scale network measurement results in the context of Large-scale Measurement of Broadband Performance (LMAP) [RFC7594]. The measurement result reports could be useful to support the ALTO cost map service or endpoint cost service. Potential ALTO protocol extensions are also discussed to better leverage LMAP measurement results.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
To motivate the proposal of ALTO for querying LMAP results, consider some key use cases defined in [RFC7536]:¶
Broadband network maintenance and monitoring¶
A network operator needs to understand the performance of their networks, the performance of the suppliers (downstream and upstream networks), the performance of Internet access services, and the impact that such performance has on the experience of their customers. Largely, the processes that ISPs operate (which are based on network measurement) include Identifying, isolating, and fixing problems, Design and planning, understanding the quality experienced by customers, Understanding the impact and operation of new devices and technology.¶
Broadband performance benchmarking¶
A regulator may want to evaluate the performance of the Internet access services offered by operators.¶
While each jurisdiction responds to distinct consumer, industry, and regulatory concerns, much commonality exists in the need to produce datasets that can be used to compare multiple Internet access service providers, diverse technical solutions, geographic and regional distributions, and marketed and provisioned levels and combinations of broadband Internet access services.¶
Regulators may want to publish performance measures of different ISPs as background information for end users. They may also want to track the growth of high-speed broadband deployment, or to monitor the traffic management practices of Internet providers.¶
This document addresses how to retrieve aggregated network performance measurement results for a certain network. These network performance measurement results are measured and gathered using the LMAP based measurement system. The LMAP based measurement system is comprised of three components: Measurement Agent (MA),Collector and Controller. The MA is located in both the ingress node and the egress node and instructed by the Controller to monitor a particular traffic flowing toward a given destination and to send the Report to the Collector. The Report contains:¶
The collector then provides results to the repository in the ALTO server, formats it as ALTO information, and exposes it to the ALTO client, see Figure 1.¶
+---------------+
| | +--------+
+----------+ | ALTO Server | | |
|Controller| | +----------+ |<--------> ALTO |
+------+---+ | |Collector | | | Client |
| | | +------^---+ | | |
| | +--------+------+ +--------+
| | |
| +-------------+ |
| | |
| | |
+----V------+ +--V---+----+
| Ingress | | Egress |
| Node | | Node |
| +--+ | | +--+ |
| |MA| | | |MA| |
| +--+ | | +--+ |
+-----------+ +-----------+
It must be possible to query for specific, possibly aggregated, results in a flexible way. Otherwise, entities interested in measurement results either cannot select the kind of result aggregation they desire, or must always fetch large amounts of detailed results and process these huge datasets themselves. The need for a flexible mechanism to query for dedicated, partial results becomes evident when considering use cases where a service provider or a process wants to use certain measurement results in an automated fashion. For instance, consider a video streaming service provider that wants to know for a given end-user request the average download speed of the end user's access provider in the end user's region (e.g. to optimize/parametrize its http adaptive streaming service). Or consider a website which is interested in retrieving average connectivity speeds for users depending on access provider, region, or type of contract (e.g. to be able to adapt web content on a per-request basis according to such statistics).¶
The ALTO cost calendar defined in RFC 8896 allows an ALTO Server to provide a sequence of network costs for a given duration of time. It provides the capability for applications to figure out the best time to schedule data transfers and also to proactively manage application traffic given predictable events, such as an expected spike in traffic due to crowd gathering (concerts, sports, etc.), traffic-intensive holidays, and network maintenance [RFC8896].¶
ALTO cost calendar defines "time-interval-size" and "number-of-intervals" as the calendar attributes to specify the time interval size and the number of intervals provided in the calendar, specifically. The calendar mode now seems more like a periodic recurrence, while lack of a more comprehensive expression of calendar time. For example, an application may want to know the network cost metric between two specific endpoints for every 15-minute interval between 12:00 p.m. and 1:00 p.m., Monday through Wednesday. It is possible for LMAP to return that result by configuring the event that triggered the execution of the measurement schedule under the /lmap/schedules subtree. This requires an extension to ALTO cost calendar to support the exposure to ALTO client.¶
In addition, some ALTO protocol extensions need to be considered. For example,¶
Comment: Should we expose LMAP details to ALTO clients?¶
Comment from Luis: how PIDs defined for the measurement agents could correlate with conventional PIDs, i.e., those representing IP address pools.¶
This work provides approach to get access to large scale broadband network performance data and has benefited from the discussions of large-scale network measurement data retrieval over the years.¶
This document has no requests to IANA.¶
The LMAP report below is in XML [W3C.REC-xml-20081126].
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="1">
<report xmlns="urn:ietf:params:xml:ns:yang:ietf-lmap-report">
<date>2015-10-28T13:27:42+02:00</date>
<agent-id>550e8400-e29b-41d4-a716-446655440000</agent-id>
<result>
<schedule>S1</schedule>
<action>A1</action>
<task>update-ping-targets</task>
<start>2016-03-21T10:48:55+01:00</start>
<end>2016-03-21T10:48:57+01:00</end>
<status>0</status>
</result>
<result>
<schedule>S1</schedule>
<action>A2</action>
<task>ping-all-targets</task>
<start>2016-03-21T10:48:55+01:00</start>
<end>2016-03-21T10:48:57+01:00</end>
<status>0</status>
<table>
<column>target</column>
<column>rtt</column>
<row>
<value>2001:db8::1</value>
<value>42</value>
</row>
<row>
<value>2001:db8::2</value>
<value>24</value>
</row>
</table>
</result>
<result>
<schedule>S2</schedule>
<action>A1</action>
<task>traceroute</task>
<option>
<id>target</id>
<name>target</name>
<value>2001:db8::1</value>
</option>
<option>
<id>csv</id>
<name>--csv</name>
</option>
<start>2016-03-21T10:48:55+01:00</start>
<end>2016-03-21T10:48:57+01:00</end>
<status>1</status>
<table>
<column>hop</column>
<column>ip</column>
<column>rtt</column>
<row>
<value>1</value>
<value>2001:638:709:5::1</value>
<value>10.5</value>
</row>
<row>
<value>2</value>
<value>?</value>
<value></value>
</row>
</table>
</result>
<result>
<schedule>S2</schedule>
<action>A2</action>
<task>traceroute</task>
<option>
<id>target</id>
<name>target</name>
<value>2001:db8::2</value>
</option>
<option>
<id>csv</id>
<name>--csv</name>
</option>
<start>2016-03-21T10:48:55+01:00</start>
<end>2016-03-21T10:48:57+01:00</end>
<status>1</status>
<table>
<column>hop</column>
<column>ip</column>
<column>rtt</column>
<row>
<value>1</value>
<value>2001:638:709:5::1</value>
<value>11.8</value>
</row>
<row>
<value>2</value>
<value>?</value>
<value></value>
</row>
</table>
</result>
</report>
</rpc>¶