SocialStreaming: Rethinking P2P Video Delivery through the Lens of Social Graphs

TL;DR

SocialStreaming is a P2P-assisted framework designed to offload massive video traffic from social network servers (like Facebook). By combining Random Network Coding, Metropolis-Hastings distribution algorithms, and social-aware neighbor selection, it reduces server bandwidth costs by over 60% while maintaining high delivery performance.

Background: The Scalability Wall

Social media platforms are effectively becoming video platforms. However, the backbone of these services often relies on traditional Client/Server (C/S) architectures. As user numbers grow, the cost of bandwidth and storage scales linearly—or worse—creating a financial and technical bottleneck. While P2P (Peer-to-Peer) technology offers a solution by letting users serve each other, "vanilla" P2P fails to capitalize on the rich metadata available in social networks, such as who is friends with whom and what their shared interests are.

The Core Innovations

1. Network Coding for Storage Diversity

In traditional P2P, a peer stores an entire segment. SocialStreaming uses Random Network Coding (RNC).

• The Insight: Instead of storing one full segment, a peer stores small, encoded "blocks" from many different segments.
• Result: This significantly increases Segment Diversity across the network. A peer is more likely to have "something" useful for its neighbors, facilitating more frequent P2P exchanges and fewer "misses" that require server intervention.

Fig 1: By storing only fractions (f) of encoded data, peers can hold parts of more segments, increasing global availability.

2. Proactive Predelivery via Metropolis-Hastings

How do you know which peer will watch a video next? SocialStreaming doesn't guess; it uses a distributed biased random walk.

• The Mechanism: When a video is uploaded, the system initiates "walkers" that move through the social graph.
• The Math: Using the Metropolis-Hastings algorithm, the transition probability is biased toward peers who have a history of watching content from that specific uploader.
• Algorithm Goal: To converge the distribution of predelivered content to the actual future demand distribution without a centralized controller.

3. Social-Aware Neighbor Selection

Traditional P2P chooses neighbors based on throughput or proximity. SocialStreaming uses an evaluation function $E$: $E_q=(1-\alpha -\beta )\cdot D(q)+\alpha \cdot I(p,q)+\beta \cdot R(p,q)$

• $D(q)$: Network Performance (Bandwidth).
• $I(p,q)$: Interest Correlation (Cosine similarity of interest profiles).
• $R(p,q)$: Friendship (Binary social link).

This ensures that your "neighbors" in the P2P swarm are not just fast, but are likely to be watching similar content and are socially connected, which typically leads to more stable connections.

Experimental Validation

The authors tested the system against a standard Client/Server model and a standard Peer-Assisted VoD (PA-VoD) system using Facebook trace data.

Fig 2: Server bandwidth consumption is drastically reduced; at 2,000 peers, SocialStreaming requires only 38% of the bandwidth needed by a C/S system.

Key Findings:

• Scalability: Unlike PA-VoD, where the percentage of peer-assisted downloads stays flat, SocialStreaming improves as the network grows. More users mean better data diversity and more efficient "pre-caching."
• Accuracy: The predelivery accuracy remains stable and high, proving that social behavior is a reliable predictor for content distribution.

Critical Analysis & Conclusion

SocialStreaming proves that context is king. By treating the social graph as a routing and caching map rather than just a UI feature, the authors solved the scalability bottleneck of social video.

Limitations: The current model assumes peers are willing to contribute storage (incentive alignment). While social "friendship" is used for selection, a robust incentive mechanism (like Tit-for-Tat) would be needed in a real-world deployment to prevent "free-riding."

Future Work: Integrating this with modern Edge Computing could further reduce latency by placing the "initial" predelivery seeds at the network edge rather than just on peer devices.