ALTO for Querying LMAP Results
draft-seedorf-lmap-alto-01

LMAP                                                          J. Seedorf
Internet-Draft                                                       NEC
Intended status: Informational                                V. Gurbani
Expires: January 12, 2014                      Bell Labs, Alcatel-Lucent
                                                              E. Marocco
                                                          Telecom Italia
                                                           July 11, 2013

                     ALTO for Querying LMAP Results
                       draft-seedorf-lmap-alto-01

Abstract

   In the context of Large-Scale Measurement of Broadband Performance
   (LMAP), measurement 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.

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 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 January 12, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Seedorf, et al.         Expires January 12, 2014                [Page 1]
Internet-Draft                ALTO for LMAP                    July 2013

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Example Use Cases . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Advantages of using ALTO  . . . . . . . . . . . . . . . . . .   4
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Download speeds . . . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  Network map . . . . . . . . . . . . . . . . . . . . .   5
       4.1.2.  Cost map  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgment . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   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

Seedorf, et al.         Expires January 12, 2014                [Page 2]
Internet-Draft                ALTO for LMAP                    July 2013

   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.

2.  Example Use Cases

   To motivate the usefulness of ALTO for querying LMAP results,
   consider some key use cases:

   o  Video Streaming Service Provider: For HTTP adaptive streaming, it
      may be very useful to be able to query for average measurement
      values regarding a particular end user's access network provider.
      For instance, consider a video streaming service provider that
      queries LMAP measurement results to retrieve for a given end-user
      request the average download speed by the end user's access

Seedorf, et al.         Expires January 12, 2014                [Page 3]
Internet-Draft                ALTO for LMAP                    July 2013

      provider in the end user's region.  Such data could help the
      service provider to optimize/parametrize its HTTP adaptive
      streaming service.

   o  Website Front End Optimization: A website might be interested in
      statistics about average connectivity types or download speeds for
      a given end user request in order to dynamically adapt HTML/CSS/
      JavaScript content depending on such information (sometimes
      referred to as "Front End Optimization").  For instance, image
      compression may or may not be employed depending on the average
      connectivity type/speed of a user in a given region or with a
      given access network provider.

   o  Display estimation of service quality or total download time to
      users: A webservice could use statistics about average download
      speeds for a given ISP and/or region to estimate Quality-of-
      Service for provided services (e.g. to indicate to the user what
      Quality-of-Experience to expect when clicking on a given link) or
      to estimate (and display to the user) the total download time for
      given content.

   o  Troubleshooting: In general, any service on the Internet may be
      interested in LMAP data for troubleshooting.  In case a service
      does not work as expected (e.g. low throughput, high packet loss,
      ...), it may be of value for the service provider to retrieve
      (fairly) recent measurement data regarding the host that is
      requesting the service.

   o  TBD: add more use cases

3.  Advantages of using ALTO

   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.

Seedorf, et al.         Expires January 12, 2014                [Page 4]
Internet-Draft                ALTO for LMAP                    July 2013

   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 increasingly 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
   extensions.

   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.

4.  Examples

   [NOTE: syntax most certainly wrong!]

4.1.  Download speeds

   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:

   o  data collected from measurements against specific endpoints (e.g.
      active measurements);

   o  data collected from all measurements (e.g. passive measurements).

4.1.1.  Network map

Seedorf, et al.         Expires January 12, 2014                [Page 5]
Internet-Draft                ALTO for LMAP                    July 2013

   {
     "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" ]
       }
     }
   }

4.1.2.  Cost map

   {
     "meta" : {},
     "data" : {
       "cost-mode" : "numerical",
       "cost-type" : "avg-dl-speed",
       "map-vtag" : "1266506139",
       "time-interval" : "2629740",
       "map" : {
         "ISP1-GEO1": { "MSMNT-CL1" : 13.2,

Seedorf, et al.         Expires January 12, 2014                [Page 6]
Internet-Draft                ALTO for LMAP                    July 2013

                        "TOTAL" : 10.2},
         "ISP2-GEO1": { "MSMNT-CL1" : 11.4,
                        "TOTAL" : 12.3},
         "ISP3-GEO1": { "MSMNT-CL1" : 13.2,
                        "TOTAL" : 10.2},
         .
         .
         .

         }
       }
     }
   }

5.  Conclusion

   This document argues that, compared to existing solutions, there may
   be a need for a more flexible way to provide access to large-scale
   network measurement results.  Further, the document argues that the
   ALTO protocol is a good candidate to enable querying for specific,
   possibly aggregated, measurement results in a flexible way.  Examples
   of how such a flexible query meachnism for large-scale measurement
   results could look like based on ALTO are given.

6.  References

6.1.  Normative References

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693, October
              2009.

6.2.  Informative References

   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
              ietf-alto-protocol-16 (work in progress), May 2013.

   [I-D.schulzrinne-lmap-requirements]
              Schulzrinne, H., Johnston, W., and J. Miller, "Large-Scale
              Measurement of Broadband Performance: Use Cases,
              Architecture and Protocol Requirements", draft-
              schulzrinne-lmap-requirements-00 (work in progress),
              September 2012.

Seedorf, et al.         Expires January 12, 2014                [Page 7]
Internet-Draft                ALTO for LMAP                    July 2013

Appendix A.  Acknowledgment

   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.

Authors' Addresses

   Jan Seedorf
   NEC
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 4342 221
   Fax:   +49 6221 4342 155
   Email: seedorf@neclab.eu

   Vijay K. Gurbani
   Bell Labs, Alcatel-Lucent

   Email: vkg@bell-labs.com

   Enrico Marocco
   Telecom Italia
   Via G. Reiss Romoli, 274
   Turin  10148
   Italy

   Email: enrico.marocco@telecomitalia.it

Seedorf, et al.         Expires January 12, 2014                [Page 8]