| LMAP | J. Seedorf |
| Internet-Draft | NEC |
| Intended status: Informational | V. Gurbani |
| Expires: October 13, 2013 | Bell Labs, Alcatel-Lucent |
| E. Marocco | |
| Telecom Italia | |
| April 11, 2013 |
ALTO for LMAP
draft-seedorf-lmap-alto-00
In the context of Large-Scale Measurement of Broadband Performance (LMAP), measurment results are currently made available to the public either at the finest granularity level (e.g. as a list of results of all individual tests), or in a very high level human-readable format (e.g. as PDF reports).
This document argues that there is a need for an intermediate way to provide access to large-scale network measurement results, flexible enough to enable querying of specific and possibly aggregated data. The Application-Layer Traffic Optimization (ALTO) Protocol, defined with the goal to provide applications with network information, seems a good candidate to fulfill such a role.
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 http://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 October 13, 2013.
Copyright (c) 2013 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Recently, there is a discussion on standardizing protocols that would allow measurements of broadband performance on a large scale (LMAP [I-D.schulzrinne-lmap-requirements]). In principle, the vision is that "user networks gather data, either on their own initiative or instructed by a measurement controller, and then upload the measurement results to a designated measurement server."
Apart from protocols that can be used to gather measurement data and to upload such data to dedicated servers, there is also a need for protocols to retrieve - potentially aggregated - measurement results for a certain network (or part of a network), possibly in an automated way. Currently, two extremes are being used to provide access to large-scale measurement results: One the one hand, highly aggregated results for certain networks may be made available in the form of PDFs of figures. Such presentations may be suitable for certain use cases, but certainly do not allow a user (or entity such as a service provider) to select specific criteria and then create corresponding results. On the other hand, complete and detailed results may be made available in the form of comma-seperated-values (csv) files. Such data sets typically include the complete results being measured on a very fine-grained level and usually imply large file sizes (of result data sets). Such detailed result data sets are very useful e.g. for the scientific community because they enable to execute complex data analytics algorithms or queries to analyse results.
Considering the two extremes discussed above, this document argues that there is a need for an intermediate way to provide access to large-scale network 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 what 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 which wants to know for a given end-user request the average download speed by 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).
This document argues that use cases as described above may enhance the value of measurements of broadband performance on a large scale (LMAP), given that it is possible to query for selected results in an automated fashion. Therefore, in order to facilitate such use cases, a protocol is needed that enables to query LMAP measurements results while allowing to specify certain parameters that narrow down the particular data (i.e. measurement results) the issuer of the query is interested in. This document argues that ALTO [RFC5693] [I-D.ietf-alto-protocol] could be a suitable candidate for such a flexible LMAP result query protocol.
To motivate the usefulness of ALTO for querying LMAP results, consider some key use cases:
The ALTO protocol [I-D.ietf-alto-protocol] specifies a very lightweigth JSON-based encoding for network information and can play an important role in querying the measurement results as we argue in Section 2.
ALTO is designed on two abstractions that are useful here. First is the abstraction of the physical network topology into an aggregated but logical topology. In this abstract topological view, referred to as "network map", individual hosts are aggregated into a well defined network location identifier called a PID. Hosts could be aggregated into the PID depending on certain identifying characteristics such as geographical location, serving ISP, network mask, nominal access speed, or any mix of them. The "network map" abstraction is essential for exporting network infromation in a scalable and privacy-preserving way.
The second abstraction that is useful for LMAP is the notion of a "cost map". Each PID identified in the network map can, in a sense, become a vertex in a cost map, and each edge joining adjacent vertices can have an associated cost. The cost can be defined by the measurement server and can indicate routing hops, the financial cost of sending data over the link, available bandwidth on the link with bottled-up links increasing showing a smaller value, or a user- defined cost attribute that allows arbitrary reasoning.
The ALTO protocol defines several basic services based on such abstractions, but additional ones can be easily defined as extesions.
There are other advantages to using ALTO as well. The protocol is defined as a set of REST APIs on top of HTTP. The data carried by the protocol is encoded as JSON. Queries can be performed by clients locally after downloading the entire topological and cost maps or clients can send filtered requests to the ALTO server such that the ALTO server performs the required computation and returns the results. The protocol supports a set of atomic constraints related to equality that can be used to filter results and only obtain a set of interest to the query.
Additionally, protocol extensions that could also be useful for the LMAP usage scenario (e.g. extensions for incremental updates, for asynchrounous change notifications and for encoding of multiple costs within the same cost map) have been proposed and are currently being discussed in the ALTO WG.
[NOTE: syntax most certainly wrong!]
This section shows, as an example, how average download speeds measured in a given time interval can be reported. The aggregation approach in this case is based on ISP and geographical location. Two types of data are reported in this example:
{
"meta" : {},
"data" : {
"map-vtag" : "1266506139",
"map" : {
"ISP1-GEO1" : {
"ipv4" : [ "10.1.0.0/16", 172.20.0.0/16" ]
},
"ISP2-GEO1" : {
"ipv4" : [ "10.2.0.0/17" ]
},
"ISP3-GEO1" : {
"ipv4" : [ "10.3.0.0/16" ]
},
"ISP2-GEO2" : {
"ipv4" : [ "10.2.128.0/17" ]
},
"ISP4-GEO2" : {
"ipv4" : [ "10.4.0.0/16" ]
},
.
.
.
"MSMNT-CL1" : {
"ipv4" : [ "192.168.0.0/30" ]
},
"TOTAL" : {
"ipv4" : [ "0.0.0.0/0" ]
}
}
}
{
"meta" : {},
"data" : {
"cost-mode" : "numerical",
"cost-type" : "avg-dl-speed",
"map-vtag" : "1266506139",
"time-interval" : "2629740",
"map" : {
"ISP1-GEO1": { "MSMNT-CL1" : 13.2,
"TOTAL" : 10.2},
"ISP2-GEO1": { "MSMNT-CL1" : 11.4,
"TOTAL" : 12.3},
"ISP3-GEO1": { "MSMNT-CL1" : 13.2,
"TOTAL" : 10.2},
.
.
.
}
}
}
}
| [RFC5693] | Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. |
| [I-D.schulzrinne-lmap-requirements] | Schulzrinne, H., Johnston, W. and J. Miller, "Large-Scale Measurement of Broadband Performance: Use Cases, Architecture and Protocol Requirements", Internet-Draft draft-schulzrinne-lmap-requirements-00, September 2012. |
| [I-D.ietf-alto-protocol] | Alimi, R., Penno, R. and Y. Yang, "ALTO Protocol", Internet-Draft draft-ietf-alto-protocol-13, September 2012. |
Jan Seedorf is partially supported by the mPlane project (mPlane: an Intelligent Measurement Plane for Future Network and Application Management), a research project supported by the European Commission under its 7th Framework Program (contract no. 318627). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the mPlane project or the European Commission.