One document matched: draft-seedorf-lmap-alto-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>

<rfc category="info" docName="draft-seedorf-lmap-alto-00"
     ipr="trust200902">
  <front>
    <title abbrev="ALTO for LMAP">ALTO for LMAP</title>
    
    <author fullname="Jan Seedorf" initials="J." surname="Seedorf">
      <organization abbrev="NEC">NEC</organization>

      <address>
        <postal>
          <street>Kurfuerstenanlage 36</street>
	  
          <code>69115</code>
	  
          <city>Heidelberg</city>

          <country>Germany</country>
        </postal>

        <phone>+49 6221 4342 221</phone>

        <facsimile>+49 6221 4342 155</facsimile>

        <email>seedorf@neclab.eu</email>

      </address>
    </author>
    
    <author initials='V.' surname='Gurbani'
	    fullname='Vijay K. Gurbani'>
      <organization>Bell Labs, Alcatel-Lucent</organization>
      <address>
	<email>vkg@bell-labs.com</email>
      </address>
    </author>

    <author initials='E.' surname='Marocco' fullname='Enrico Marocco'>
      <organization>Telecom Italia</organization>
      <address>
        <postal>
          <street>Via G. Reiss Romoli, 274</street>
          <city>Turin</city>
          <code>10148</code>
          <country>Italy</country>
        </postal>
        <email>enrico.marocco@telecomitalia.it</email>
      </address>
    </author>


    <date year="2013" />

    <area>TSV</area>

    <workgroup>LMAP</workgroup>

    <keyword>LMAP</keyword>

    <keyword>CDN Interconnect</keyword>

    <keyword>ALTO</keyword>

    <abstract>
      <t>
	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).
      </t>
      <t>
	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.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

      <t>
	Recently, there is a discussion on standardizing protocols
	that would allow measurements of broadband performance on a
	large scale (<xref
	target="I-D.schulzrinne-lmap-requirements">LMAP</xref>). 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."
      </t>
      <t>
	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.
      </t>
      <t>
        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).
      </t>
      <t>
        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 <xref
        target="RFC5693"/> <xref target="I-D.ietf-alto-protocol"/>
        could be a suitable candidate for such a flexible LMAP result
        query protocol.
      </t>
    </section>
    
    <section anchor="Exampleusecases" title="Example Use Cases">

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

        <list style="symbols">
	  <t>
	    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 provider in the end user's region. Such data could
	    help the service provider to optimize/parametrize its HTTP
	    adaptive streaming service.
	  </t>
	  <t>
	    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 be
	    employed depending on the average connectivity type of a
	    user in a given region or with a given access network
	    provider.
	  </t>
	  <t>
	    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.
	  </t>
	  <t>TBD: add more use cases</t>
	</list>
      </t>
    </section>
    
    <section anchor="AdvantagesALTO" title="Advantages of using ALTO">
      <t>
	The <xref target="I-D.ietf-alto-protocol">ALTO protocol</xref>
	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 <xref
	target="Exampleusecases"/>.
      </t>
      <t>
	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.
      </t>
      <t>
	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.
      </t>
      <t>
	The ALTO protocol defines several basic services based on such
	abstractions, but additional ones can be easily defined as
	extesions.
      </t>
      <t>
	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.
      </t>
      <t>
	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.
      </t>
    </section>

    <section title="Examples">
      <t>
	[NOTE: syntax most certainly wrong!]
      </t>

      <section title="Download speeds">
	<t>
	  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:
	  <list style="symbols">
	    <t>
	      data collected from measurements against specific
	      endpoints (e.g. active measurements);
	    </t>
	    <t>
	      data collected from all measurements (e.g. passive
	      measurements).
	    </t>
	  </list>
	</t>
	<section title="Network map">
	  <figure>
	    <artwork>
<![CDATA[
{
  "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" ]
    }
  }
}
]]>
	    </artwork>
	  </figure>
	</section>
	<section title="Cost map">
	  <figure>
	    <artwork>
<![CDATA[
{
  "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},
      .
      .
      .

      }
    }
  }
}

]]>
	    </artwork>
	  </figure>
	</section>
      </section>      

    </section>
  
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.5693" ?>
    </references>

    <references title="Informative References">
	<?rfc include="reference.I-D.schulzrinne-lmap-requirements"?>
	<?rfc include="reference.I-D.ietf-alto-protocol"?>
	
	


    </references>

    <section title="Acknowledgment">
      <t>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.</t>

     </section>

  </back>
</rfc>