[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                               E. Marocco
Internet-Draft                                            Telecom Italia
Intended status: Informational                                V. Gurbani
Expires: July 23, 2012                                Bell Laboratories,
                                                          Alcatel-Lucent
                                                        January 20, 2012


  Extending the Application-Layer Traffic Optimization (ALTO) Protocol
                       draft-marocco-alto-next-00

Abstract

   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.

   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.

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




Marocco & Gurbani         Expires July 23, 2012                 [Page 1]


Internet-Draft               Extending ALTO                 January 2012


   This Internet-Draft will expire on July 23, 2012.

Copyright Notice

   Copyright (c) 2012 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.



































Marocco & Gurbani         Expires July 23, 2012                 [Page 2]


Internet-Draft               Extending ALTO                 January 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
   2.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Content Delivery Networks (CDNs) . . . . . . . . . . . . .  5
     2.2.  Virtualized Applications in Datacenters  . . . . . . . . .  6
     2.3.  ALTO Server-to-server Communications . . . . . . . . . . .  6
   3.  New Protocol Features  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Server-initiated Notifications . . . . . . . . . . . . . .  7
     3.2.  ALTO Information Extensions  . . . . . . . . . . . . . . .  8
       3.2.1.  Bandwidth Availability Between Hosts . . . . . . . . .  9
       3.2.2.  Resource Availability on Hosts . . . . . . . . . . . .  9
       3.2.3.  Content Availability on Hosts  . . . . . . . . . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
































Marocco & Gurbani         Expires July 23, 2012                 [Page 3]


Internet-Draft               Extending ALTO                 January 2012


1.  Introduction

   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.

   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.

   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.

   To provide such kind of information the ALTO protocol need to be
   extended on several axes:

   o  a means for providing incremental updates to optimize for
      frequently changing information;

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

   o  a server-initiated notification mechanism, for promptly informing
      applications of status changes;

   o  different types of information, not only related to network costs,
      such as:

      *  network link load;

      *  server load;





Marocco & Gurbani         Expires July 23, 2012                 [Page 4]


Internet-Draft               Extending ALTO                 January 2012


      *  availability of resources such as storage memory, content and
         installed applications.

   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.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].


2.  Use Cases

2.1.  Content Delivery Networks (CDNs)

   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:

   o  network distance betwen the querying client and the caching
      server;

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

   o  content availability;

   o  storage capacity availablity, for deciding whether to replicate
      some content on servers that do not have it yet.








Marocco & Gurbani         Expires July 23, 2012                 [Page 5]


Internet-Draft               Extending ALTO                 January 2012


2.2.  Virtualized Applications in Datacenters

   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:

   o  resource availability on the physycal servers;

   o  application code and configurations availability on the physycal
      servers;

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

2.3.  ALTO Server-to-server Communications

   ALTO servers can improve the guidance they provide by aggregating
   information distributed by other servers (see
   [I-D.medved-alto-svr-apis] and
   [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 base ALTO protocol
   [I-D.ietf-alto-protocol] is suitable for maintaining an updated
   representation of the environment status.


3.  New Protocol Features

   This section discusses some extensions to the ALTO protocol that can
   be used to cover the use cases described in Section 2.  Such
   extensions include:

   o  incremental updates for the network and cost maps defined in the
      base ALTO protocol [I-D.ietf-alto-protocol], for the CDN,
      datacenter and server-to-server use cases, to enable efficient
      transmission of status changes;

   o  integrity protection, for the server-to-server use case, to enable
      servers assert the authenticity of data re-distributed by other
      servers;



Marocco & Gurbani         Expires July 23, 2012                 [Page 6]


Internet-Draft               Extending ALTO                 January 2012


   o  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;

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

   Incremental updates and integrity protection are easily defined on
   the basis of existing (ongoing) work, namely [I-D.pbryan-json-patch]
   and [I-D.jones-json-web-signature].  The remainder of this section
   discusses the other, perhaps more controversial extensions.

3.1.  Server-initiated Notifications

   The base ALTO protocol [I-D.ietf-alto-protocol] 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.


























Marocco & Gurbani         Expires July 23, 2012                 [Page 7]


Internet-Draft               Extending ALTO                 January 2012


      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:


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


3.2.  ALTO Information Extensions

   The base ALTO protocol [I-D.ietf-alto-protocol] 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 Section 2
   and that would allow an ALTO servers to expose an abstract
   representation of a computational environment beyond the simple
   network topology.



Marocco & Gurbani         Expires July 23, 2012                 [Page 8]


Internet-Draft               Extending ALTO                 January 2012


3.2.1.  Bandwidth Availability Between Hosts

   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.

   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.

   Information about bandwidth availability can be defined for encoding
   in the ALTO protocol as a new path cost type.

3.2.2.  Resource Availability on Hosts

   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.

   Information about resource availability can be defined for encoding
   in the ALTO protocol as a new endpoint property.

3.2.3.  Content Availability on Hosts

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

   Information about content availability can be defined for encoding in
   the ALTO protocol as a new endpoint property.


4.  Security Considerations

   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.

   Server initiated notification requires more resources than the
   stateless retrivial model adopted by the base ALTO protocol
   [I-D.ietf-alto-protocol] and is more thus more vulnerable to denial
   of service attacks.




Marocco & Gurbani         Expires July 23, 2012                 [Page 9]


Internet-Draft               Extending ALTO                 January 2012


   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.


5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

5.2.  Informative References

   [I-D.dulinski-alto-inter-problem-statement]
              Dulinski, Z., Wydrych, P., and R. Stankiewicz, "Inter-ALTO
              Communication Problem Statement",
              draft-dulinski-alto-inter-problem-statement-01 (work in
              progress), July 2011.

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

   [I-D.jones-json-web-signature]
              Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer,
              J., Sakimura, N., and P. Tarjan, "JSON Web Signature
              (JWS)", draft-jones-json-web-signature-04 (work in
              progress), December 2011.

   [I-D.medved-alto-svr-apis]
              Medved, J., Ward, D., Peterson, J., Woundy, R., and D.
              McDysan, "ALTO Network-Server and Server-Server APIs",
              draft-medved-alto-svr-apis-00 (work in progress),
              March 2011.

   [I-D.pbryan-json-patch]
              Bryan, P., "JSON Patch", draft-pbryan-json-patch-04 (work
              in progress), December 2011.

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







Marocco & Gurbani         Expires July 23, 2012                [Page 10]


Internet-Draft               Extending ALTO                 January 2012


Authors' Addresses

   Enrico Marocco
   Telecom Italia
   Via Reiss Romoli, 274
   Torino,   10148
   Italy

   Phone:
   Email: enrico.marocco@telecomitalia.it


   Vijay K. Gurbani
   Bell Laboratories, Alcatel-Lucent

   Email: vkg@bell-labs.com



































Marocco & Gurbani         Expires July 23, 2012                [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/