PPSP L.Xiao Internet Draft Nokia Siemens Networks Intended status: Informational D.Bryan Expires: April 21, 2011 Cogent Force, LLC/Huawei Y.Gu Huawei X.Tai China Mobile/BUPT February 22, 2011 A PPSP Tracker Usage for Reload draft-xiao-ppsp-reload-distributed-tracker-01 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 April 21, 2011. 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. liao Expires April 23, 2011 [Page 1] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Abstract This document defines PPSP tracker usages for REsource LOcation And Discovery (RELOAD). Although PPSP assumes a centralized tracker from peer's point of view, the logical centralized tracker could be realized by a cluster of geographically distributed trackers. In this draft, we design distributed trackers system, which are organized by RELOAD. It provides lookup service for file/channel indexes and Peer Status among the distributed trackers. Table of Contents 1. Introduction...................................................2 2. Terminology and Conventions....................................4 3. Content Information Registration and Update....................5 3.1. Kind Data.................................................5 3.2. Message flows.............................................6 4. Lookup Content Index (a Swarm).................................8 5. Peer Status Registration, Update and Lookup....................9 6. Kind Definition...............................................11 6.1. CONTENT-REGISTRATION Kind Definition.....................11 6.2. PEER-STATUS Kind Definition..............................11 7. Open Issues...................................................11 8. Security Considerations.......................................12 9. IANA Considerations...........................................12 10. Acknowledgments..............................................12 10.1. Normative References....................................13 10.2. Informative References..................................13 Author's Addresses...............................................14 1. Introduction PPSP assumes that a centralized 'tracker' is used to communicate with the PPSP Peers for content registration and location. The content index is stored in the tracker with location information that which peers have the content. However, the logically centralized 'tracker' could be also realized by a cluster of geographically distributed trackers or deployed in multiple servers in a data center, which can increase the content availability, the service robustness and the network scalability or reliability. The management and locating of index information are totally internal behaviors of the tracker cluster, which is invisible Xiao Expires April 21, 2011 [Page 2] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 to PPSP Peers. The signaling between PPSP Peers and trackers is still the simple request/reply mechanism defined in PPSP tracker protocols. Therefore, the Tracker Nodes themselves construct and maintain a P2P overlay as shown in Figure 1. This document is to define the behaviors of the tracker overlay as a usage for RELOAD. Because all protocols this draft applies to - the PPSP tracker protocol, PPSP peer protocol and RELOAD - are still changing, this draft will certainly change in the future, and is very much a work in progress. The authors encourage list discussion of the draft and any suggestions are welcome. Tracker1 Tracker6 -- -- ---| |------| |--- | -- -- | | | -- -- Tracker2 | | Tracker Overlay | | Tracker5 -- -- | | | -- -- | ---| |------| |--- Tracker3 -- -- Tracker4 / \ \ / \ \ / \ \ ----- ----- ----- |Peer1| |Peer2| |Peer3| ----- ----- ----- Figure 1 PPSP Peers connect with Tracker Overlay by Tracker Protocol The document tries to handle the data maintenance for two kinds of information: content index and PPSP peer status, among a cluster of distributed trackers. Four basic functions in tracker overlay are defined as follows: o Content/ channel index information registration: PPSP Peers registrar/update their contents/channels to a Connection Tracker.(How to find the initial tracker locally is out of scope.) This tracker takes the advantage of the RELOAD data storage functionality to store the index information to tracker nodes in the tracker overly accordingly; o Look up a content/channel index: Once a PPSP Peer search for certain content/channel, it makes the request to a local connection tracker as defined in PPSP tracker protocol. If the data cannot be Xiao Expires April 21, 2011 [Page 3] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 found in the tracker locally, the tracker will locate the required index information in the overlay on behalf of the requesting PPSP Peer. Once the Peer List is fetched, the PPSP Peer will set up communications with the PPSP Peers in the Peer List as defined in PPSP Peer protocol; o PPSP peer status registration: PPSP Peers registrar/update their status in the tracker overlay. o Look up status of a certain peer: the tracker overlay can look up the status of a certain PPSP Peer. 2. Terminology and Conventions This document makes extensive use of the terminology and definitions from the RELOAD Base Protocol [I-D.ietf-p2psip-base], PPSP Requirements and Problem Statements [I-D.ietf-ppsp-problem- statement][I-D.ietf-ppsp-reqs] and the Gu PPSP Tracker Protocol proposal [I-D.gu-ppsp-tracker-protocol]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. This document defines the following additional terminology: PPSP Peer: The peer in PPSP protocol for content sharing and distribution among swarms. Tracker Node: The RELOAD Node with PPSP tracker usage. Each Tracker Node takes the responsibility to store and maintain certain content/channel index. Tracker Overlay: A RELOAD overlay constructed by Tracker Nodes. This Overlay is logically separated with overlay formed by PPSP Peers. Connection Tracker: The Tracker Node to which the PPSP Peer will connect when it wants to join the PPSP system. Swarm Tracker: The Tracker Node who is responsible for the swarm in the overlay, and stores the content information (e.g. Peerlist) of the swarm. Status Tracker: A Tracker Node which is responsible to store the status of a particular list of Peers. Xiao Expires April 21, 2011 [Page 4] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 3. Content Information Registration and Update To fulfill the functions of content information registration and update mentioned in Section 1, Tracker Node must maintain such resources related to peers; Content Registration: Information about the content which belongs to a specific swarm. It can be stored in a data structure denoted as ContentRegistration, which primarily includes an identification of the swarm, a name of the content, and a Peer List. 3.1. Kind Data Structure The data structure of ContentRegistration uses the RELOAD dictionary kind whereas the DictionaryKey value is the Swarm ID of the content required. The data structure of type ContentRegistration is shown as follows: struct{ Uint32 index; ChunkID chunk_id; }ArrayChunkListData; struct{ PeerID peer_id; ArrayChunkListData chunklist_data; }PeerListData; struct{ uint16 length; PeerListData peerlist_data; }PeerList; Xiao Expires April 21, 2011 [Page 5] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 struct { uint16 length; opaque content_name<0..2^16-1>; PeerList peerlist <0..2^16-1>; } ContentRegistration; The content of the PeerList structure are as follows: length the length of the data structure content_name the name of the content peerlist the content of Peer List 3.2. Message flows When a PPSP Peer wishes to share its contents to others, it will inform Tracker Overlay with the swarm information of the contents, then Swarm Tracker need to add this PPSP Peer into the corresponding Peer List to the swarm, or create a new swarm when there is no record of the swarm. Correspondingly, When a PPSP Peer deletes some old contents locally, it will inform Tracker Overlay that it would like to leave from a particular swarm, then the Swarm Tracker for the swarm need to delete this PPSP Peer from the corresponding Peer List which is defined in the requirement of PPSP [I-D.ietf-ppsp-reqs]. An example is given as the figure has shown below: Xiao Expires April 21, 2011 [Page 6] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 1. PPSP Peer wants to join into a swarm to share the content, first it will send a PPSP message "Join" with a Swarm-ID to TrackerA, which is a connection tracker of the Tracker Overlay for PPSP Peer connects to; 2. TrackerA first check local records, if it isn't responsible for the Peer List of this swarm, it still can map the Swarm-ID into a Node-ID identifying the Tracker Node which stores the Peer List. so TrackerA hashes the Swarm-ID to a Node-ID by some specific P2P algorithm, then sends a RELOAD message "StoreReq" to TrackerB whose ID is the Node-ID; 3. When Swarm Tracker (TrackerB) receives the request (or if TrackerA is responsible for the Peer List of the swarm, TrackerB=TrackerA), it searches locally the Peer List of the swarm whose ID is the Swarm-ID, then add the Node-ID of the PPSP Peer into the Peer List or delete it from that, and send the result of the operation (e.g. successful or failed) in a RELOAD message "StoreReqAns" to TrackerA through Tracker Overlay; 4. Finally, TrackerA analyses the received message, and responds to the requesting Peer by a corresponding PPSP message: "Successful (OK)" or some error messages. Note: When PPSP Peer is the first node of the swarm, which means it is the first one who stores this kind of content in the network, TrackerB doesn't have records of the new swarm, TrackerB will create a new ContentRegistration for the swarm locally, and put the identification of PPSP Peer into Peer List of this new ContentRegistration, then send the result of the operation (e.g. successful or failed) in a RELOAD message "StoreReqAns" to TrackerA through Tracker Overlay. Xiao Expires April 21, 2011 [Page 7] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 (connection) (overlay) (swarm) PPSP Peer TrackerA TrackerX TrackerB -------------------------------------------------------------- --JOIN-> --StoreReq-> --StoreReq-> <-StoreReqAns-- <-StoreReqAns-- <-SUCCESSFUL(OK) - Figure 2 Content Information Registration and Update If PPSP Peer wishes to update content information, for example, list of chunks it has, it sends a PPSP message "JOIN_CHUNK" to TrackerA, and then TrackerA sends the corresponding RELOAD message to TrackerB to update the detailed chunk-IDs in the Swarm according to the request message. 4. Lookup Content Index (a Swarm) When a PPSP Peer wants to use some streaming service, which means it wants to download some interested contents from the system, it firstly needs to get related Peer List from Tracker Overlay. As the figure has shown below: 1) PPSP Peer wants to watch a video belonging to a swarm with a Swarm-ID, firstly it will send a PPSP message "Find" with the Swarm- ID to Connection TrackerA; 2) If TrackerA isn't responsible for the swarm, it still can map the Swarm-ID into a Node-ID identifying the Tracker Node which stores the Peer List, so TrackerA hashes the Swarm-ID to a Node-ID by some specific P2P algorithm, then sends a RELOAD message "FetchReq" to TrackerB whose ID is the Node-ID; 3) When Swarm TrackerB receives the request (or if TrackerA is responsible for the Peer List of the swarm, TrackerbB=TrackerA), it searches the Peer List of the swarm locally, then send the Peer List Xiao Expires April 21, 2011 [Page 8] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 which is organized by the data structure of PeerList in a RELOAD message "FetchReqAns" to TrackerA through Tracker Overlay; 4) Finally, TrackerA analyses the received PeerList structure, and reconstructs it into a PPSP message "Successful(OK)", then forwards it to the PPSP Peer. (connection) (overlay) (swarm) PPSP Peer TrackerA TrackerX TrackerB -------------------------------------------------------------- --Find-> --FetchReq-> --FetchReq-> <-FetchReqAns-- <-FetchReqAns-- <-SUCCESSFUL(OK)- Figure 3 Content Information Lookup 5. Peer Status Registration, Update and Lookup To fulfill the functions of peer status registration, update and lookup mentioned above, Tracker Node must maintain such resource related to peers: Information about status of peers: The tracker may collect PPSP Peer status and PPSP Peer priorities periodically because they can be used to optimize Peer Lists returned to PPSP Peers; it includes online time, link status, node capability and other streaming parameters, etc. It can be stored in a data structure denoted as PeerStatus. [Open issue]: When a PPSP Peer wishes to submit or update statistic data to Tracker Node to improve system performance, there are different options about which Tracker Node should store the status data for the PPSP Peer we give several options for discussing: o Connection Tracker: PPSP Peer can submit its status to Connection Tracker and Connection Tracker locally record peer status. PPSP Peer sends a request for a particular swarm to Connection Tracker, Connection Tracker connects to Swarm Tracker; then Swarm Tracker will connect to all other Connection Trackers to get the status data of Xiao Expires April 21, 2011 [Page 9] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 PPSP Peers listed in Peer List; finally, it sends Peer List which has already been optimized by the status of PPSP Peer to PPSP Peer through Connection Tracker. This method will lead to high signaling cost between Swarm Trackers and Connection Trackers, and how Swarm Tracker knows about the address of Connection Tracker for a particular Peer ID is a problem. o Swarm Tracker: PPSP peer register its status to Connection Tracker and Connection Tracker will find out which swarms the peer joins and then store the peer status onto these Swarm Trackers. PPSP Peer sends a request for a particular swarm to Connection Tracker, Connection Tracker connects to Swarm Tracker; then Swarm Tracker ranks PPSP Peers of the Peer List according to the locally recorded PPSP Peer status; finally, it sends the Peer List to PPSP Peer through Connection Tracker. This method can save the signaling cost between Swarm Tracker and Connection Trackers, but because a PPSP Peer may join in several swarms, its status may be stored by several Swarm Trackers repetitively, which leads to storage redundancy and data synchronization problem. o Peer Status Tracker: PPSP Peer register its status to Connection Tracker, the Connection Tracker submit its status to Peer Status Tracker. When PPSP Peer wants to get Peer List of some swarm from Tracker Overlay, Connection Tracker can get Peer List from Swarm Tracker and get PPSP Peer status from Peer Status Tracker, and then returns it back to PPSP Peer. The method proposes another peer status overlay besides swarm overlay, it brings more complexity for every Tracker Node, and also leads to high signaling cost between Connection Trackers and Peer Status Trackers. o Every Tracker: Every Tracker Node in Tracker Overlay will store all status of PPSP Peers in the system. PPSP Peer registers its status to the Connection Tracker. Connection Tracker not only records the status, also distributed the status to all other Trackers. PPSP Peer sends a request for a particular swarm to Connection Tracker, Connection Tracker connects to Swarm Tracker through Connection Tracker; then Swarm Tracker returns Peer List to Connection Tracker, Connection Tracker optimizes it according to status data locally recorded; finally, Connection Tracker answers requesting PPSP Peer. In order to provide optimized Peer List that satisfy requesting PPSP Peer's preference, Tracker needs to know not only the status of local PPSP Peers, but also remote PPSP Peers, so Tracker Node must store all PPSP Peers' status locally, which leads to redundancy and data synchronization problem. o PPSP Peer itself: Tracker Overlay can store PPSP Peer status just used to make some basic information record, and more timely status Xiao Expires April 21, 2011 [Page 10] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 information is stored in PPSP Peer itself without involving Tracker Nodes. PPSP Peer gets Peer List of some swarm from Tracker Overlay, then the PPSP Peer connects to other PPSP Peers of Peer List directly to request their current status; finally, by these status data, PPSP Peer decides which one it should get streaming resources from. This method obviously alleviates storage and signaling cost of Tracker Overlay, but oppositely increases signaling load of PPSP Peers. Suggestion is to leave the choice to implementation. And, we add Status Exchange in Peer protocol. So that no matter which one the implementation choose, the PPSP can work. 6. Kind Definition 6.1. CONTENT-REGISTRATION Kind Definition This section defines the CONTENT-REGISTRATION kind. o Name: CONTENT-REGISTRATION o Kind IDs: The Resource Name for the CONTENT-REGISTRATION Kind-ID is Swarm Name. The data stored is a CONTENT-REGISTRATION, which contains a identification of the swarm, a name of the content, and a list of PPSP Peer-IDs with or not a list of chunk-IDs for each PPSP Peer to show which chunks the PPSP Peer has. o Data Model: The data model for the CONTENT-REGISTRATION Kind-ID is dictionary. The dictionary key is the Swarm-ID of the peer action as focus. o Access Control: USER-NODE-MATCH. 6.2. PEER-STATUS Kind Definition 7. Open Issues Presently, the approach used is essentially a "cache-like" approach. The local connection tracker is consulted, and if the information is not available, the overlay is instead consulted. It is possible an approach where all messages are immediately referred to the overlay (in other-words, where each tracker behaves as essentially a super- peer) would be preferred in a data-center deployment or other Xiao Expires April 21, 2011 [Page 11] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 situation where there is ample connectivity between trackers. We have not addressed this at this time. 8. Security Considerations This document does not currently introduce security considerations. 9. IANA Considerations This document does not specify IANA considerations. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Xiao Expires April 21, 2011 [Page 12] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 References 10.1. Normative References [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] [I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Avila, V., Williams, C., and L. Xiao, "P2P Streaming Protocol (PPSP) Requirements", draft-ietf-ppsp-reqs-00 (work in progress), October 2010. [3] [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", draft-ietf-ppsp-problem-statement- 00 (work in progress), October 2010. [4] [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-11 (work in progress), October 2010. [5] [I-D.gu-ppsp-tracker-protocol] Yingjie, G., Bryan, D., Zhang, Y., and H. liao, "Tracker Protocol", draft-gu-ppsp-tracker- protocol-01 (work in progress), July 2010. 10.2. Informative References Xiao Expires April 21, 2011 [Page 13] Internet-Draft P2P Traffic Localization by Alias Tracker February 2011 Author's Addresses Lin Xiao Nokia Siemens Networks No.14 Jiuxianqiao Road Beijing, 100016 P.R.China Phone: +86-13810361287 Email: lin.xiao@nsn.com David A. Bryan Cogent Force, LLC / Huawei Email: dbryan@ethernot.org Yingjie Gu Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210012 P.R.China Phone: +86-25-56624760 Email: guyingjie@huawei.com Xuan Tai China Mobile/BUPT Phone: +86-13581762082 Email: taixuanyueshi@gmail.com Xiao Expires April 21, 2011 [Page 14]