ALTO WorkingGroup Yu Meng Internet-Draft Jun Wang Intended status: Informational ZTE Corporation Expires: Feb 20, 2010 Tao Ma Hui Wang Miao Xiong MINE lab,Beijing University of Posts and Telecommunication Aug 20,2009 Relay Usage for ALTO in Real Time Communication draft-meng-alto-relay-00 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 January 21, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Meng, et al. Expires Jan 21, 2010 [Page 1] Internet-Draft ALTO relay usage July, 2009 Abstract ALTO has been proposed to help peer-to-peer (P2P) applications make better decisions with respect to peer selection. It provides the underlying network view for P2P users to choose the optimal resource instances. The usage of ALTO has covered nearly all the P2P applications, such as file sharing, media streaming, real time communications and etc. In real time communication where the source and destination are fixed, it is used to choose relays. This document defines the relay usage for ALTO in real time communication. Beside the relay for NAT traversal mentioned before, this document introduce a relay called Qos relay to improve the performance. After analyzing the necessity of this type of relay and the benefits of combining ALTO with relay, two models of combination are described according to the coupling tightness between ALTO and relay service. One is called "integrating relay service into alto service" and the other is "cooperation between P2P application provider and ISP". In all, the usage of ALTO in real time communication has been developed in this document. Meng, et al. Expires Feb 20, 2010 [Page 2] Internet-Draft ALTO relay usage July, 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The necessity of relay in the P2P real time communication. . . 5 2.1. Connectivity relay . . . . . . . . . . . . . . . . . . . . 5 2.2. Qos relay. . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. The phenomenon of anti-triangular . . . . . . . . . . 5 2.2.2. The benefits of combining ALTO service with relay service . . . . . . . . . . . 7 3. The model of combining ALTO service with relay service . . . . 7 3.1. Integrating relay service into alto service . . . . . . . 8 3.1.1. Server functions . . . . . . . . . . . . . . . . . . 8 3.1.2. Server database . . . . . . . . . . . . . . . . . . . 9 3.1.3. Protocol . . . . . . . . . . . . . . . . . . . . . . 9 3.1.4. Measurements. . . . . . . . . . . . . . . . . . . . . 10 3.2. Cooperation between P2P application provider and ISP . . . 10 4. Security and privacy . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Meng, et al. Expires Feb 20, 2010 [Page 3] Internet-Draft ALTO relay usage July, 2009 1. Introduction Network traffic generated by Peer-to-Peer (P2P) applications determines a large portion of the overall traffic in the Internet. Because P2P applications have limited information about the underlying network topology, they usually select direct P2P connections in a suboptimal way. As a result, P2P traffic often crosses several ISPs, causes high load and congestion on particular network links, reduces application performance, and generates high costs for ISPs. This problem is discussed and described in detail in the ALTO problem statement[draft-ietf-alto-problem-statement]. The goal of ALTO is to solve the ALTO problems by providing information which can help peer-to-peer (P2P) applications to make better decisions with respect to peer selection. The ALTO solution provides a logical entity called ALTO server which provides the information and guides the peer selection. The ALTO service provided by ALTO server is most likely deployed by ISP which has the accurate topology information. The ALTO clients are possibly the P2P application users who try to receive good experiences by locating suitable peers or resource providers. ALTO service can be applied in many scenarios. The ALTO problem statement[draft-ietf-alto-problem-statement] has listed five usecases of ALTO service: file sharing, live media streaming, real time communication, DHTs and cache/mirror selection. In the five cases, ALTO service is mainly used to sort multiple destinations in the P2P communication. For example, a user would locate the proximatepeer with the help of ALTO according to underlying network topology among a group of resource instances. But in real time communication, the source and destination are fixed. Under this circumstance, ALTO service would only help peers to choose relay, which acts as a bridge in the application layer between the source and destination. The relay mentioned in the ALTO problem statement [draft-ietf- alto- problem-statement] is applied to connect users with limited access to the Internet (e.g. users behind NATs, firewalls or HTTP proxies). ALTO would help them find the best relays to relay the media flows. We call this type of relay as "connectivity relay", which is used to guarantee the connectivity of real time communication. This document proposes another type of relay, which can be used to improve performance of real time communication, called "Qos relay" here. This document would describe the background of Qos relay and design the mechanism of combining ALTO service with relay. On the basis of the tightness of coupling between ALTO and relay service, we put forward two methods to apply ALTO solution for relay to improve performance of real time communication. Meng, et al. Expires Feb 20, 2010 [Page 4] Internet-Draft ALTO relay usage July, 2009 2. The necessity of relay in the P2P real time communication We argue that two types of relay are needed in P2P real time communication, which include the connectivity relay and Qos relay. Here the necessity of relay would be formulated to show that relay is generally useful. Additionally, the benefits of combining ALTO service with relay service is generalized, which expands the range of application of ALTO. 2.1. Connectivity relay P2P real time communication allows users to establish direct media flows, usually to place audio and video calls, or to have text chats. In the basic case, media would flow directly between the two endpoints; however, in the general case, a significant portion of communications between users with limited access to the Internet (e.g. users behind NATs, firewalls or HTTP proxies) need to be relayed by other elements. Such media relays are distributed over the Internet -- in some cases co-located with applications with a public address; the goal of an ALTO solution would be to help peers find the best relays[draft-alto-problem-statement]. We call this type of relay as connectivity relay which aims to guarantee the connectivity of the endpoints of real time communication. This type of relay is widely used, but not the focus of our document. 2.2. Qos relay This document stresses upon another type of relay, which can be used to improve performance of real time communication, called Qos relay here. Its existence comes from the phenomenon of anti-triangular in Internet. Because of the quality requirements of real time communication and this widely existing phenomenon, Qos relay is of great significance and impact. 2.2.1. The phenomenon of anti-triangular Among all of the sessions on the internet, there are always some sessions with direct IP routing RTTs which exceed the RTT threshold for quality VoIP communication. For these sessions, it is likely to find one-hop overlay relay paths to reduce the RTTs. The RTTs of these relay paths are less than those of the direct IP routing paths. This is called as the phenomenon of anti-triangular. Meng, et al. Expires Feb 20, 2010 [Page 5] Internet-Draft ALTO relay usage July, 2009 IP routing on the Internet is dependent on the provider-customer and peer-peer commercial contractual relationships between neighboring Autonomous Systems (AS) or Internet Service Providers (ISPs). Usually a provider AS transits traffic for a customer AS, while a customer AS does not transit traffic for its provider AS. Constrained by this rule, an Internet AS-level routing path usually has the valley-free property. Because each AS can enforce its own routing policy, the direct IP routing path between two end hosts is not necessarily the optimal one among all possible routing paths between them, including overlay routing paths. Under the following two conditions, overlay routing paths can be faster than the direct IP routing paths[SL06]. (1) An AS in a direct routing path is congested or failed. Consider a session between two end hosts in AS A and AS B. The direct IP routing path between them contains AS C which is congested. If there is a one-hop relay overlay routing path between AS A and AS B through AS D which does not contain the congested AS C on the IP routing path, this relay path will be faster than the direct IP routing path. Even worsely, the direct routing path may contain failed ASes, while needs to be bypassed by overlay routing path. In these cases, overlay routing latency can be shorter than the direct IP routing path. (2) Multi-homed customer ASes can further improve overlay routing. A multi-homed customer AS connecting to multiple upstream provider ISPs can act as the intermediary relay to transit traffic for its provider ISPs, and this one-hop relay path can have shorter AS hops than the direct IP routing path. Considering the AS graph in Figure 1, an AS B has multi-homed connections to two providers AS D and AS E. For the two end hosts in AS A and AS C, the direct IP routing path between them is A-D-F-H-I-G-E-C, which has 7 AS hops, while the overlay routing path through AS B is A-D-B-E-C, which has only 4 AS hops, 3 hops shorter. As the path latency is correlated to the AS hops on this path, the RTT of overlay routing is highly likely to be shorter than that of direct IP routing despite of the relay delay at AS B. Meng, et al. Expires Feb 20, 2010 [Page 6] Internet-Draft ALTO relay usage July, 2009 AS H****AS I / \ / \ AS F AS G / \ / \ AS D AS E / \ / \ / \ / \ / \ / \ AS A AS B AS C / provider-to-customer edge * peer-to-peer edge Figure 1 Multihome AS-overlay routing is faster than direct IP routing 2.2.2 The benefits of combining ALTO service with relay service In P2P applications, the underlay topology is very limited known, which results in the suboptimal choice of peers and unnecessary waste of network resources. For relay service, P2P application needs to do a lot of measurements to choose the suitable relays. If ALTO service is combined with relay service, we can get reliable and accurate information from the ISPs, including accurate AS topology, link cost and QoS parameters. Both ISPs and P2P applications can benefit from the combination. The introduction of ALTO service makes the relay selection process and the overlay routing under the control of ISPs, which avoids the traffic congestion and confusion of selection of nodes in P2P network which is lack of management. It also reduces the costs of measurements for P2P applications because many parameters can be obtained from the ALTO server. 3. The model of combining ALTO service with relay service The idea of combining ALTO service with relay service can be implemented in two models. Here two models are illustrated. The two models are different in the tightness of coupling between ALTO and relay. For the first model, ALTO server accounts for both the management and ranking of relay candidate lists. Relay service is tightly coupled with alto service. We call this model as "integrating relay service into alto service". For the second model, ALTO server is unaware of relay peer. The P2P application provides relay candidate lists and ALTO server only sorts it considering topological proximity. The coupling relationship between ALTO and relay is relatively loose. It reflects the cooperation between ISP and P2P application providers. ALTO server provides the P2P application provider the necessary underlying network information to help choose the suitable relay candidates. We call this model as "cooperation between P2P application provider and ISP". Meng, et al. Expires Feb 20, 2010 [Page 7] Internet-Draft ALTO relay usage July, 2009 3.1 Integrating relay service into alto service As the anti-triangular phenomenon widely exists in Internet, relay service can be deemed as an important tool for application layer traffic optimization, which means ALTO server would take the relay service into its functional components. In this model, the relay candidate lists are maintained in ALTO servers. An ALTO server is a logical entity that provides interfaces to query the alto service. The ALTO server may integrate relay service into alto service to improve client's performance or quality of service. ALTO clients can query the ALTO server for the list of available relay peers or servers. An illustration of the architecture is presented in the following figure. +-------------------------------------------------------------------+ | AS1 or cluster1 | | +-----------+ +---------+ +--------+ | | |Relay | | ALTO | ALTO Query/Response | ALTO | | | |Information|........| Server | ------------------- | Client | | | +-----------+ +---------+ +--------+ | | | | | +----------------------------|------------------------------|-------+ +----------------------------|------------------------------|-------+ | AS2 or cluster2 | | | | | | | | +-----------+ +---------+ +--------+ | | |Relay | | ALTO | ALTO Query/Response | ALTO | | | |Information|........| Server | ------------------- | Client | | | +-----------+ +---------+ +--------+ | +-------------------------------------------------------------------+ Figure 2 The architecture of combining ALTO service with relay service Four key points are highlighted in this model: server functions; server database; protocol; measurements. 3.1.1. Server functions Functions of ALTO server include: 1.Maintain and update AS topology; 2.Peer registration ; 3.Gathering relay list; 4.Update adjacent AS information Meng, et al. Expires Feb 20, 2010 [Page 8] Internet-Draft ALTO relay usage July, 2009 3.1.2. Server database ALTO server requires these data below: AS topology information; AS number(ASN); Mapping information between ASN and IP address(es); Peer registration information; Relay list; Hops to the adjacent AS. 3.1.3. Protocol Communication protocol in the system comprises protocol between ALTO servers, protocol between ALTO server and peers, protocol between peers. An illustration of the flowchart is presented in the following figure. p1 ALTO server1 ALTO server2 p2 | | | | |------1------>| | | |--------------|-------------2-----------|------------>| | | |<-----3------| | |<------------4-----------| | |<-----5-------| | | | |-------------6---------->| | | | |------7----->| |<-------------|-------------8-----------|-------------| | | Figure 3 Example of integration model Meng, et al. Expires Feb 20, 2010 [Page 9] Internet-Draft ALTO relay usage July, 2009 Figure 3 shows an example of integration model. Peer 1 have established a session to peer2 and it measures the direct path QoS value. 1> If Peer 1 needs relay(direct Qos value are not satisfactory), peer1 sends a relay request to ALTO server1.After receiving the request ,server1 searches relay peer/server information among adjacent AS through communication with other ALTO servers. 2> Peer 1 sends a relay notification to peer 2 via direct path. 3> After receiving from peer 1,peer 2 sends a relay request to ALTO server 2. Server 2 does the same as in step1. 4> ALTO server 2 sends the relay information to ALTO server 1, server 1 will do an intersection operation between its own relay information and the received relay information, and then obtain the relay candidate list. 5> ALTO server 1 returns the relay list to peer 1. Peer 1 measures the QoS value to those candidates in the list. 6> ALTO server 1 returns the relay candidate list to ALTO server2. 7> ALTO server 2 returns the relay candidate list to peer 2, and peer 2 measures the QoS value to those candidates in the list. 8> peer 2 returns the measuring results to peer 1. Based on the measuring results, peer 1 will determine the best relay peer. 3.1.4. Measurements Measurements in the system mainly consist of AS topology measurements and QoS value measurements. AS topology measurements contain adjacent AS hops and other connection relationship information. QoS value includes delay, jitter, loss rate etc from peers to relays. Source and destination should both measure the Qos values to relays. The destination gives the results to the source which will deal with them and filter the suitable relays. 3.2. Cooperation between P2P application provider and ISP We define another model which is compatible with the current ALTO architecture. The relay service is not integrated but considered as the ordinary peer selection process. The peer would provide the ALTO server with the relay candidate list, and the ALTO server would rank the list. Here the relay candidate list is provided and maintained by P2P application providers. P2P software users might configure or cache this list before querying ALTO server. The relay candidate discovery mechanism might be designed by P2P application providers. After receiving the ranked list, the end users negotiate with each other and choose the most suitable relay according to the ALTO server response. Meng, et al. Expires Feb 20, 2010 [Page 10] Internet-Draft ALTO relay usage July, 2009 The ALTO goal here is not only for traffic localization but also for improving the Qos. ALTO server might use BGP routing information to calculate the preference of relay candidates that P2P application provides. The rating method can be seen in [draft-racz-bgp-based- alto-service]. In P2P real time communication, P2P application providers has deployed relay candidate peers or servers, then ALTO server assists the users to select relay to reduce inter-domain traffic and achieve a more efficient inter-domain traffic pattern between ISPs. It is meaningful to both P2P application and ISPs. The flow chart of P2P real time communication with the cooperation between ISP and P2P application providers can be seen as follows: p1 ALTO server1 ALTO server2 p2 | | | | |------1------>| | | |<------2------| | | |--------------|-------------3-----------|------------>| | | |<-----4------| | | |-------5---->| |<-------------|-------------6-----------|-------------| | | | | Figure 4 Example of cooperation model Figure 4 shows an example of cooperation model. Peer 1 have established a session to peer2 and it measures the direct path QoS value. 1> If peer 1 needs relay(direct Qos value are not satisfactory), peer 1 sends the relay candidate lists to ALTO server1.After receiving, ALTO server1 ranks the lists according to its policy or topological proximity information. 2>ALTO server 1 returns the ranked list to peer 1, and peer 1 measures the QoS value to those candidates in the relay list. 3> Peer1 sends a relay notification to peer2 via direct path. 4> After Peer2 receives the notification from peer 1, it sends the relay candidate list to ALTO server2. Server2 does the same as in step1. 5> ALTO server 2 returns the ranked list to peer 2, and peer 2 measures the QoS value to those candidates in the relay list. 6>Peer 2 returns the measuring results to peer 1. Based on the measuring results, peer 1 will determine the best relay peer. A possible measure is to intersect the received peer 2's relay list and peer 1's own relay list to choose the best relay. Meng, et al. Expires Feb 20, 2010 [Page 11] Internet-Draft ALTO relay usage July, 2009 This model needs the cooperation between P2P application providers and ISPs. P2P application providers would provide the relay lists they maintain and asks ISPs to help the selection. The ISPs would sort the candidates according to both the policy and topological proximity. The results would be sent back to end users, who would decide whether or which to choose. The cooperation between the two parties would result in better relay selection and further improve the Qos of P2P real time communication. 4. Security considerations High-level security considerations can be found in the ALTO problem statement [draft-ietf-alto-problem-statement] and they apply for this document as well. 5. IANA Considerations None. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [draft-ietf-alto-problem-statement] Seedorf, J., Burger, E., "Application-Layer Traffic Optimization (ALTO) Problem Statement", Internet-Draft, May, 2009. [SL06] S. Ren, L. Guo, and X. Zhang, "ASAP: an AS-Aware Peer-Relay Protocol for High Quality VoIP with Low Overhead", in Proceedings of 26th International Conference on Distributed Computing Systems (ICDCS'06), Lisbon, Portugal, July 4 - 7, 2006 Meng, et al. Expires Feb 20, 2010 [Page 12] Internet-Draft ALTO relay usage July, 2009 Authors' Addresses Yu Meng ZTE Corpoporation No68, Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877648 Email: meng.yu@zte.com.cn Jun Wang ZTE Corpoporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877648 Email: wang.jun17@zte.com.cn Tao Ma Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 P.R.China Email: abcdmatao@gmail.com Hui Wang Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 P.R.China Email: whui.bupt@gmail.com Miao Xiong Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 P.R.China Email: xiongbearie@gmail.com Meng, et al. Expires Feb 20, 2010 [Page 13]