One document matched: draft-marocco-alto-next-00.xml

<?xml version="1.0" encoding="US-ASCII"?> <!-- -*- fill-column: 120; -*- -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5693 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5693.xml">
<!ENTITY I-D.ietf-alto-protocol SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-alto-protocol.xml">
<!ENTITY I-D.pbryan-json-patch SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.pbryan-json-patch.xml">
<!ENTITY I-D.jones-json-web-signature SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jones-json-web-signature.xml">
<!ENTITY I-D.medved-alto-svr-apis SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.medved-alto-svr-apis.xml">
<!ENTITY I-D.dulinski-alto-inter-problem-statement SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dulinski-alto-inter-problem-statement.xml">

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="info" docName="draft-marocco-alto-next-00" ipr="trust200902">

  <front>

    <title abbrev="Extending ALTO">Extending the Application-Layer Traffic Optimization (ALTO) Protocol</title>

    <author fullname="Enrico Marocco" initials="E." surname="Marocco">
      <organization>Telecom Italia</organization>
      <address>
        <postal>
          <street>Via Reiss Romoli, 274</street>
          <city>Torino</city>
          <region></region>
          <code>10148</code>

          <country>Italy</country>
        </postal>
        <phone></phone>
        <email>enrico.marocco@telecomitalia.it</email>
      </address>
    </author>

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

    <date month="January" year="2012" />

    <area>Transport</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>alto</keyword>

    <abstract>
      <t>
	The Application-Layer Traffic Optimization (ALTO) protocol is 
        designed to allow entities with knowledge about the network 
        infrastructure to export such information to applications that 
        need to choose one or more endpoints to connect to among large 
        sets of logically equivalent ones. The primary use case for the ALTO
	protocol was peer-to-peer applications for file sharing, video 
        streaming and realtime communications, usually running on end-user 
        devices. However, a number of other applications executing in
	more controlled environments may also benefit from the information 
        that can be exported through the ALTO protocol. The use cases that 
        have received significant attention include Content Delivery Networks 
        (CDNs), distributed applications running in large datacenters, as 
        well as systems made of inter-communicating ALTO servers.
      </t>
      <t>
	To apply ALTO to these new use cases, this document aims to foster a
        discussion to determine if, and how, the ALTO protocol could be 
        extended to provide a simple yet useful view of a computational
	environment that goes beyond the static (or near static)
        network topology and cost map information.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
	The Application-Layer Traffic Optimization (ALTO) protocol is 
        designed to allow entities with knowledge about the network 
        infrastructure to export such information to applications that 
        need to choose one or more endpoints to connect to among large 
        sets of logically equivalent ones. The primary use case for the ALTO
	protocol was peer-to-peer applications for file sharing, video 
        streaming and realtime communications, usually running on end-user 
        devices. However, a number of other applications executing in
	more controlled environments may also benefit from the information 
        that can be exported through the ALTO protocol. The use cases that 
        have received significant attention include Content Delivery Networks 
        (CDNs), distributed applications running in large datacenters, as 
        well as systems made of inter-communicating ALTO servers.
      </t>
      <t>
	Such applications require information about the underlying 
        infrastructure that goes beyond network topology and
        associated costs.  We believe that the ALTO protocol can be 
        easily extended to provide this information.
      </t>
      <t>
	The basic idea is to use the ALTO protocol to present a 
        simplified view of a computational environment, aggregating with 
        some level of abstraction and approximation information that at 
        a fine-grained level may be conveyed by protocols like 
        OSPF, ISIS, BGP, SNMP, ECN, and ConEx.
      </t>
      <t>
	To provide such kind of information the ALTO protocol need to be extended on several axes:

	<list style="symbols">

          <t>
	    a means for providing incremental updates to optimize for frequently changing information;
	  </t>

          <t>
	    a means for providing integrity protection for the information provided by an ALTO server, in order to
	    enable information redistribution;
	  </t>

          <t>
	    a server-initiated notification mechanism, for promptly informing applications of status changes;
	  </t>

          <t>
	    different types of information, not only related to network costs, such as:
	    <list style="symbols">

	      <t>network link load;</t>

	      <t>server load;</t>

	      <t>availability of resources such as storage memory, content and installed applications.</t>
	    </list>
	  </t>
        </list>
      </t>

      <t>
	Detail-level and timescale of the additional information that can be provided are an open topic of
	discussion. If on the one hand applications may not take any advantage of too coarse-grained infromation, on the
	other hand ALTO protocol extensions cannot satisfy all the requirements of the mechanisms that today make full
	use of such low level information and therefore must not be intended in any way as a replacement for them. The
	goal of this document is to frame the discussion of what could be reasonable compromises for exporting
	information of the underlying network and computational infrastructure to applications that need to make best
	use of it.
      </t>

      <section title="Requirements Language">
        <t>
	  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
	  "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC
	  2119</xref>.
	</t>
      </section>
    </section>

    <section anchor="use-cases" title="Use Cases">

      <section title="Content Delivery Networks (CDNs)">
	<t>
	  CDNs consist of systems of caching servers that cooperate in the distribution of frequently requested
	  content. When a client wants to access some content, the request is directed by the CDN routing logic to the
	  most appropriate caching server. The criteria for selecting the most appropriate server can be arbitrary
	  complex and depend of information such as:
	    <list style="symbols">

	      <t>
	        network distance betwen the querying client and the caching server;
	      </t>

	      <t>
		load of the caching server, e.g. in terms of number of concurrent requests or available serving capacity
		measured over a recent timeframe;
	      </t>

	      <t>
		content availability;
	      </t>

	      <t>
		storage capacity availablity, for deciding whether to replicate some content on servers that do not have
		it yet.
	      </t>
	    </list>
	</t>
      </section>

      <section title="Virtualized Applications in Datacenters">
	<t>
	  Applications running on virtual servers in large datacenters require dynamic allocation of resources such as
	  computation power, storage capacity and network bandwidth. Datacenter management logic allocate the resources
	  of physycal servers to such applications based on information such as:
	    <list style="symbols">

	      <t>
		resource availability on the physycal servers;
	      </t>

	      <t>
		application code and configurations availability on the physycal servers;
	      </t>

	      <t>
		network connectivity quality (i.e. delay and expected throughput) between the physycal servers the
		virtual server is already running on, and the new physycal servers the additional resources may be
		allocated from.
	      </t>
	    </list>
	</t>
      </section>

      <section title="ALTO Server-to-server Communications">
	<t>
          ALTO servers can improve the guidance they provide by aggregating
          information distributed by other servers (see  
          <xref target="I-D.medved-alto-svr-apis"/> and 
          <xref target="I-D.dulinski-alto-inter-problem-statement"/>).
	  In such scenarios, for the model to be effective, at any
	  point in time all servers need to have a fresh version of the information distributed by the servers they are
	  communicating with, regardless of the type of information distributed. However, the frequency of changes
	  increases with the number of communicating servers, and the faster the information changes, the less the pull-based
	  approach of the <xref target="I-D.ietf-alto-protocol">base ALTO protocol</xref> is suitable for maintaining an
	  updated representation of the environment status.
	</t>
      </section>
    </section>

    <section title="New Protocol Features">
      <t>
	This section discusses some extensions to the ALTO protocol that can be used to cover the use cases described in
	<xref target="use-cases"/>. Such extensions include:
	<list style="symbols">
	  <t>
	    incremental updates for the network and cost maps defined in the <xref target="I-D.ietf-alto-protocol">base
	    ALTO protocol</xref>, for the CDN, datacenter and server-to-server use cases, to enable efficient
	    transmission of status changes;
	  </t>
	  <t>
	    integrity protection, for the server-to-server use case, to enable servers assert the authenticity of data
	    re-distributed by other servers;
	  </t>
	  <t>
	    a mechanism for server-initiated notifications, for the CDN, datacenters and server-to-server use cases, to
	    enable a fast propagation of the status changes;
	  </t>
	  <t>
	    new types of information for the ALTO protocol, for the CDN and datacenters use cases, to provide a
	    representation of the computational environment that goes beyond the network topology.	    
	  </t>
	</list>
      </t>
      <t>
	Incremental updates and integrity protection are easily defined on the 
        basis of existing (ongoing) work, namely 
        <xref target="I-D.pbryan-json-patch"/> and 
        <xref target="I-D.jones-json-web-signature"/>. The remainder
	of this section discusses the other, perhaps more controversial 
        extensions.
      </t>

      <section title="Server-initiated Notifications">
	<t>
	  The <xref target="I-D.ietf-alto-protocol">base ALTO protocol</xref> defines a JSON-based syntax to be conveyed
	  statelessly over HTTP. Such a lightweight approach has several advantages and is considered most appropriate
	  for the use case of peer-to-peer applications, where the information is likely to be retrieved and consumed by
	  huge numbers of clients. However, in more controlled environment, the same information, with the same or an
	  equivalent syntax, can also be conveyed by different protocols, such as XMPP, SIP, or by any protocol with
	  publish/subscribe capabilities that would allow servers to send updates to subscribed clients.
	</t>

	<t>
	  <list style="empty">
	    <t>
	  <figure>
	      <preamble>
		As an example, if an ALTO service provider wanted to make cost maps available also through XMPP
		(assuming some kind of specification for ALTO-over-XMPP exists), it could simply advertize the proper
		URI in the information resource directory along with the basic HTTP one:
	      </preamble>
 	      <artwork align="left">
		<![CDATA[
   {
     "resources" : [
       {
         "uri" : "http://alto.example.com/serverinfo",
         "media-types" : [ "application/alto-serverinfo+json" ]
       }, {
         "uri" : "http://alto.example.com/networkmap",
         "media-types" : [ "application/alto-networkmap+json" ]
       }, {
         "uri" : "http://alto.example.com/costmap/num/routingcost",
         "media-types" : [ "application/alto-costmap+json" ],
	 "additional-uris" : [ "xmpp:routingcost@alto.example.com" ],
         "capabilities" : {
           "cost-modes" : [ "numerical" ],
           "cost-types" : [ "routingcost" ]
         }
       }, {
         "uri" : "http://alto.example.com/costmap/num/hopcount",
         "media-types" : [ "application/alto-costmap+json" ],
	 "additional-uris" : [ "xmpp:hopcount@alto.example.com" ],
         "capabilities" : {
           "cost-modes" : [ "numerical" ],
           "cost-types" : [ "hopcount" ]
         }
       },
       .
       .
       .
     ]
   }
		]]>
	      </artwork>
	    </figure>
	    </t>
	  </list>
	</t>
      

      </section>

      <section title="ALTO Information Extensions">
	<t>
	  The <xref target="I-D.ietf-alto-protocol">base ALTO protocol</xref> has been designed to be easily extended,
	  in terms of both endpoint properties and path cost types. The reminder of this section discusses the types of
	  information that are required by the use cases described in <xref target="use-cases"/> and that would allow an
	  ALTO servers to expose an abstract representation of a computational environment beyond the simple network
	  topology.
	</t>

	<section title="Bandwidth Availability Between Hosts">
	  <t>
	    Bandwidth availability is a kind of information that changes instantaneously and strictly depends on
	    applications behavior. For such (and other) reasons, conveying it for congestion control other than in-band
	    within the data flows may result useless at best, if not the cause of detrimental feedback loops.
	  </t>
	  <t>
	    However, some notion of link bandwidth availability averaged over a reasonabe timeframe may be effectively
	    used by CDN or datacenter applications to select well-connected pairs or groups of hosts that have to
	    perform bandwidth-demanding tasks.
	  </t>
	  <t>
	    Information about bandwidth availability can be defined for encoding in the ALTO protocol as a new path cost
	    type.
	  </t>
	</section>

	<section title="Resource Availability on Hosts">
	  <t>
	    Information about storage and computational capacity availability averaged over a reasonable timeframe may
	    be effectively used by CDN and datacenter applications as one of the criteria for selecting hosts for
	    serving content or performing tasks.
	  </t>
	  <t>
	    Information about resource availability can be defined for encoding in the ALTO protocol as a new endpoint
	    property.
	  </t>
	</section>

	<section title="Content Availability on Hosts">
	  <t>
	    Information about content availability can be expressed as lists of URIs (e.g. for identifying stored files
	    in CDN caching servers), URNs or other kinds of identifiers (e.g. for identifying installed applications on
	    physycal servers in a datacenter).
	  </t>
	  <t>
    	    Information about content availability can be defined for encoding in the ALTO protocol as a new endpoint
    	    property.
	  </t>
	</section>

      </section>


    </section>

    <section title="Security Considerations">
      <t>
	The information types discussed in this document are likely to be privacy critical in many environment and
	therefore must be protected, restricting or controlling access to the servers that export them.
      </t>
      <t>
	Server initiated notification requires more resources than the stateless retrivial model adopted by the <xref
	target="I-D.ietf-alto-protocol">base ALTO protocol</xref> and is more thus more vulnerable to denial of service
	attacks.
      </t>
      <t>
	Access control mechanisms, including HTTP's, may be valid options for addressing the security issues related to
	both privacy critical information types and resource-consuming server notifications.
      </t>
    </section>

  </middle>

  <back>

    <references title="Normative References">

      &RFC2119;

    </references>

    <references title="Informative References">

      &RFC5693;

      &I-D.ietf-alto-protocol;

      &I-D.pbryan-json-patch;

      &I-D.jones-json-web-signature;

      &I-D.medved-alto-svr-apis;

      &I-D.dulinski-alto-inter-problem-statement;

    </references>

  </back>
</rfc>