Peer to Peer Multimedia Streaming - Essay Example

Peer to Peer Multimedia Streaming Using Caching Service In this paper, we propose a peer-to-peer (P2P) multimedia streaming solution thataddresses the problems usually associated with streaming services such as delay issues and poor link quality. The proposed solution is based on inter-overlay optimized topology, in which peers can join multiple overlays simultaneously to improve resource utilization and guarantee link quality. We evaluate our solution along with another P2P topology through simulation. We discuss the results and draw a conclusion at the end of the report. Introduction Multimedia streaming has become an alternative solution to traditional broadcast services such as terrestrial, cable and satellite television. The first solutions developed were based on a client-server architecture, which initially served the purpose. However, the increase in the number of viewers, along with the rise in number of other online applications, has made this architecture ineffective because of bandwidth bottleneck issues. One solution introduced to solve this problem is peer to peer (P2P) technology, wherein peers automatically relay streams to other peers. The P2P network they are connected to performs an algorithm that help peers nd a relay for a specied stream to connect to. In multimedia streaming service, the important factors to observe are playing time and network bandwidth utilization. The purpose of this report is to present a solution to these issues. The proposal is to utilize P2P caching service that exploits the proximity of connected clients, i.e. the temporal and spatial locality of cached streams to the clients. In this scheme, connected peer clients not only receive multimedia streams from a server, but also send cached streams to peer clients like a proxy server upon request. One P2P technology that can support this architecture is called inter-overlay optimization. Different Approaches in Multimedia Streaming Figure 1 shows the different approaches employed in multimedia streaming starting from the centralized client-server topology to decentralized schemes, which includes IP multicast and P2P solutions. P2P can be further sub-divided into mesh-based, tree-based and hybrid overlays. Mesh-based: Each peer can accept media data from multiple parents as well as provide services to multiple children (both parent and child are relative terms in place of master-slave relationship). The advantages of this solution are: high resource utilization and fast discovery of fresh peers in a single mesh due to gossiping. The disadvantages are: quality of service cannot be guaranteed due to gossiping among peers and large buffer space needed to reduce impact of autonomy of peers (in a dynamic environment). Example applications are Coolstreaming, Promise and GNUStream. Tree-based: Each peer communicates only with one parent (per overlay) and provides service to a number of children such that a "tree" topology is always maintained (in an overlay). The advantages of this solution are: closely resembles original IP multicast ideas and low management overhead. The disadvantages are: highly vulnerable to disruption under dynamic environments and low resource utilization. Example applications are ALMI, NICE and ZigZag (single tree protocol) and SplitStream, Bullet and MDC (multiple tree protocol). Figure 1. Multimedia Streaming Topologies Proposed Solution There were lots of research done in designing efficient streaming overlay multicast scheme based on P2P networks [1], where connected viewers act as routers for other users. Different from traditional IP multicast systems, streaming overlays concentrates on the following issues: start-up delay, source-to-end delay and playback continuity. These metrics are very important to the user because large start-up delays would exhaust user patience and streaming interruptions would spoil viewing experience. In order to improve the above-mentioned metrics, studies were done on intra-overlay optimization [2], in which each node joins at most one overlay. Figure 2 shows an example of intra-overlay optimization with two logical streaming overlays. Peers A, B, C and D join the stream originating from S1 and peers E, F, G, H and K join the stream originating from S2. The number on each edge of the links represents the cost of the link between two nodes. Take note that these are relative values and were used only to compare link costs. In typical intra- overlay optimization schemes, two multicast topologies can be established as shown in Fig. 2 (a) and (b). Looking at peer D in Fig. 1(a), the cost of S1 to D link is 8, while that for path S1 to S2 to D is only 4. Cost efficiency can be achieved but resource utilization of traditional approaches such as this is relatively low. Figure 2. Intra-overlay Optimization Scheme In our solution, we propose an inter-overlay optimization based scheme, in which resources can join multiple overlays simultaneously [3]. The objective is to (1) improve global resource utilization of a live streaming network and then distribute traffic to all physical links evenly; (2) assign resources based on the peers' locality and delay; (3) guarantee link quality by using the nearest peers, even if they belong to different overlays; and (4) balance the load among members within the group. Figure 3 shows the inter-overlay optimization scheme. Figure 3. Inter-overlay Optimization Scheme The basic workflow of our solution is shown in Fig. 4. The first step is to create an efficient mesh-based overlay manager. A location detector based algorithm is utilized to match the overlay with the underlying physical topology [4]. This is complemented by a single overlay manager, which is based on traditional intra- overlay optimization and deals with the join/leave operations of peers. The third component is the inter-overlay optimization manager that explores appropriate paths, builds backup links, and cuts off paths with low quality service. The fourth is the key node manager that is used to allocate limited network resources. The last but not the least is the buffer manager, which is responsible for the transmission of media data. Figure 4. Inter-overlay Workflow Mesh-based Overlay Manager In our proposed solution, peers join the mesh-based overlay first. Each peer, with a unique ID, first selects one or several peers to establish logical links. With this scheme, every peer maintains a group of logical neighbors. The mesh-based overlay manager uses a number of strategies, such as an LTM (Location- aware Topology Matching) technique [4], to find the latest neighbors and eliminate slow overlay, thus optimizing the established connections. This scheme has two major operations: flooding-based detection with limited TTL, and updating logical connections. In flooding-based detection, each peer periodically floods a message, defined as dm (id, S, TTL), to its neighbor peers. This message means that the peer initiates a message with ID value id in TTL hops. Since the purpose is to find the latest neighbors of peer S, we define TTL=2. To detect the distance of peers, the message body has six parts: message ID, TTL value, source peer IP address, source Timestamp, Direc t IP (the IP address of one neighbor within one hop) and Direct Timestamp (the timestamp when the neighbor within one hop gets the message). Figure 5 shows the roadmap of one message from peer S. A message is broadcast to direct neighbors and also 2-hop away neighbors. In the next step, logical links are updated. Utilizing the timestamps on peers, peer P1 compares the distance between two paths, S to P1 and S to N1 to P1. If the former path is longer, the link N1 to P1 would be dropeed and the direct path between S and P1 would be established. All peers would do the same operations as those of peer S. The effect is after several operations, peers would be connected with their nearest neighbors. Figure 5. Roadmap of detector message initiated by peer S Single Overlay Manager The single overlay manager is responsible for the leaving/joining operations of the connected peers. Before inter-overlay optimization, each peer joins one streaming overlay and then receives media contents from multiple providers or single providers according to intra-overlay optimization schemes. In this scheme, a new attribute called LastDelay is introduced, which is the minimal difference of all source-to-end delays from the current node to the streaming source on different paths. By utilizing LastDelay, each path to the media source is measured and evaluated. When a media block is delivered from the media source to the node, the single overlay manager records the timestamp and writes it into the media block's header. When a peer receives the media block along with the initial timestamp, it computes the difference of the initial timestamp and the arriving timestamp. This minimal difference is called LastDelay and peers can join or leave the overlay according to this value. Inter-overlay Optimization Manager Every connected peer maintains one active streaming path set and one backup path set. Initially, all streaming paths are managed by the single overlay manager. When the number of backup streaming paths is less than a set threshold, the inter-overlay optimization manager finds appropriate streaming paths in the global P2P network with the help of the mesh-based overlay. When one active streaming path is dropped due to its poor link quality or due to a peer leaving the network, a new streaming path is selected from the backup set. In this algorithm, a probing message named ProbM is also included as shown in Fig. 6. This parameter includes two major parts: (1) initial information about the message, including sequence number (Seq.), initial peer ID (Peer_0), message issuance time, (Timestamp0), media source ID of the initial peer (Source), current (LastDelay), and TTL; (2) an array with the size of TTL to record peer ID and the arriving timestamp of the message. The inter-overlay optimization manager has two main tasks - backup streaming path set management and active streaming path set management. Figure 6. Probing Message ProbM Structure Key Node Manager The goal of the key node manager is to determine the number of requests that a peer should have. When there are too many requests, it is of great importance for peers to have an effective admission control policy. Suppose each peer has spare connection slots. According to the characteristics of requests, each request will fall into one set of queues with different priorities and popularities. When we assign the spare connection slots to a set of queues, there are two interesting cases. First, some queues are assigned with more than one connection tunnel and second, some queues only receive one connection. Buffer Manager This manager is responsible for receiving valid media data from multiple providers in the active streaming path set and continuously keeping the media playback. Our solution employs a similar heuristic as used in the Coolstreaming system [5] to fetch expected media segments in a dynamic and heterogeneous network to meet two constraints: the playback deadline for each segment and the heterogeneous streaming bandwidth from partners. Coolstreaming does not employ any inter-overlay optimization so peers often fail to find the closest neighbors to supply services. To keep the media playback continuous, a big buffer must be used. Due to the effectiveness of the inter-overlay optimization scheme we adopted, a smaller buffer space is needed resuting to shorter startup delay. System Diagram Figure 7 shows the system block diagram of our proposed solution. Every end system (including the Broadcaster) is composed of several function modules as follows: (1) getting media data (GMD) module is for Broadcaster; (2) sending peer selection (SPS) module is deployed on all peers except the Broadcaster; (3) session for controlling message (SFCM) module is responsible for exchanging control messages between current peer and its supplier, and monitoring actions of child peers; (4) buffer manager (BM) module gets media packets from the upper-layer, sends them to the HTTP server module, and deletes packets with outdated timestamps in the buffer; (5) data transmitter (DT) module fetches media packets from the buffer, and transmits packets to underlying peers under flow control policy; (6) HTTP server (HS) module creates a virtual HTTP service at a local machine. After retrieving media data packets from the buffer, HS module sends them to media players such as Windows Media Player, under the HTTP protocol. Figure 7. System Diagram of Proposed Solution Simulation Parameters We consider two types of topologies, physical topology and logical P2P topology. The physical topology represents a real topology with Internet characteristics. The logical topology represents the overlay P2P topology built on top of the physical topology. All P2P nodes are in a subset of nodes in the physical topology. The communication cost between two logical neighbors is calculated based on the shortest physical path between this pair of nodes. For the simulation, we run tests for our proposed solution and another application called Coolstreaming. We used a crawler based on Gnutella protocol [6] and the source codes are rewritten from Limewire open source client [7]. The crawler's main function is to probe the connections of Gnutella peers. When peers are receiving crawler ping messages, they reply with corresponding pong messages. Utilizing forty-five independent threads, our crawler discovers over fifty thousands peers and their connections in one week. In this simulation we use three data sets, obtained from different time slots. Each trace includes around 2,000 peering nodes. For the physical topology, we use BRITE [8] generating three topologies, each with 5,000 nodes. The average number of neighbors of each node ranges from 4 to 10. The major parameters in our simulations are listed in Table 1. In each run, peers randomly join one of S streaming overlays (S=1, 4, 8, 12). Each peer randomly has C connections ranging from 4 (1 Mbps bandwidth) to 40 (10 Mbps bandwidth) and maintains at least M neighbors. The size of each overlay is N (N Read More