Internet DRAFT - draft-madhavan-alto-caching

draft-madhavan-alto-caching






Internet Engineering Task Force                              S. Madhavan
Internet-Draft                                              R. Nandiraju
Intended status: Informational                       Huawei Technologies
Expires: August 1, 2013                                 February 1, 2013


                              ALTO Caching
                     draft-madhavan-alto-caching-01

Abstract

   The specification of the ALTO protocol uses map based approaches
   assuming that the information provided is static for a longer period
   of time.  The purpose of this memo is to provide a mechanism where
   ALTO clients cache the map information and the servers provide the
   expiration time for invalidation.

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 February 2, 2013.

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.



Madhavan & Nandiraju    Expires February 2, 2013                [Page 1]

Internet-Draft                ALTO Caching                   August 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol Structure . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Overall Operation  . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  ALTO Types . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     6.1.  EndpointAddrGroup  . . . . . . . . . . . . . . . . . . . .  5
     6.2.  NetworkMapData . . . . . . . . . . . . . . . . . . . . . .  5
   7.  ALTO caching and Consistency . . . . . . . . . . . . . . . . .  5
     7.1.  Server behavior  . . . . . . . . . . . . . . . . . . . . .  5
     7.2.  Client behavior  . . . . . . . . . . . . . . . . . . . . .  6
     7.3.  Cache Consistency Approaches . . . . . . . . . . . . . . .  6
     7.4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  7
       7.4.1.  Network Map with Expiry Example  . . . . . . . . . . .  8
       7.4.2.  Filtered Network Map with Expiry Example . . . . . . .  9
   8.  Transport Considerations . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     11.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10



























Madhavan & Nandiraju    Expires February 2, 2013                [Page 2]

Internet-Draft                ALTO Caching                   August 2012


1.  Introduction

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications, which have to select one or several
   hosts from a set of candidates, that are able to provide a desired
   resource [RFC5693].  The requirements for ALTO are itemized in
   I-D.ietf-alto-reqs.  ALTO is realized by a client-server
   protocol.ALTO clients send queries to ALTO servers, in order to
   solicit guidance.

   This memo defines a mechanism for ALTO clients to cache the map
   information and for the servers to provide the expiration time for
   invalidation at subset level or map level.


2.  Problem Statement

   The ALTO protocol uses HTTP for discovering available Information
   resources at an ALTO server and retrieving information resources.
   The protocol defines Map-based and Non-map based approaches for
   retrieving information resources.Map-based approaches are chosen as
   they lower the signaling load on the server, as the maps have only to
   be retrieved if they are changed.

   HTTP protocol already defines mechanisms for caching the content.
   There are many limitations in using those mechanisms.  HTTP based
   caches store the responses only for HTTP GET requests.  ALTO queries
   can be GET or POST(in case of filtered map) requests.  In the case of
   POST requests, HTTP caching mechanism cannot be used because
   responses for POST are generally not cached.

   The validity of the information in the map need not be same for all
   the elements in the map and there is currently no mechanism(in HTTP
   also) to convey this information.  This mechanism has to be
   incorporated into the protocol itself.


3.  Protocol Structure

   The ALTO Protocol uses a simple extensible framework to convey
   network information.  In the general framework, the ALTO protocol
   will convey properties on both Network Locations and the paths
   between Network Locations.[I-D.ietf-alto-protocol].

   The Map filtering and endpoint property services can be extended to
   include the map level and subset level expiration time.





Madhavan & Nandiraju    Expires February 2, 2013                [Page 3]

Internet-Draft                ALTO Caching                   August 2012


      .--------------------------------------------------------.
      |                                                        |
      |.--------..--------------------------------------------.|
      ||        || ALTO Info Services                         ||
      ||        || .-----------. .----------. .----------.    ||
      ||        || |    Map    | | Endpoint | | Endpoint |    ||
      ||        || | Filtering | | Property | |   Cost   |    ||
      ||        || |           | |          | |          |    ||
      ||        || |           | |          | |          |    ||
      ||        || |  Service  | | Service  | | Service  |    ||
      || Server || `-----------' `----------' `----------'    ||
      ||  Info. || .-------------------------------------.    ||
      || Service|| |  Map Service                        |    ||
      ||        || |  .-------------.  .--------------.  |    ||
      ||        || |  | Network Map |  |  Cost Map    |  |    ||
      ||        || |  `-------------'  `--------------'  |    ||
      ||        || `-------------------------------------'    ||
      |`--------'`--------------------------------------------'|
      |                                                        |
      `--------------------------------------------------------'

                     Figure 1: ALTO Protocol Structure


4.  Overall Operation

   The overall operation is based on the ALTO client caching the map
   information.  The ALTO server sends the map information providing
   details of full or subset level expiration.

   ALTO server can choose to use HTTP based caching mechanisms or ALTO
   caching mechanism (defined in this document) based on the request.

   A typical message flow would be:

                 ALTO Client       ALTO Server
                     |-----ALTO Query--->|     ALTO Query for complete map information
                     |<---ALTO Response--|     ALTO Response with caching related information
                     |                   |
Subset level         |------ALTO Query-->|     ALTO Query for expired maps
validity expires     |<-------200--------|     ALTO response
                     |                      |



                          Figure 2: Message flow





Madhavan & Nandiraju    Expires February 2, 2013                [Page 4]

Internet-Draft                ALTO Caching                   August 2012


5.  Definitions

   ALTO cache: Any logical entity which caches the ALTO responses for
   the purpose of reducing repeated requests by the alto client to the
   alto server.  The ALTO cache MAY be co-located with the ALTO client
   or it can be a separate node


6.  ALTO Types

   This section details the format for particular data values used for
   ALTO caching framework.  Base types defined by I-D.ietf-alto-protocol
   are used by this memo with some extensions listed below.

6.1.  EndpointAddrGroup

   EndpointAddrGroup JSON object is extended as below

   object {
        JSONString expires;
        EndpointPrefix [AddressType]<0..*>;
        ...
      } EndpointAddrGroup;

6.2.  NetworkMapData

   NetworkMapData JSON object is extended as below

    object {
        JSONString expires;
        EndpointAddrGroup [pidname]<0..*>;
        ...
      } NetworkMapData;


7.  ALTO caching and Consistency

   ALTO servers specify the expiration time of the complete map or the
   subset level maps in the response.  Expiration time format is an
   absolute date and time with GMT as reference.  ISPs MAY use any
   mechanism to determine the expiration time.  This is out of the scope
   of this specification.

7.1.  Server behavior

   ALTO server MAY use HTTP based or ALTO caching mechanism to convey
   the expiration time.  When the request is HTTP GET,then the ALTO
   server MAY use HTTP based caching mechanism.  In the case of request



Madhavan & Nandiraju    Expires February 2, 2013                [Page 5]

Internet-Draft                ALTO Caching                   August 2012


   being POST, ALTO server SHOULD use ALTO caching mechanism.  To ensure
   consistent behaviour and reduce implementation complexity it is
   recommended that the mechanism defined by this memo is used for all
   caching scenarios.

7.2.  Client behavior

   ALTO cache MUST be able to identify expiration of map level or subset
   level information.  On expiry, cache SHOULD trigger a new request to
   the server to refresh the expiration.

7.3.  Cache Consistency Approaches

   ALTO caches are useful when cache consistency is maintained,that is,
   cached copies should be updated when the originals change.There are
   two different types of consistency approaches - weak consistency and
   strong consistency.  Weak consistency is an approach in which stale
   documents may be returned to user , while the latter approach ensures
   that stale documents are never returned to user.

   ALTO caches SHOULD have strong invalidation mechanisms.  In the case
   of P2P, the stale data can result in the unoptimized peer selection
   and resulting in selecting the longest PATH which will defeat the
   purpose of ALTO.  In the case of cdni(see [I-D.seedorf-i2aex-alto-
   cdni-perpective] for details)) there can be service failures as
   requests are redirected to wrong/invalid dCDN.

   The below table shows comparison of different validation approaches.
   Assume that interleave of requests and file modifications happens in
   the order RRRMMMRRMRRRMMRM.Let R be the number of times a node views
   a resource and RI be the number of intervals during which client
   repeatedly asks for resource while resource is changed.  It is
   evident that notification based mechanisms takes few control messages
   and ensures that there is no stale data returned.

   The mechanism of notification is proposed in
   [draft-madhavan-alto-subscription]














Madhavan & Nandiraju    Expires February 2, 2013                [Page 6]

Internet-Draft                ALTO Caching                   August 2012


   +-------------------+-----------+--------------+--------------------+
   |      Messages     |  Polling  | Notification | TTL based approach |
   |                   | everytime |   approach   |                    |
   |                   |  approach |              |                    |
   +-------------------+-----------+--------------+--------------------+
   |    GET requests   |     1     |       1      |          1         |
   | If-Modified-Since |    R-1    |       0      |    TTLmissed - 1   |
   |    304 response   |    R-RI   |       0      |     TTLmissed -    |
   |                   |           |              | TTLmissedreschange |
   |  Notification Msg |     0     | 1 Sub + RI * |          0         |
   |                   |           |      Not     |                    |
   |   File Transfers  |     RI    |      RI      |        RI -        |
   |                   |           |              |  Stalehitintervals |
   |   Stale document  |     No    |      No      |         Yes        |
   +-------------------+-----------+--------------+--------------------+

                Message contents for consistency approaches

                    Table 1: Cache consistency tradeoff

7.4.  Examples






























Madhavan & Nandiraju    Expires February 2, 2013                [Page 7]

Internet-Draft                ALTO Caching                   August 2012


7.4.1.  Network Map with Expiry Example

   GET /networkmap HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-networkmap+json,application/alto-error+json

   HTTP/1.1 200 OK
   Content-Length: [TODO]
   Content-Type: application/alto-networkmap+json
   Cache-Control: no-cache

   {
     "meta" : {},
     "data" : {
       "map-vtag" : "1266506139",
       "map" : {
         "expires": "Wed, 14 Sep 2011 16:00:00 GMT",
         "PID1" : {
           "ipv4" : [
             "192.0.2.0/24",
             "198.51.100.0/25"
           ]
         },
         "PID2" : {
           "ipv4" : [
             "198.51.100.128/25"
           ]
         },
         "PID3" : {
           "ipv4" : [
             "0.0.0.0/0"
           ],
           "ipv6" : [
             "::/0"
           ]
         }
       }
     }
   }












Madhavan & Nandiraju    Expires February 2, 2013                [Page 8]

Internet-Draft                ALTO Caching                   August 2012


7.4.2.  Filtered Network Map with Expiry Example

   POST /networkmap/filtered HTTP/1.1
   Host: custom.alto.example.com
   Content-Length: [TODO]
   Content-Type: application/alto-networkmapfilter+json
   Accept: application/alto-networkmap+json,application/alto-error+json

   {
     "pids": [ "PID1", "PID2" ]
   }


   HTTP/1.1 200 OK
   Content-Length: [TODO]
   Content-Type: application/alto-networkmap+json

   {
     "meta" : {},
     "data" : {
       "map-vtag" : "1266506139",
       "map" : {
         "PID1" : {
           "expires": "Wed, 14 Sep 2011 16:00:00 GMT",
           "ipv4" : [
             "192.0.2.0/24",
             "198.51.100.0/24"
           ]
         },
         "PID2" : {
           "expires": "Wed, 14 Dec 2011 16:00:00 GMT",
           "ipv4": [
             "198.51.100.128/24"
           ]
         }
       }
     }
   }


8.  Transport Considerations


9.  Acknowledgements







Madhavan & Nandiraju    Expires February 2, 2013                [Page 9]

Internet-Draft                ALTO Caching                   August 2012


10.  Security Considerations

   TBD


11.  References

11.1.  Normative References

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

11.2.  Informative References

   [I-D.ietf-alto-deployments]
              Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO
              Deployment Considerations", draft-ietf-alto-deployments-04
              (work in progress), March 2012.

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

   [I-D.ietf-alto-reqs]
              Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
              Y. Yang, "Application-Layer Traffic Optimization (ALTO)
              Requirements", draft-ietf-alto-reqs-16 (work in progress),
              June 2012.

   [I-D.seedorf-i2aex-alto-cdni-perpective]
              Seedorf, J., "Infrastructure-to-application information
              exposure from an ALTO-CDNI Perspective",
              draft-seedorf-i2aex-alto-cdni-perpective-00 (work in
              progress), March 2012.

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












Madhavan & Nandiraju    Expires February 2, 2013               [Page 10]

Internet-Draft                ALTO Caching                   August 2012


Authors' Addresses

   Sreekanth Madhavan
   Huawei Technologies
   Bangalore,
   India

   Phone:
   Email: sreekanth.madhavan@huawei.com


   Nandiraju Ravishankar
   Huawei Technologies
   Bangalore,
   India

   Phone:
   Email: ravi.nandiraju@huawei.com

































Madhavan & Nandiraju    Expires February 2, 2013               [Page 11]