Subject: [ppsp] Thoughts on "P2P Streaming" Problem Statement

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 9 Dec 2008 14:55:03 +0100

Hi,
I'm late to the party but here go some thoughts (considering video the
most bandwidth-hungry application).

For technological as well as commercial reasons, video streaming has
been a very active research topic as of lately. Specially live
streaming, with its additional real-time constraints has been a very
challenging topic, for a number of reasons.
First, video streaming, if it is to compete with classical TV
broadcasting, has to scale to very large audiences (Req- large scale:
hundreds of thousands of users).

In spite of tremendous advances in video compression and coding, an
average quality, fullscreen video stream needs
anwhere from 512 Kbps to 2 Mbps as a minimum; much more if it is HDTV
quality (Req: performance demanding: 1,5 Mbps for TV quality; 300 kbps
– 450 kbps achievable today). Given the lack of support for native
multicast in IP networks, and particularly in the Internet, bandwidth
consumption at the source for unicast distribution becomes
prohibitive.

Second, managing large numbers of dynamically joining and leaving
customers, specially if some form of video relaying or forwarding for
bandwidth saving is employed, implies a tremendous management burden
and potentially impacts severely the quality of experience. Although
buffering can alleviate the problem, its use in live streaming is
necessarily very restricted (Req- real-time
uninterrupted video with limited buffering)

Third, as a side effect of the impact of churn, zapping (which implies
unsubscribing from a certain channel and subscribing to another one)
is very slow. The management burden associated with it and the
initialization of the system for the new channel all bring zapping
speed down to anywhere from several seconds to several tens of seconds
(Req- gracefully degradable quality to accommodate bandwidth
heterogeneity and dynamics: different access speeds, churn)

Last but not least, the perceived quality of video streaming over the
Internet is still poor, with chunky video and even loss of continuity.
Although this might be a worthy price to pay for free TV, especially
when accessing content unavailable otherwise, it is certainly not ripe
for mass commercial deployment.

Peer-to-peer technology has been proposed to solve many of those
problems. By using the video consumers as also relay elements, the
bandwidth consumption at the source can be drastically reduced and the
scalability of the architecture improved: With every new viewer
contributing its upload bandwidth to the overall system, the capacity
of the network actually grows with the number of users, which is a
requirement for large audiences. Besides, users can be somewhat
protected from the effect of churn, provided that
every viewer can contact more than one relaying station
simultaneously. Should one of the stations change to another channel,
the total download bandwidth will decrease momentarily, but not be cut
out altogether. However, P2P does not solve the issue of the long
startup and zapping delays, and can actually even make it worse. Since
the stream now comes to a viewer after traversing a
number of relaying stations, additional delay is introduced.
Furthermore, a number of additional problems appear in the
P2P context. Assuming that a number of relay stations exist, an
algorithm is needed to decide from which of them to (simultaneously
and cooperatively) download the video, and also which parts of the
video to download from every one of them. The reverse is also true:
Since upload bandwidth is typically scarce in ADSL environments, an
algorithm is also needed to decide to whom to stream the solicited
video pieces, if more requests arrive than can be accepted. All in
all, P2P live streaming solutions generally also present
high management complexity and burden in order to keep the information
about sources, channels, videos, relays, etc. updated and distributed
among the participating nodes. Nevertheless, P2P technology is a very
promising avenue, which is producing a number of breakthroughs in live
streaming. But to date, all the proposed architectures have failed to
address the issue of true integration with standard protocols. P2P
streaming architectures to date resort to proprietary protocols for
overlay management and in some cases, also for the management of video
sessions. IMHO it is a bad idea for one main reason: video streaming
in the Internet
based on standard multimedia distribution and management protocols
opens the door to a new dimension of converged
multimedia services. Although many platforms exist for concurrent text
and audio interchange, which even support videoconferencing,
they remain isolated communication devices. They lack so far the
integration with other web-based services and ways of expression like
blogs, social communities, etc. and also with non-interactive media
distribution, like, precisely, video broadcasting, Internet radio,
etc.

The key idea here is to transform users into media relays increasing
hence the overall capacity with the number of users. IMHO there exist
two main approaches: Tree-based and Data-driven.

+ Tree-based solutions are basically push-based solutions:
- Data automatically forwarded to children
- Almost negligible delay in relaying
- Need a lot of management in the face of churn (reassign parents)
- Bandwidth is underutilized (leaves do not contribute to the system).
A possible solution: Multi-trees (every user is both leaf and node in
different trees).

Data-driven solutions can be considered either push or pull based solutions:
+ No definite structure is maintained

+ Use gossip protocols to distribute data (push based)
- Data spreads like a virus
- Resilient against churn
- Decentralized
- Highly inefficient and redundant use of bandwidth

+Alternative: Pull-based solutions
- Exchange chunk availability with (random) partners
- Choose from whom to download
- Redundancy is avoided while resilient to churn
- High additional delay

draft-zhang-ppsp-problem-statement-01 states: "The basic mission of
PPSP is to create a distributed real-time data retrieval protocol in
one to many communication (or data-driven communication)."

Data driven communication implies higher algorithmic complexity and
requires answering the following questions (feel free to complete the
list):
- How to choose from whom to download? (Also in the presence of churn)
- How to choose what to download from each? (Scheduling problem is
NP-hard; Avoid holes and meet playback deadlines)
- How to choose to whom to upload/relay? (Uplink capacity is scarce in ADSL)
- How to discover other peers that have the information you want?
(General problem in P2P systems)
- How to (efficiently) interchange data availability? (Delay vs
overhead trade-off)
- How to cope with heterogeneity?

My two cents,
-- 
Victor Pascual Ávila
_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp