CollectCast: A peer-to-peer service for media streaming

Abstract

We present CollectCast, a peer-to-peer (P2P) service for media streaming where a receiver peer is served by multiple sender peers. CollectCast operates at the application level but infers underlying network properties to correlate end-to-end connections between peers. The salient features of CollectCast include: (1) a novel multisender selection method that exploits the performance correlation and dependency among connections between different candidate senders and the receiver, (2) a customization of network tomography techniques and demonstration of improved practicality and efficiency, and (3) an aggregation-based P2P streaming mechanism that sustains receiver-side quality in the presence of sender/network dynamics and degradation. We have performed both real-world (on PlanetLab) and simulation evaluation of CollectCast. Our simulation results show that for a receiver, CollectCast makes better selection of multiple senders than other methods that do not infer underlying network properties. Our PlanetLab experiments are performed using a P2P media streaming application (called PROMISE) which we developed on top of CollectCast. Both packet-level and frame-level performance of MPEG-4 video streaming demonstrates the practicality and effectiveness of CollectCast.

Decentralized media streaming infrastructure (DeMSI): An adaptive and high-performance peer-to-peer content delivery network

“…The concept was probably originated about 3 years ago as Calvert et al [13] outlined it in their Concast paper. The subject of aggregated streaming slowly came into research attention such as the works from Nguyen and Zakhor [14], CoopNet by Padmanabhan et al [26], and finally, Hefeeda et al [15] is probably among the first to integrate this concept with the peer-to-peer paradigm with the introduction of CollectCast (also known as PROMISE). The papers [14,15,26] brought out a number of important issues related to aggregated streaming with remarkable solutions.…”

“…The subject of aggregated streaming slowly came into research attention such as the works from Nguyen and Zakhor [14], CoopNet by Padmanabhan et al [26], and finally, Hefeeda et al [15] is probably among the first to integrate this concept with the peer-to-peer paradigm with the introduction of CollectCast (also known as PROMISE). The papers [14,15,26] brought out a number of important issues related to aggregated streaming with remarkable solutions. For example, the Nguyen group proposed the use of forward error correction (FEC) in their aggregated streaming architecture such that the receiver can recover the original stream by receiving any n of n FEC :n FEC > n FEC encoded packets [14], as long as the number of lost packets during the transmission does not exceed n FEC À n. The solution neatly avoids the need of lost packets re-transmission that imposes delay and control overhead.…”

“…For example, the Nguyen group proposed the use of forward error correction (FEC) in their aggregated streaming architecture such that the receiver can recover the original stream by receiving any n of n FEC :n FEC > n FEC encoded packets [14], as long as the number of lost packets during the transmission does not exceed n FEC À n. The solution neatly avoids the need of lost packets re-transmission that imposes delay and control overhead. In [15], the Hefeeda group raised the importance of network topology awareness in the selection of candidate peers in the aggregated streaming scenario, in order to avoid having too many active serving peers that deliver the sub-streams through the same link of the network that causes congestion. The Padmanabhan group [26] attempted to support partial content storage in each active serving peer participating in the aggregated streaming in the CoopNet system, by employing MDC on the media content.…”

“…Regular switching of actively serving peers set is required for the duration of a streaming session regardless of peer availability and network condition. In contrast, CollectCast heavily relies on a handful (an average of four as discussed in [15]) of peers. Switching of active peers is inherently less frequent in CollectCast's scenario as it only occurs when the peer becomes unavailable or network condition becomes inferior.…”

“…In order to achieve the goal, DeMSI has to have knowledge about the path of the sub-stream flow from each peer such that the hop-links that shared by two or more sub-stream flows can be identified. Recent works [15,16,21] indicate that the inference of fine-grain knowledge such as network topology takes too much time to converge even for a small network consisted of a few peers. DeMSI has to visit a diverse selection of candidate peers over the course of the streaming due to the decentralized storage of content segments.…”