Network Working Group Yunfei.Zhang Internet Draft China Mobile Intended status: Informational Hongluan.liao Expires: April 23, 2009 China Mobile Naibao.ZHOU China Mobile October 23, 2008 P2P Traffic Localization by Alias Tracker for Tracker-based P2P applications (ATTP) draft-zhang-alto-attp-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created. 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 February 1, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract zhang & liao Expires April 23, 2009 [Page 1] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 Currently P2P applications have accounts for large cross-ISP traffic. This document proposes a method to reduce cross-ISP traffic by setting cooperative ISP-friendly trackers in the ISP's network. Through improving the random node selection mechanism in P2P tracker-based application, we can effectively reduce cross-ISP traffic as well as the cost of network equipments and network operation. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 [1]. Table of Contents 1. Introduction................................................2 1.1. Terminology............................................3 2. Overview....................................................4 3. ISP's Considerations on ISP-P2P application provider align....5 4. ATTP: One mechanism for Tracker-based P2P applications........6 4.1. Architecture...........................................6 4.2. Procedure of ATTP.......................................8 4.3. The strategies of alias Tracker choosing seed nodes.....10 4.3.1. According to the state of the network.............10 4.3.2. According to the seed node service capabilities....13 4.3.3. The connection strategy and economy of the AS......13 4.4. The process order of Alias Tracker selecting seed nodes.13 4.5. Advantages of ATTP.....................................14 5. Security Considerations.....................................14 6. IANA Considerations........................................15 7. Conclusions................................................15 8. Acknowledgments............................................15 8.1. Normative References...................................16 8.2. Informative References.................................16 Author's Addresses............................................16 Intellectual Property Statement................................17 Disclaimer of Validity........................................17 1. Introduction Currently P2P applications take a large share in total network traffic. According to the recent record of China Telecom, one of the zhang & liao Expires April 23, 2009 [Page 2] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 biggest ISP in China, P2P applications account for more than 50% of the Internet traffic in the daytime and 90% at night. Meanwhile the ISP international outport is jammed seriously by P2P applications almost all the time. The problem of cross-ISP traffic is serious which will bring out great cross-ISP traffic billing as well as network management and operation cost for ISPs. The purpose of this document is to specify a cooperative tracker building mechanism aligned with tracker-based P2P application providers to improve the seed selection mechanism for Tracker-based P2P applications. This mechanism doesn't change current P2P software and can make node selection consistent with physical topology, so cross-ISP traffic can be effectively reduced and the cost of network equipment and network operation is largely cut off. 1.1. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described RFC 2119 [RFC2119]. This section defines some key concepts using in this document. Tracker: A server which assists in the communication between live peers. It is a major critical point. Clients communicate with the tracker to get peer list. After initiate downloads clients communicate with the tracker periodically to negotiate with newer peers. Tracker-based application: We denote P2P file sharing applications like Bittorent and P2P streaming (both live and VOD) applications like PPlive as tracker-based applications. In a P2P tracker-based system, each end node requests seed/leecher list from the tracker. Seed Node/Leecher node: P2P clients that can provide data to other clients, allowing other clients to download p2p data. They register themselves at the tracker and refresh information periodically. The difference in seed Node and leecher node is just how much it holds the shared files. A seed holds the whole parts of the specific files. DNS Redirection: A technique on the Internet for making a domain name available under many IP address. Through this technique user request to a domain name can be redirected to a new address. zhang & liao Expires April 23, 2009 [Page 3] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 2. Overview Currently P2P applications accounts for significant traffic on the Internet, For example, in China some P2P applications including Bittorent[4] PPlive[5] have take 75% share of total P2P traffic. Such applications are all tracker-based. The tracker selects nodes without any knowledge about the physical topology. That causes a serious mismatch between physical topology and application topology and it contributes to most P2P cross-ISP traffic, which will bring great network operation cost for ISPs. These P2P applications are tracker-based and we mainly focus on this type of P2P applications because its traffic dominance in the Internet. In this document we will take Bittorent as an example to describe the problem and the related solutions. Obviously it can be used in other tracker-based P2P applications. As showed in Figure 1 there are three components in Bittorent: tracker, websites and end nodes. The website provides resource information published by end nodes about which files others can download. Other end nodes visit the website to search the target files and then download related torrent files; the trackers is an index server which maintains seed nodes/leecher nodes list that can provide files data and it returns nodes list to end nodes after they request. After receiving the corresponding nodes list, the requesting end node then connects the seed nodes/leecher nodes to request the file blocks and download file blocks from these nodes when these nodes allow its request. In current mechanism the cross-ISP traffic will be great. The most important reason is that trackers select some seed nodes/leecher nodes and return them to end nodes without knowledge of physical topology. End nodes will contact these seed nodes/leecher nodes to download P2P data. If two nodes don't belong to the same ISP, cross- network traffic will be unavoidable. zhang & liao Expires April 23, 2009 [Page 4] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 /------------------------\ | Trackers | \------------------------/ /--------------\ ^ ^ | websites | | |(4) | \--------------/ |(3) |return | ^ | |Parsing |node list | | |(2) |.torrent | |periodically | | |file and | |communication | | download |request | |and heart beat (1) | | .torrent |node list| | visit| | file | | | | | | V | |--------------------------------| | | end nodes | | |--------------------------------| | | ^ | (5)request | | (6) | status and data| | return | | | status and data| V | | |--------------------------------| | end nodes | |--------------------------------| Figure 1 Bittorent 3. ISP's Considerations on ISP-P2P application provider align In a word, node clustering and localization is very important for reducing cross-ISP traffic. The basic idea is to let operators/ISPs and service providers of P2P application cooperate with node clustering and localization. On one hand, operators totally know their own network topology. They can effectively manage and classify inner nodes of operator's network. On the other hand if service providers of P2P application want to make node localized they have to have some knowledge of the network topology and other information. There are several choices in the use of network topologys. One choice is that the operator provides topology and/or bandwidth information to P2P applications. The other choice is that P2P applications provides live nodes information to the operator and the operator makes the decision of node clustering and localization based on its network knowledge. zhang & liao Expires April 23, 2009 [Page 5] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 Because the topology and/or bandwidth information is are important and private for the operator,it's difficult to make it public for security consideration becuse: 1) Malicious nodes/parties may use such information to launch network attack; 2) It may affect the fairness of network to applications if P2P application is the basic users of such services; So it's a good choice for operators to provide node localization decision themselves with the help of P2P application providers. In this document we propose one mechanism to reduce cross-ISP traffic for Tracker-based P2P applications. It has some advantages: 1) It can keep operator independence and privacy; 2) It can make full use of operator's knowledge to reduce cross-ISP traffic; 3) it don't add more burdens for the P2P application providers to make node and request localization decision and it make increase the application performance(esp. decreasing latency and increasing throughput by localization). So it's a double-will game. 4. ATTP: One mechanism for Tracker-based P2P applications 4.1. Architecture ATTP (Alias Tracker for Tracker-based P2P applications)is proposed in this document to reduce the cross-ISP traffic. Three kinds of new components/mechanisms are introduced in ATTP. We create a mirror-P2P environment in home network by the cooperation with original P2P application. The first new component is called Alias tracker. It is controlled by the operators and is a cooperative component with original tracker in P2P applications. The second new component is inner resource website. The Resource websites is similar to the websites in Bittorent. The most popular resource information and the related torrent files will be issued here. The inner nodes will be redirected to resource websites when they try to visit Bittorent websites residing in foreign networks. zhang & liao Expires April 23, 2009 [Page 6] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 The third part is a redirection mechanism in inner DNS server. When inner nodes visit the original Bittorent website, ip address of this website should be gotten from inner DNS server. When inner DNS server receives the request, it will return the IP address of the mirror resource website. So inner nodes will be automatically redirected to resource website. Alias Tracker is designed to provide peer index service for inner nodes. It monitors live seed/leecher information in the Internet scale and when inner nodes request peer list, it will first return the inner nodes. One special case is that all the nodes return by alias tracker are local nodes of operator's network. Alias Tracker can reduce the cross-ISP traffic effectively between different operator networks through returning inner nodes as more as it can. If we just depend on the original BT websites and BT trackers we can not achieve the goals because operators can not control the BT trackers that may not in operator's network. Alias Tracker is deployed in operator's network. In order to make users automatically visit Alias tracker, some resource description information (such as .torrent in Bittorent) should be changed to amend the original tracker address to be Alias tracker address. Through ATTP local nodes will be first recommended in the node list to download file blocks thus the network traffic could be reduced greatly for P2P application. We take Bittorent as an example to describe the architecture as Figure 2. zhang & liao Expires April 23, 2009 [Page 7] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 network of | operator's home network other operators | | /------------\ | | Trackers | <--- |------- \ \------------/ | /----------------\ | | Alias Trackers | /-----------\ | \----------------/ | websites | <---------|---------/ \-----------/ | /------------------\ | | | Resource websites | | | \------------------/ | | | | | | |---------------| | |---------------| | Foreign nodes | | | Inner nodes | |---------------| | |---------------| | Figure 2 ATTP 4.2. Procedure of ATTP According to the requirements, one or more Alias trackers could be deployed as the mirror tracker for inner nodes of the ISP's network. As showed in Figure 3 the Procedure of ATTP is as follows zhang & liao Expires April 23, 2009 [Page 8] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 Original Original Alias Resource inner BT websites BT trackers tracker websites nodes | | | | | | get files | | | | |<--------------|--------------| issue | | |---------------|------------->| files | | | | |--------->| | | | get peer list| | | | |<-------------| | | | |<-------------| | | | | | | visit | | | | |<----------| | | | |---------->| | | | | | | | | | get peer | | | | | list | | | |<---------|-----------| | | |----------|---------->| | | | | | | | | | | | | | | | Figure 3 Procedure Firstly alias tracker obtains a list of N files which are downloaded most often at the most popular Bittorent websites. The parameter N can be adjusted according to the service ability of Alias tracker (Another way is to get the files information that are downloaded most often from the Web Cache servers which are deployed widely .Then Alias tracker obtains the resource description files of above files from Bittorent websites (such as .torrent files for BT).It may cooperate with the original BT websites or simply act as normal Bittorent client to get the description files. We change the original tracker address in the .torrent files to the address of the alias tracker (it is easy to be changed because it is plain text). Then the new resource description files are issued to the resource website in inner operator's network. The operator use DNS redirection [RFC2234] or other application layer redirection to change the user request from Bittorent website to the resource website in operator's network. When users want to visit the original BT website, actually they will visit the resource website in inner operator network. Users will contact alias tracker through analyzing the .torrent file form the resource website in operator's network. zhang & liao Expires April 23, 2009 [Page 9] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 Obviously by this means inner nodes will request the Alias tracker for file downloading. Alias tracker functions similar to BT Tracker server It maintains the seed/leecher nodes lists that can provide files data which are listed in the resource website in the home network. And it will return related nodes list when end users request. To further improve the downloading performance, an enhanced tracker communication procedure between original tracker and alias tracker is defined in ATTP to increase the amount of available seed/leechers. Alias tracker gets the outside seed/leecher node list of the files from BT tracker. Again this can be achieved by the proactive report from the original tracker or reactive request as a normal P2P client. When Alias tracker return seed/leecher nodes list, it will follow the following policies: a) If the amount of inner nodes of the ISP's network is enough, all of the nodes that are returned by alias tracker are inner nodes. b) If the amount of inner nodes is not enough it should return all the inner nodes and some foreign nodes. At last the end nodes will download the files from the seed nodes returned by alias tracker. 4.3. The strategies of alias Tracker choosing seed nodes 4.3.1. According to the state of the network Alias Tracker will monitor and record the operation state of current network including network loads, network topology. When Alias Tracker selects seed nodes, it will make the best choice according to all above information. zhang & liao Expires April 23, 2009 [Page 10] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 +-------------------------------------------+ | | | ISP +---------+ | | | Alias | | | | Tracker | | | | | | | +---------+ | | ^ ^ | | /| |\ | | / | | \ | | / | | \ | | +--------+ / | | \ +--------+ | | | +----+ | / | | \ | +----+ | | | | | DP | |/ | | \| | DP | | | | | +----+ | | | | +----+ | | | | +----+ | | | | +----+ | | | | | U1 | | | | | | U2 | | | | | +----+ | | | | +----+ | | | +--------+ | | +--------+ | | | | | | | | | | | | | | +--------+ | | +--------+ | | | +----+ | | | | +----+ | | | | | DP | | | | | DP | | | | | +----+ |------+ +------| +----+ | | | | +----+ | | +----+ | | | | | U4 | | | | U3 | | | | | +----+ | | +----+ | | | +--------+ +--------+ | | | +-------------------------------------------+ Figure 4 Sub-domain clustering network monitoring the traffic According to the Figure 4, in a network such as an ISP network, Alias Tracker will firstly select seed nodes which belong to its own network. A network can be divided into several sub-domain networks which load maybe different. So we provide a sub-domain clustering traffic monitoring method. The details of the method are as follows: a network is divided into various small sub-domain clustering networks which have one or more DP (Detection Point) nodes. In the sub-domain networks, DPI equipments can be used as DP nodes and responsible for monitoring the sub-domain network traffic load, and calculate the sub-domain network's traffic density: Formula: Traffic density=Total of traffic for a period/Number of users zhang & liao Expires April 23, 2009 [Page 11] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 For example, in an access network, DPI can monitor and calculate all of the network traffic. We also can get the total number of the users accessing to the network. As a result, the traffic density of the network can be computed through the formula. DP nodes will send information about the traffic density to the Alias Tracker periodically. When Alias Tracker chooses seed nodes, it will priority select nodes which belong to traffic density lower sub-domain network. But in the lower traffic density sub-domain network, the upstream bandwidth of the seed node maybe has been very small, and the loads of the seed node are very heavy. As a result, Alias Tracker not only concerns the traffic density, but also need to consider the seed nodes' service capabilities. +------------------------------------------------+ | | | | | | +-----+ | | | | | | | |------| DPI | | | | +-----+ | | | | | | | | +-------------------|--------------------+ | | | | | | | | +--------+ | | | | | | | | | | --->| BRAS |<--- | | | | / +--------+ \ | | | | / | | \ | | | | / | | \ | | | | / | | \ | | | | / | | \ | | | | +----+ +----+ | | +----+ +----+ | | | | | U1 | | U2 |--+ +--| U3 | | U4 | | | | | +----+ +----+ +----+ +----+ | | | | | | | +----------------------------------------+ | +------------------------------------------------+ Figure 5 Accessing network works as a sub-domain network For example, in Figure 4 sub-domain networks' traffic density: sub- domain A < sub-domain B < sub-domain C < sub-domain D. Assuming that seed nodes U1 and U2 are optional, but the seed node U1's available zhang & liao Expires April 23, 2009 [Page 12] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 capabilities (such as upstream bandwidth, etc) are less than U2's.Preference will be given to seed node U2 by Alias Tracker, despite the density of sub-domain B is greater than sub-domain A's. 4.3.2. According to the seed node service capabilities Each seed node has different capabilities. In addition to general information, each seed node will report performance data to the Alias Tracker periodically. The data may include, but are not limited to these: the CPU's average utilization rate, the average memory usage rate, available network bandwidth, and other information. 4.3.3. The connection strategy and economy of the AS The AS business relationship of different network operators decide the price of transferring a bit of data. Choosing a different network, the inter-working billing rate is not the same. In this method, when Alias Tracker selects seed nodes, the selection order is: 1) Selecting the seed nodes inside the AS; 2) Selecting the seed nodes in other AS which belong to the same network operators; 3) Selecting the seed nodes in other network operators whose inter- working billing rate is lower; The business relationship of AS can obtained by operators or by detection methods [CAIDA have done a lot of work in this area], which is not within the scope of this invention. Selection order is showed as the following: 1) AS; 2) Node capabilities; 3) The state of network congestion. 4.4. The process order of Alias Tracker selecting seed nodes Alias Tracker implements all functions of the origin Tracker: monitoring the current end users downloading resources; allocating the other end users which are currently downloading the resources and returning the peer list to the client, the specific selection process are as follows: zhang & liao Expires April 23, 2009 [Page 13] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 1) A network such as an ISP network, will be divided into several sub-domain clustering networks. For example, an access network can act as a sub-domain clustering network; 2) A DPI equipment will be deployed in the network export link interface to monitor the sub-domain network traffic; 3) According to the total numbers of traffic and network users obtained from DP(Detection Point) and BRAS, the network traffic density can be calculated through the formula, further more the network congestion situation can be got; 4) DP will send all the sub-domain traffic density values to the Alias Tracker periodically; 5) At the same time, each node will send the node service capabilities information to Alias Tracker, which include the average CPU utilization rate, the average utilization rate of memory, available network bandwidth, and some other information; 6) Pre-set the configure file on the Alias Tracker, which indicate the connection strategy and economic billing rate of AS; 7) When a node sends a request for seed nodes list to Alias Tracker, it will integrate traffic density, nodes service capabilities, and AS information, comprehensive judgment to choose the low traffic density, strong capacity nodes as seed nodes; 8) Alias Tracker returns the peer list to the requesting node; 4.5. Advantages of ATTP ATTP just needs some alias trackers and website built up by the operator and only need configure DNS re-direction mechanism to achieve above goals. The cost is low and the deployment is simple. It can make operators keep independence and privacy when making full use of operator's advantages. And it don't add more burdens for the P2P application providers to make node and request localization decision and it make increase the application performance(esp. decreasing latency and increasing throughput by localization). So it's a double-will game. 5. Security Considerations This document does not currently introduce security considerations. zhang & liao Expires April 23, 2009 [Page 14] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 6. IANA Considerations This document does not specify IANA considerations. 7. Conclusions This document describes a novel method to reduce cross-ISP traffic in P2P tracker-based applications such as Bittorrent and PPlive. Through cooperating ISP with P2P application providers, ATTP acts as a mirror P2P application provider in its home network to lower cross-network traffic. 8. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. zhang & liao Expires April 23, 2009 [Page 15] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [3] [RFC2234]M. Crawford, "Non-Terminal DNS Name Redirection", August 1999. 8.2. Informative References [4] J.A. Pouwelse, P. Garbacki, D.H.J. Epema, H.J. Sips,THE BITTORRENT P2P FILE-SHARING SYSTEM: MEASUREMENTS AND ANALYSIS,IPTPS 2005. [5] www.pplive.com. Author's Addresses Yunfei Zhang China Mobile Communications Corporation Phone: +86 10 66006688 Email: zhangyunfei@chinamobile.com Hongluan liao China Mobile Communications Corporation Phone: +86 10 66006688 Email: liaohongluan@chinamobile.com Naibao ZHOU China Mobile Communications Corporation Phone: +86 10 66006688 Email: zhounaibao@gmail.com zhang & liao Expires April 23, 2009 [Page 16] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. zhang & liao Expires April 23, 2009 [Page 17] Internet-Draft P2P Traffic Localization by Alias Tracker October 2008 zhang & liao Expires April 23, 2009 [Page 18]