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.