< ALTO >                                                       A.Wang
                                                                   K.Li
 Internet Draft                                                   K.Zhou
 Intended status: Standards Track                                  X.Sun
Internet Draft                                           China Telecom
Expires: November 2010                                    May 20, 2010



           Server nofitification mechanism for ALTO optimization
                    draft-sun-alto-notification-01.txt


Abstract

The cooperation between Internet application and network enhances not
only the efficiency of network transportation but also the experiences
of end users. To design the information exchanging protocol and
architecture that facilitate such cooperation is the objective of
Application-Layer Traffic Optimization (ALTO) working group.

Currently, ALTO protocol adopts an efficient query/response message
based on the prevalent http protocol. However, such protocol cannot
support rapid dispatch of ALTO information. Noted that many scenarios
require the updated network information to be dispatched to clients as
soon as possible, such as when part of the network is congested, when a
new policy is to be deployed urgently, or when unexpected network
maintenance is required. To tackle such problem, this draft proposed a
server notification extension to the original query/response mechanism.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.






<A.Wang>              Expires November 20, 2010               [Page 1]

Internet-Draft            < Notification >                    May 2010


Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.

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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 20, 2010.

Copyright Notice

Copyright (c) 2010 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.





<A.Wang>              Expires November 20, 2010               [Page 2]

Internet-Draft            < Notification >                    May 2010


Table of Contents


   1. Introduction ................................................ 3
   2. Server Notification Mechanism ............................... 4
      2.1. Overview of Server Notification Mechanism ............... 4
      2.2. Scope of server notification mechanism .................. 5
      2.3. Registration Methods of ALTO Clients .................... 6
      2.4. Server Notification Mode ................................ 6
      2.5. Implementation Consideration ............................ 7
   3. Server Notification Messaging    ............................. 7
      3.1. The processing ......................................... 7
      3.2. Message format ......................................... 8
   4. Discussion .................................................. 9
      4.1. tracker-less p2p situation  ............................ 9
   5. Security Considerations    ................................. 10
   6. IANA Considerations ........................................ 10
   7. Acknowledgment ............................................. 10
   8. References ................................................. 10
   Author's Addresses ............................................ 11

1. Introduction

   Internet application, especially p2p applications, can benefit from
   knowing the underlying network topology information via the ALTO
   protocol [I-D.ietf-alto-protocol]. The ALTO clients query the ALTO
   server periodically to get the updated ALTO information. Such method
   is simple and effective given that the ALTO information is seldom
   changes.

   However, there are some situations that the ALTO information changes
   occasionally. For example, due to network congestion, traffic load


<A.Wang>              Expires November 20, 2010               [Page 3]

Internet-Draft            < Notification >                    May 2010


   fluctuation, or management requirement, an ISP may change its
   traffic optimization policy. This generally results in an update of
   ALTO information.

   With simple query/response method, a possible way to tackle such
   situations is to shorten the query interval. But this may flood the
   ALTO sever with a large amount of query messages. A shorter query
   interval also increases the traffic generated by ALTO. That is, a
   shorter query interval may exacerbate the network congestion in some
   sense. Moreover, as most of the ALTO information seldom changes, the
   information carried is not proportional to the amount of traffic
   generated.

   Another method is to modify the ALTO protocol. If the ALTO server
   can notify the ALTO clients proactively the change of ALTO
   information, the traffic formed by the ALTO clients will be
   optimized timely. The ALTO server and the ALTO clients will be
   relieved from the unnecessary query/response messages.

   This draft describes the ALTO server notification mechanism which
   can be incorporated into the current ALTO protocol, its main
   applicable scope and the detail process. Such mechanism can
   certainly increase the efficiency of ALTO protocol.



2. Server Notification Mechanism

2.1. Overview of Server Notification Mechanism

   Within currently ALTO protocol, the ALTO clients can only get the
   ALTO information via the query/response mechanism. The query period


<A.Wang>              Expires November 20, 2010               [Page 4]

Internet-Draft            < Notification >                    May 2010


   is one key parameter that needs to be considered. If this value is
   set very short, ALTO messages may burden the underlying network; if
   it is set very long, the ALTO clients may not able to get the
   updated ALTO information in time.

   Given that the ISP may change their policy occasionally, enable the
   ALTO server to notify the clients of updated ALTO information as
   soon as possible is reasonable. When an ALTO server determines that
   a major change has occurred and the clients should know the change,
   the server broadcast a notification message to its clients. On
   receiving the notification message, the ALTO clients can send a
   query message to the server and fetch the ALTO information that they
   interested in.



2.2. Scope of server notification mechanism

   The ALTO protocol is aimed to p2p and non-p2p internet applications
   that can utilize the network information to optimize their
   performances.

   From the statistics of China Telecom's IP traffic reports, the
   tracked-based p2p applications and other non-p2p, distributed web
   services (such as CDN-based web services) produce exceed 80% of the
   internet traffic. The developers of these applications are also more
   easily cooperative with ISP to increase the traffic transport
   efficiency.

   This draft will focus mainly on these applications that creating
   large amounts of flow in internet.



<A.Wang>              Expires November 20, 2010               [Page 5]

Internet-Draft            < Notification >                    May 2010



2.3. Registration Methods of ALTO Clients

   In order to notify the ALTO clients actively, the ALTO server needs
   to know the IP addresses and the listening ports of an ALTO client
   in advance. Such information can be gotten via the contracts with
   ISP or by other out-of-band methods.

   The ALTO Server will keep one table (referred as "candidate table"
   in following) that records the IP addresses/ports information of
   these ALTO clients (referred as "registered ALTO clients" in
   following). It will be kept permanently in ALTO sever unless changed
   or removed by the ISP.



2.4. Server Notification Mode

   The server notification mechanism can be designed in a general mode
   or in a specific mode.

   In the general mode, if there is any change of network condition,
   which leads to the information change of network map, cost map or
   other information provided by ALTO server, the server sends notify
   message to all the registered ALTO clients. These registered ALTO
   clients then send the query messages to ALTO server, together with
   their own map filter, to get the interested ALTO information
   respectively.

   With the specific mode, a specific notification message is send to
   all registered ALTO clients. This specific message points out which
   part of the ALTO information has been changed. The interested ALTO
   clients, not all registered ALTO clients, then send query message to



<A.Wang>              Expires November 20, 2010               [Page 6]

Internet-Draft            < Notification >                    May 2010


   ALTO server, together with the map filter, to get the changed ALTO
   information.





2.5. Implementation Consideration

   The notification service can lessen the burden of the ALTO server.
   That is, it is acceptable to incorporate such service in the ALTO
   server, as an independent module. However, notification service can
   also be provided by a dedicated notification server, if the
   notification service becomes a burden to the original ALTO server.



3. Server Notification Messaging

   This section specifies notification processing and message format.



3.1. The processing


   Once an ALTO server determines that a notification to its clients is
   required the ALTO server will build the notification message and
   send it to the ALTO clients. Upon receiving the notification, a
   client checks whether the notification is a general notification or
   a specific notification. The local ALTO information updating logic
   of the client determines the next processing step. If the client
   receives a general notification, and the client is willing to update



<A.Wang>              Expires November 20, 2010               [Page 7]

Internet-Draft            < Notification >                    May 2010


   its ALTO information, it sends the ALTO query message immediately to
   get the renewed network/cost map. Otherwise, it may just neglect the
   notification and send no more queries. Note that the above ALTO
   query message is the same as the current ALTO query message.

    +---------------+     +---------------+    +----------------+
    |P2P Tracker/   |     |               |    |   Network      |
    |ALTO client    |     |ALTO server    |    |   condition    |
    +---------------+     +-------+-------+    +----------------+
            |                     |                     |
            |                     |  Network changing   |
            |                     <---------------------+
            |                     | \\                  |
            |                     |   | Map refresh     |
            | Notification message| //                  |
            <---------------------|-                    |
            |                     |                     |
            |                     |                     |
            |   Query message     |                     |
            +--------------------->                     |
            |                     |                     |
            |                     |                     |
            |   Response message  |                     |
            <---------------------+                     |


3.2. Message format


      The notification message format is as below.
      For general notification:



<A.Wang>              Expires November 20, 2010               [Page 8]

Internet-Draft            < Notification >                    May 2010


             Method        : 'POST'
             URI Path      : '/notification'

      Or
      For specific notification
             Method        : 'POST'
             URI Path      : '/notification/costmap'
                           : '/notification/networkmap'
                           :??



4. Discussion

4.1. tracker-less p2p situation

   The tracker-based and tracker-less p2p application now use different
   information distribution algorithm, and then have different impact
   on ALTO server for current query/response mechanism and the proposed
   notification mechanism. Further research should be devoted on how to
   distribute the ALTO information effectively among track-less p2p
   peers.  If such efficient algorithm can be found, it can then be
   used together with the notification mechanism to improve timely the
   transport efficiency of tracker-less p2p traffic as well.

   One alternative solution to tracker-less situation is that only some
   of p2p peers, which have similar capability (for example, have
   public IP address and are very stable etc.) as p2p tracker, will be
   contacted by the ALTO server directly to get the updated ALTO
   information timely. The other part of p2p peers will get the ALTO
   information via traditionally query/response manner.


<A.Wang>              Expires November 20, 2010               [Page 9]

Internet-Draft            < Notification >                    May 2010




5. Security Considerations

   High-level security considerations can be found in the [draft-ietf-
   alto-problem-statement].

6. IANA Considerations

   This document requests the registration of a new media type:
   "application/alto"

7. Acknowledgment

   Here we are very appropriate the feedbacks and advices from Richard
   Alimi, Reinaldo Penno and Thomson Martin. It is just under their
   reviews and comments that make this draft more comprehensive and
   acceptable.



8. References

   [RFC 5693]
             Seedorf, J. and E. Burger, "Application-Layer Traffic
                 Optimization (ALTO) Problem Statement", RFC 5693,
                 October 2009.

   [I-D.ietf-alto-reqs]
                 S Kiesel, L.Popkin, S.Previdi, R.Woundy, and Y R.
                 Yang, "Application-Layer Traffic Optimization (ALTO)
                 Requirements", draft-ietf-alto-reqs-04 (work in
                 progress),March 2010.



<A.Wang>              Expires November 20, 2010              [Page 10]

Internet-Draft            < Notification >                    May 2010



   [I-D.ietf-alto-protocol]
                 R.Alimi, R.Penno and Y. Yang, "ALTO Protocol",
                 draft-ietf-alto-protocol-03 (work in progress),
                 March 2010.


Author's Addresses

       Aijun Wang
      China Telecom Beijing Research Institute
      Room 708 No.118, Xizhimenneidajie, xicheng District
      Beijing 100035
      China

      Email: wangaj@ctbri.com.cn


      Kai Li
      China Telecom Beijing Research Institute
      Room 708 No.118, Xizhimenneidajie, xicheng District
      Beijing 100035
      China

      Email: leekai@ctbri.com.cn

      Kaiyu Zhou
      China Telecom Beijing Research Institute
      Room 708 No.118, Xizhimenneidajie, xicheng District
      Beijing 100035
      China



<A.Wang>              Expires November 20, 2010              [Page 11]

Internet-Draft            < Notification >                    May 2010


      Email: zhouky@ctbri.com.cn

       Xianghui Sun
      China Telecom Beijing Research Institute
      Room 708 No.118, Xizhimenneidajie, xicheng District
      Beijing 100035
      China

      Email: sunxh@ctbri.com.cn


































<A.Wang>              Expires November 20, 2010              [Page 12]