draft-ppsp-download

Downloading Data From The Remote P2P Streaming System
   draft-tong-ppsp-download-01

Abstract

   This draft has proposed a scheme trying to provide an uniform interface for
   the client to get the streaming no matter whether the streaming exists in
   the client's local P2P overlay or in the other P2P overlay. We concerns
   about how the client gets the content data from a different proprietary
   P2P streaming system.

Table of Contents

   1. Introduction
   2. Overview of the Scheme
     2.1 The Advance Preparations
   3. Communication Between Peer and Tracker
     3.1 Publish the Content
       3.1.1 Message Structure
       3.1.2 Response and Reply
     3.2 Refresh the Content Availability
       3.2.1 Message Structure
       3.2.2 Response and Reply
     3.3 Request for the Content
       3.3.1 Message Structure
       3.3.2 Response and Reply
   4. Communication Between Peer and Peer In Different P2P Overlay
   5. Open Issues
   6. Informative Refences
   Authors' Addresses

1. Introduction

   As there is no uniform interface for a proprietary P2P streaming system
   to interview another different one, there is greate waste of the bandwidth
   and computer etc. resources as the proprietary P2P streaming systems have
   to publish and store the content resources dependently. So it's meaningful
   and necessary to unify the interfaces of interviewing the content resources
   , then we can integrating P2P streaming as an integral component of a
   global content delivery infrastructure.
 
   Considering using the file system to interview the content locally, we propose a
   scheme which can make the clients get the content resources easily between
   different proprietary P2P steaming systems. We can consider getting the
   content from the P2P overlay as getting a "file" from a special "disk".
   To provide the uniform interfaces for clients to get the content resource
   from the different proprietary P2P streaming systems, we have to
   construct a virtual file system in a proprietary streaming system and
   define the messages of communications between the independent content systems
   in different proprietary streaming systems.

   The live streaming and the VOD streaming in the P2P system can be both
   considered as special files. The content provider of the live streaming
   and the VOD streaming can be considered as a peer which has stored the
   content in the P2P overlay network. In the following, every propreitary
   P2P streaming system gives the content a unique content ID in its overlay
   networks.

2. Overview of the Scheme
         
   We can consider this scheme as a new way of serveicing the clients, it makes
   clents access the content in a stable way. In our operating system, we access the
   local files by giving some parameters including the file path and the offset
   to the file system. So in this scheme, clents can access the content by giving the
   the content name and the offset to the tracker which is reponsible for the
   proprietary P2P streaming system. And the tracker can access the content in another
   proprietary P2P streaming system by passing the parameter to the tracker which locates
   in another p2p streaming system. We can easily access the contents between
   different P2P streaming system.

   [1] defines the main signaling flows between the peer and the tracker. The
   scheme is proposed as supplements for that protocol which emphasizes the
   communication between the peer and the tracker while the content isn't in the
   local proprietary P2P streaming system.

2.1The Advance Preparations
  
   The scheme which we have proposed bases on some advance preparations. And some
   terminology and concepts have been descripted in the former drafts. The most
   important condition is that while you want to access a content in another proprietary
   P2P streaming system, the communication will be established first between
   the different trackers before the data transmission. That means there will be
   messages exchanging between the tracks to enable clients to access the content from
   another proprietary.
  

                +-----------+                              +----------+
                |               |Message Exchange |              |
                | Tracker1 |<----------------->     |Tracker2 |
                |               |                               |               |
                +-----------+                              +-----------+
                     ^                                              ^
                     |                                                |
         Tracker |                                Tracker    |
        Protocol |                                 Protocol |
                     |                                                |
                     |                                                |
                     |                                                |
                     |                                                |
                     |                                                |
                     |                                                |
                     |                                                |
                     v                                                v
                +----------+                                +----------+
                |              |   Data Transmission |               |
                |   Peer1  |<----------------------->|   Peer2  |
                |              |                                  |             | 
                +----------+                                 +----------+
                Figure 1 : The Message Exchanging Between the Trackers

   In Figure 1, we suppose that peer1 want to get a content which is only stored on
   peer2 and the two peers are in different proprietary P2P streaming systems.
   The peer1 first send the request to Tracker1 by using the Tracker Protocal,
   the tracker1 first search the requested content on the local P2P overlay networks.
   Then it fails, the tracker1 will search the requested content on another
   proprietary by communicating with tracker2. Then tracker2 returns the
   content infomation and the peer2 information to tracker1. The peer1 can get
   enough information to access the content on the peer2. The tracker2 can treat
   tracker1 as a peer on its overlay.

   We can implement this scheme in different structures only if they have their
   trackers. And before communicating with the other trackers, the track itself
   must prepare something first.
  
   (1)Name mapping table. Maybe there is no uniform namingspace for the different
   proprietary P2P system, so there will be different content identification for
   the same content. If a tracker want to search a content in another P2P system, it
   MUST get the content identification of the other P2P system. So in the tracker, we
   first have to store a name mapping table in which we can easily find the content
   corresponding identification in another P2P system. The name mapping table
   contains the content ID in the other P2P systems. However how to construct
   name mapping tables is an open issue which we will descript afterwards.   
  
   (2)Chunk information. As different proprietary P2P streaming systems may have
   the different statistics to split the content into chunks including whether
   split the content by size or duration, the size or time length of the chunk etc.
   As the tracker has these information, it can easily transfer the offset of
   the content into the chunk ID without thinking about the different chunk statistics.
  
   (3)Information of the content. The tracker at least has the information of content
   size and the owner of the content if the content exists in the P2P streaming system
   which the tracker belongs to. At current, we don't care about the legality
   of accessing the content. The tracker just use these information to convert the
   offset of the content to the chunk ID with the help of the chunk information.
  
   After the above information prepared, the traker of the P2P streaming system can
   search the content in the local overlay and in the other overlay if needed, and
   convert the offset to the chunk ID to enable the clients access the file througth
   the uniform interface.
 
3.Communication Between Peer and Tracker
  
   In this section, we define the corresponding messages between the peer and tracker
   by using the scheme above. In the following, we descript the messages including
   publish the content, refresh the status, request the content and the reply of the
   tracker to the peer. And we also descript the actions of the tracker while the
   message is received from the client.

3.1Publish the Content
  
   After registered in the P2P streaming system, the client can publish its local
   content to the P2P overlay network by sending the publish message to the tracker.
   Of course, the client SHOULD have enough bandwidth and other resources to upload
   the content for servering the other clients. Some P2P systems first store the
   contents on their own servers. Here we don't consider the constrains on the client.

3.1.1Message Structure

     +------------------------------------------------------------------------------------+      
     | Content ID | Owner Info | Chunk_type | Chunk Info | Content Info |
     +------------------------------------------------------------------------------------+
    
             Figure 2 : Basic Structure of the publish message

   Figure 2 shows the basic structure of the publish message which is sended
   by the client to publish its local contents. Content ID means the identification
   of the content in the P2P streaming system, and it can be considered as the
   unique identification in the system. Owner Info contains the information of the
   content owner including the owner's ip address etc., so the other clients can
   access the content through the information of the owner. Chunk_type points out
   that the file is split by size or duration etc. And the Chunk Info will explain
   the details of every chunk including the numbers. Content Info contains some
   other properties of the content and may include the type of the content and
   the other clients' authority information.
  
3.1.2Response and Reply
  
   While the tracker receive the clent's publish message, it will divide the
   information contained in the message and store them. The tracker will store
   the content ID for searching. The chunk_type and chunk Info will be stored
   as the chunk information of the content. And after that, the tracker will
   return OK to the client.

3.2Refresh the Content Availability
 
   The peer have to refresh the status information which is stored in the tracker.
   The information includes the latest chunk information, link status, node capablity
   and other steaming parameters. Here we emphasize the content availability.
   And we can use bitmap indication which chunks a peer possesses.

3.2.1Message Structure
  
                 +----------------------------------+      
                 | Content ID | Chunk Bitmap |
                 +----------------------------------+
    
     Figure 3: Basic structure of the refresh chunks message

   Figure 3 shows that the basic structure of the refresh chunks meesage mainly
   contains the content ID and the chunk bitmap of the peer. While the chunk information
   of the peer changes the peer will send this message to the tracker to refresh
   its chunk information. Here we don't think about whether the peer will
   refresh the chunk information on the peers which is dowloading the content
   chunk from it.      
       
3.2.2Response and Reply
 
   When the tracker has received the refresh chunks message from the peer, it will
   refresh the corresponding information stored loally.

3.3Request for the Content
 
  Before the peer begin to access the content, the peer will first send the content
  request message to the tracker which is reponsible for the proprietary P2P streaming
  system. The tracker will search the content locally and may commnunication with
  other trackers if needed.

3.3.1Message Structure
 
                 +-------------------------------------------------------+      
                 | Content ID | Request Type | Request Offset |
                 +-------------------------------------------------------+

             Figure 4: Basic Structure of content request message

  Figure 4 shows the basic structure of the request for the content message.
  It contains the content ID, the request type and the request offset. The request
  offset enables the peers access the content as the same as accessing a file
  in the file system. In some proprietary P2P streaming system, the tracker may
  check the client's authority of accessing the requested content first before
  handling the request message. We can add these information to the message,
  but how to check the authority is still an open issue.
 
  The request type in the message explains whether the request is from a tracker or
  not. When a tracker for example tracker1 in Figure1 fails to search the content
  locally and searches the content in the name mapping table successfully, tracker1
  will send request message to the tracker2. We can change the request type to tell
  the tracker whether the message is from a peer or a tracker.  
   
3.3.2Response and Reply
 
  After receiving the content request message, the tracker server will first
  searching the content locally by using the unique identification of the content.
  If there is no peer storing the requested content, the tracker will search the
  content in the name mapping table.
  
  +-------------------------------------------------------------------------------------------------+      
  | Request Content ID |  Reply Content ID  | Reply Type | Chunk Info | Peer List |
  +-------------------------------------------------------------------------------------------------+

        Figure 5: Basic Structure of reply message of the content request
  
  Figure 5 shows the basic structure of reply message of the content request. The
  request content ID is the same as contained in the content request message. Because
  the request message has two types, there are also corressponding two types of
  reply message.

  One type is for the request from a peer. When the request message is from a peer,
  the reply content ID is as same as the request content ID. The peers in the peer
  list are the peers which located in the same proprietary P2P streaming overlay.
  The other type is for the request from a tracker. Before sending this message,
  the tracker has searched the content successfully in the name mapping table.
  The reply content ID is the ID of the same content in another proprietary P2P
  steaming system which the tracker sends the request to. The tracker will send
  the content request message to another tracker. After receiving the peer list
  from another tracker, the tracker will return the reply message to the peer. As the
  content ID for the same content is different in different proprietary P2P
  streaming systems, the tracker first gets the content ID of another P2P streaming
  system in the name mapping table and writes it as the content ID in the request
  message to another tracker.

  As the different contents may have different strategies to split the whole content
  into chunks in the same P2P sytem and the same content in different proprietary
  P2P systems may have different chunk information, it's important to return the
  chunk information to the peer which sends the request.
  
4. Communication Between Peer and Peer In Different P2P Overlay
  
  [2] has defined the architecture of the P2P system, requirements for the PPSP peer
  protocol and the corresponding open issues. This scheme concerns how to get the
  content from another proprietary P2P system to achieve the goal which desripted
  in [3]. While a peer is communicating with another peer located in another
  proprietary P2P streaming system, because of the different content ID for the
  same content they SHOULD know the ID of the same content in the other P2P systems
  first.
 
  No matter the content is stored in the local P2P overlay or in another one, the
  requesting peer can access the content after receiving the reply for its content
  request from the track. The requesting peer converts the offset into the chunk
  ID and then communicates with the peers.  
     
5. Open Issues
 
  1. How to form and refresh the name mapping table stroed in the tracker. It's
  hard to decide the way of judging whether the content is the same as the local one
  although their content ID are different. One way is to hash the content first, and
  the compare the hash of the two contents to decide whether thry are the same or
  not. But for the live streaming, the content is changing over time and we can't
  compute the hash of the content. Maybe we can use the some properties of the
  content.

  2. While the downloading speed is too slow for the requesting peer, whether it
  can choose the peers located in other proprietary P2P streaiming systems to get the 
  data. Sometimes a content is just stored in one peer in the P2P overlay, and
  if too many peers try to connect to it, there will cause bottle neck and the
  performance slows down. Maybe we can let some requesting peer to connect other
  peers in other P2P overlay.
 
  3. We can access the content by passing the enough parameters, so we can contruct
  a simple file system above the uniform interfaces to enable different file
  systems to access this simple file system.

6.Informative References

  [1] 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.

  [2] Yingjie, G., Bryan, D.,"Peer Protocol",
      draft-gu-ppsp-peer-protocol-01(work in progress),
      October 2010.

  [3] 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] Yingjie, G., Bryan, D., Zhang, Y., and H. liao, "Tracker
      Protocol", draft-gu-ppsp-tracker-protocol-02 (work in
      progress), October 2010.