Resilient Peer-to-Peer Streaming (CoopNet)
This webpage documents my presentation of "Resilient Peer-to-Peer
Streaming" by V.N. Padmanabhan, H.J. Wang, P.A. Chou for CPSC 538A:
Topics in Time-sensitive Distributed Systems, taught by Charles 'Buck'
Krasic.
Quick Links
Summary
CoopNet is a novel application-level multicast system that targets video
streaming over the Internet. The motivation for the work is the 'Flash
Crowd' scenario: where demand for popular streaming content causes the
streaming server to become unreachable due to limited bandwidth. The
authors choose a Peer-to-Peer (P2P) approach to distributing content as
opposed to IP multicast or an infrastructure based Content Distribution
Network because the P2P approach is self-scaling with respect to bandwidth
and it does not require any new infrastructure. The main disadvantage to
using a P2P approach is that it is hard to provide delivery guarantees
because peer failures, departures, and disconnections are common.
CoopNet aims to become resilient to the transience of peers by ultilizing
redundency in network paths and redundency in data. To acheive this, the
CoopNet protocol anchors itself at a central server that manages
multiple distribution trees of peers. The server also encodes
data using multiple description coding to provide redundency in data.
The MDC encoded data is then distributed to clients using the different
distribution trees. A key feature of the system is
that nodes only participate in the distribution of a video stream
data that they are currently watching.
The key contributions of this paper are:
- A centralized deterministic distribution tree management algorithm
that can be used to build and maintain a set of distribution trees that
are: diverse, short, and efficient
- A framework for adapting MDC based on receiver feedback. The
feedback is gathered using a scalable protocol where packet loss rate
histograms for each node filter up the distribution trees until they
reach the root (ie. the server). The server then uses this
information to adapt the MDC encoding process.
- An evaluation of the system carried out on a simulator using the
access logs from the MSNBC streaming server from Sep 11, 2001. The
results
of the evaluation show that the CoopNet approach generally improves the
peak signal-to-noise ratio (PSNR) of the received video stream. The
results also show that MDC outperforms pure Forward Error Correction
(FEC) when dealing with a wide variation in loss rates across clients
(as is the case for most Peer-to-Peer systems).
Presentation Slides
The slides for my presentation (in pdf format) can be found
here.
Group Discussion
Questions about the paper:
- Clarification of the node join/leave protocol. To join, nodes
contact the server requesting a parent. The parent chooses a parent for
the new node using the deterministic algorithm and notifies the new node.
The new node then contacts its assigned parent and the parent accepts
the child. Buck pointed out that the server could contact both
the parent and the child (instead of the child only). The main
disadvantage of this approach is that it requires the server to do more
work (ie. sending two messages instead of one).
- Graceful vs. ungraceful leaving of nodes in CoopNet. When a parent
leaves gracefully, it contacts the server, telling it to find a new
parent
for each of its child nodes. When a parent leaves ungracefully, its
children notice its absence by monitoring their own incoming packet loss
rate. The children are then responsible for contacting the server and
requesting a new parent. It should be noted that this mechanism can
also be used to deal with unacceptably high packet loss rates during
normal operation (ie. no join/leave of the parent, just a bad connection
between parent and child).
- The tree manager living at the server uses global knowlege of the
participating nodes to maintain the distribution trees.
- Location (determined using GeoPing coordinates)
- Available bandwidth (as advertised by the client)
- Packet loss distribution (as monitored by the client)
These three pieces of information are used to build distribution trees
with desirable
shortness and diversity to acheive robustness; efficiency is a secondary
goal. The packet loss distribution is also used to tweak the
encoding parameters for MDC. For example, to adapt the amount of
redundency introduced by the MDC encoder. High quality links need
less protection from failure (less redundency), while lower quality
links need more protection from failure (more redundency). This makes
more effective use of the available bandwidth.
Discussion of future work:
The authors state that they would like to develope a framework for
congestion control in the future. Essentially, they would like to build
on top of the work they have done already, where each node monitors the
condition of its incoming link, and if the packet loss rate becomes too
great, the child contacts the server so that the problems can be resolved.
What steps do we se e being made in
in their future work? What should they be careful of?
- Must take care to decide when congestion occurs, because by taking
action to correct suspected congestion by finding another parent node
you interrupt the flow of data to the node experiencing congestion.
A possible idea that I see the CoopNet team exploring is the use of
historic record of the performance of a nodes incoming link. That is,
instead of each node maintaining information about the current state
of the link, the node will track the links performance over time. Using
this information a node may be able to predict the performance of a link
in the future by looking at its past performance.
- The CoopNet team should take steps to find out how TCP-friendly their
congestion control algorithm is. If the goal of CoopNet is actual
deployment on the Internet, discovering the TCP-friendliness of its
congestion control algorithm has to be
one of the top three areas to be examined. Especially since the target
application for CoopNet is streaming video over the internet.
- CoopNets congestion control mechanism is inspired by Receiver-driven
Layered Multicast (RLM). Currently RLM is having trouble proving
TCP-Friendliness. We expect the CoopNet approach to encounter similar
difficulties.
What about the difference between congestion control for multiple TCP
streams compared to congestion control for multiple mulicast senders?
- It is easier for servers to limit the use of multiple TCP connections
from a single client. Servers simply deny any new connections in excess
of some limit (commonly four connections for a webserver).
- However, even single TCP connections have there own problems. There
are implementations of the TCP stack that cheat to gain more bandwidth
for themselves at the expense of others in the network. An example of
such an
implemenation is TCP Daytona developed at the University of Washington.
It acknowleges data before it receives the data, in effect telling the
server to send more data and not back-off. Such optimistic ACKing is
unfair to
other users of regular TCP implementations that detect the congestion
and back-off appropriately.
Finally, it was noted that there is unused bandwidth when receiving data
sent by CoopNet peers due to the asymetry of peer bandwidth. The
PeerMetric study determined 200kbps upload and 900kbps download on average
for a broadband connection. Thus,
there is 700kbps going unused at the receiver side. A possible area for
further research could be to figure out how to modify CoopNet to
'keep the pipe full' at the receiver side.
Additional References
- [TCP Daytona] Stefan Savage, Neal Cardwell, David Wetherall, Tom Anderson.
TCP Congestion Control with a Misbehaving Receiver.
Computer Communications Review, v 29, no 5, October, 1999
- [SCRIBE] M. Castro, P. Druschel, A-M. Kermarrec, A. Rowstron.
SCRIBE: A Large-scale and Decentralized Application-level Multicast
Infrastructure.
IEE JSAC, 20(8):100-110, October, 2002
- [SplitStream] M. Castro, P. Druschel, A-M. Kermarrec, A. Nandi,
A. Rowstron, A. Singh.
SplitStream: High-bandwidth Content Distribution in a Cooperative
Environment.
In Proc. IPTPS, February, 2003
- [Pastry] A. Rowstron, P. Druschel.
Pastry: Scalable, distributed object location and routing for
large-scale peer-to-peer systems.
IFIP/ACM International Conference on Distributed Systems Platforms
(Middleware), Heidelberg, Germany, pages 329-350, November, 2001
- [MDC] V.K. Goyal.
Multiple Description Codeing: Compression Meets the Network.
IEEE Signal Processing Magazine, pages 74-93, September, 2001
- [Layered MDC] P.A. Chou, H.J. Wang, V.N. Padmanabhan.
Layered Multiple Description Coding.
In Proc. Packet Video Workshop, April, 2003
Links
Daniel Ferstay
Last modified: Tue Feb 3 18:18:43 PST 2004