Internet-Draft ALTO for LMAP May 2023
Xie, et al. Expires 6 November 2023 [Page]
Workgroup:
Application-Layer Traffic Optimization
Internet-Draft:
draft-xie-alto-lmap-02
Published:
Intended Status:
Informational
Expires:
Authors:
C. Xie
China Telecom
W. Wang
China Telecom
Q. Ma
Huawei

ALTO for Querying LMAP Results

Abstract

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.

Status of This Memo

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.

Table of Contents

1. Introduction

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.

2. Requirements Language

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.

3. Example Use Cases

To motivate the proposal of ALTO for querying LMAP results, consider some key use cases defined in [RFC7536]:

4. Solution Overview

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|   |
|    +--+   |       |    +--+   |
+-----------+       +-----------+
Figure 1

5. Advantages of Using LMAP Measurement Results

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

6. Proposed ALTO protocol extensions

6.1. ALTO cost calendar

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.

6.2. Other Potential ALTO Protocol Extensions

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.

7. Security Considerations

TBD

8. Acknowledgements

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.

9. IANA Considerations

This document has no requests to IANA.

10. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7285]
Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, , <https://www.rfc-editor.org/info/rfc7285>.
[RFC7536]
Linsner, M., Eardley, P., Burbridge, T., and F. Sorensen, "Large-Scale Broadband Measurement Use Cases", RFC 7536, DOI 10.17487/RFC7536, , <https://www.rfc-editor.org/info/rfc7536>.
[RFC7594]
Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, , <https://www.rfc-editor.org/info/rfc7594>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8194]
Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, , <https://www.rfc-editor.org/info/rfc8194>.
[RFC8896]
Randriamasy, S., Yang, R., Wu, Q., Deng, L., and N. Schwan, "Application-Layer Traffic Optimization (ALTO) Cost Calendar", RFC 8896, DOI 10.17487/RFC8896, , <https://www.rfc-editor.org/info/rfc8896>.

Appendix A. Example LMAP Report

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>

Authors' Addresses

Chongfeng Xie
China Telecom
Beijing
China
Wei Wang
China Telecom
32 Xuanwumen West St, Xicheng District
Beijing
Qiufang Ma
Huawei
101 Software Avenue, Yuhua District
Nanjing
Jiangsu, 210012
China