ALTO X. Sun K. Li K. Zhou Internet Draft China Telecom Expires: August 2010 February 26, 2010 Server Notification mechanism for ALTO optimization draft-alto-notification-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 August 26, 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 BSD License. Sun, et al. Expires August 26, 2010 [Page 1] Internet-Draft Server Notification mechanism February 2010 Abstract Application-Layer Traffic Optimization (ALTO) guides an application, especially a Peer to Peer (P2P) application, to select hosts from its candidate set. ALTO is a promising technique for future network, as it is able to jointly optimize network resource utilization and application performance. The ALTO protocol is Client-Server based. Applications work as ALTO clients to fetch PID information from the ALTO server, but the ALTO server can't send the notification to ALTO clients, even if there is a major change to the networks. This draft discusses the requirements for server initialized notification, and proposes one mechanism to enable the ALTO server notification. Table of Contents 1. Introduction ................................................ 2 2. Problem statement ........................................... 3 3. Requirement ................................................. 3 4. Server initiating notification mechanism .................... 3 4.1. The processing ......................................... 4 4.2. Message format ......................................... 5 5. Security Considerations ..................................... 5 6. IANA Considerations ......................................... 5 7. References .................................................. 5 Author's Addresses ............................................. 6 1. Introduction Application Layer Traffic Optimization (ALTO) provides a solution benefits both Internet Service Provider (ISP) and P2P operators/applications. In this solution, P2P applications utilize network information provided by ALTO service to optimize its traffic. However, the current ALTO mechanism depends on ALTO clients fetching network information from the servers, and neglects the requirements to proactively dispatching such information. Unfortunately, there are some scenarios that rapid dispatching of network information is valuable. In this draft, one mechanism is proposed to dispatch the newest network information from ALTO server to ALTO clients quickly. It will let P2P applications know the new network information. The performance of peer selection and ISP traffic management will be improved. Sun, et al. Expires August 26, 2010 [Page 2] Internet-Draft Server Notification mechanism February 2010 Because traffic generated by tracker indexed P2P applications predominates current P2P networks. This draft considers only the server notification implementation based on tracker indexed P2P applications. 2. Problem statement ALTO enhances the traffic optimization capability of ISPs. However, networks and the optimization policy of ISPs are changing frequently. Current ALTO protocol uses B/S architecture. ALTO server is the passive side, and there is only one direction of ALTO message process. ALTO clients send query message periodically to ALTO server for the network and optimization information. This kind of passive mode cannot response quickly to network or ISP's network provision policy change. When a network change occurs, although the ISP updates the ALTO server simultaneously, P2P traffic keeps following the guidance of the previous ALTO direction, as ALTO clients have no knowledge of the change. This will cause a period of pressure to ISP network and raises maintenance problems. 3. Requirement Whenever the change of network condition leads to the change of network map and cost map in ALTO server, the ALTO server SHOULD notify the change to ALTO clients as quickly as possible, and need not wait for the ALTO query message of next period as illustrated in current ALTO protocol. 4. Server initiating notification mechanism In this mechanism, ALTO server will maintain one table to record the address information about each ALTO client. ALTO server will initiate the notification message connection using the address information. The address information will be used to identify the ALTO client, which can be the IP address/port or the URL of tracker which has the ALTO client. In order to improve the ALTO server's efficiency, only P2P tracker and application server will be notified by ALTO server. Sun, et al. Expires August 26, 2010 [Page 3] Internet-Draft Server Notification mechanism February 2010 One new ALTO message is added in this mechanism, notification message. The source of the message is the ALTO server, and the destination is the ALTO client which recorded in the table. HTTP protocol is used to build notification message. One lightweight HTTP server module is needed in ALTO client to receive notification message, as well as HTTP client is needed in the ALTO server. 4.1. The processing When network condition changes, the ALTO server will refresh its network map and cost map according to the related policy. Once the update is finished, ALTO server will build the notification message and send to the ALTO clients. When ALTO client receives the notification message, it will send the ALTO query message immediately to get the renewed network/cost map. This ALTO query message is the same with the current ALTO protocol. When ALTO client receives the notification message, it need not send any response message. +---------------+ +---------------+ +----------------+ |P2P Tracker/ | | | | Network | |ALTO client | |ALTO server | | condition | +---------------+ +-------+-------+ +----------------+ | | | | | Network changing | | <---------------------+ | | \\ | | | | Map refresh | | Notification message| // | <---------------------|- | | | | | | | | Query message | | +---------------------> | | | | | | | | Response message | | <---------------------+ | | | | Sun, et al. Expires August 26, 2010 [Page 4] Internet-Draft Server Notification mechanism February 2010 4.2. Message format The notification message format is as below. Method : 'POST' URI Path : '/notification' 5. Security Considerations High-level security considerations can be found in the [draft-ietf- alto-problem-statement]. 6. IANA Considerations This document does not mandate any immediate IANA actions. 7. References [RFC 5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [I-D.ietf-alto-reqs] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-ietf-alto-reqs-01 (work in progress),July 2009. [I-D.penno-alto-protocol] Penno, R. and Y. Yang, "ALTO Protocol", draft-ietf-alto-protocol-01 (work in progress), July 2009. Sun, et al. Expires August 26, 2010 [Page 5] Internet-Draft Server Notification mechanism February 2010 Author's Addresses Xianghui Sun China Telecom Beijing Research Institute No.118, Xizhimenneidajie, xicheng District Beijing 100035 China Email: sunxh@ctbri.com.cn Kai Li China Telecom Beijing Research Institute No.118, Xizhimenneidajie, xicheng District Beijing 100035 China Email: leekai@ctbri.com.cn Kaiyu Zhou China Telecom Beijing Research Institute No.118, Xizhimenneidajie, xicheng District Beijing 100035 China Email: zhouky@ctbri.com.cn Sun, et al. Expires August 26, 2010 [Page 6]