P2P streaming with LT codes

P2P streaming with LT codes: a
prototype experimentation
Andrea Magnetto, Rossano Gaeta, Marco Grangetto, Matteo
Sereno
Università degli Studi di TORINO
Dipartimento di Informatica
Corso Svizzera 185
10149 Torino
first.last@di.unito.it
ACM Workshop on Advanced video streaming techniques for peer-to-
peer networks and social networking, Firenze 29/10, 2010

Outline
• Motivations
• Introduction to rateless codes
– LT codes
• ToroVerde architecture
– Overlay layer
– Content distribution layer
– Video buffer layer
• Additional PlanetLab results
• Conclusions and future work

Motivations
• Real-time multicast over P2P
network is promising
application
– startup delay, latency, security, ISP
friendliness
• Coding techniques can
improve the efficiency of
content distribution
M. Wang, B. Li, “R2: Random push with random
network coding in live p2p streaming”, IEEE
JSAC, Dec. 2007.
W. Chuan, B. Li, ”rStream: resilient and optimal p2p
streaming with rateless codes”, IEEE Trans. on
Parallel and Distributed Systems, Jan. 2008

Motivations
• Rateless codes
– LT codes, Raptor codes
– Packet level coding by
simple XOR
– Random coded packets
are generated on the fly
(rateless)
– Optimal (asymptotically
zero overhead)
– Low complexity
encoder/decoder
M. Luby, “LT codes”, IEEE Symp. on
Foundations of Computer Science,
2002

LT codes
• Source packets:
• j-th coded packet:
• Encoder:
– Randomly select the coded packet degree d according to the
Robust Soliton Distribution (RSD)
– Randomly chose d packets for XOR
• Decoder:
– Buffers coded packets
– Search for a degree 1 packet (it corresponds to a source
packet) and cancel it from all involved packet equations
– Efficient Gaussian elimination based decoding
V.Bioglio, R.Gaeta, M.Grangetto, M.Sereno, “On the fly Gaussian elimination for
LT codes”, IEEE Communications Letters, Dec. 2009ACM Workshop on Advanced video streaming techniques for peer-to-

LT codes applications
• Data dissemination with rateless
codes is well suited for broadcasting
(3GPP MBMS, DVB-H)
• Application to overlay networks
– not straightforward
– connections with network coding
– yields PROs and CONs

LT codes & overlay networks
• LT codes for overlay networks
– Simple push
approach for data
distribution
– Does not require
content
reconciliation
– Robustness to peer
churning and losses
– Additional
complexity & mem.
– coding may
introduce additional
delay
Starting from our previous work this
paper presents the development and
evaluation of a live P2P streaming
application based on LT codes
R.Gaeta, M.Grangetto, M.Sereno,
“Rateless codes network coding for
simple and efficient P2P streaming”,
IEEE ICME, 2009

Toro Verde architecture
• video is organized in a sequence of
chunks
– independently decodable video units
– composed of the video packets corresponding to a
GOP encoded by the AVC/H.264 encoder
– each chunk is coded using LT codes

Toro Verde architecture
• LT codes rise tolerance to packet loss
– UDP based
– TFRC used to control sending rates
• LT code introduce delays (chunk
coding only after complete decoding)
– Early coded packet relaying (lesson learned from
our previous work)
– To avoid loops of duplicated coded packets
 Coded packets are relayed only once
 Bloom filter (32 bits, 3 hash functions in the header of
each coded packet) to store the path already followed
 Currently under submission a work extending these
policies avoiding the need for Bloom filters

Toro Verde architecture : overlay layer
• goal: to form the logical network
• the cast: tracker, video server, peer
– The part played by the tracker
 store the addresses of the peers
 respond to peers requests
– The part played by the video server
 accept connection requests up to a maximum number
 deliver packets of LT coded chunks to its neighbors
– The part played by the peer
 contact the tracker
 get a random subset of peers
 send a contact message to all peers returned by the
tracker
 send keep-alive messages to neighbors and tracker

Toro Verde architecture : overlay layer
• a peer is removed from the neighbor
list
– it does not send keep-alive messages for some
time
– it sends an explicit quit message
• maximum number of neighbors
– refuse additional connection requests
• minimum number of neighbors
– contact the tracker for more neighbors

Toro Verde architecture : content distribution layer
• goal: maximize upload bandwidth
utilization and minimize duplicated
packets
– dynamic buffer to store chunks
– chunks are ordered according to their sequence
number (Bfirst and Blast)
• state of a chunk (peer internal)
– empty, partially decoded, decoded
• state of a chunk (to advertize)
– Interested, not interested
• decoded chunks trigger STOP CHUNK
messages

• a peer keeps a buffer map for each
neighbor
– binary representation of useful chunks
• algorithm to keep track of useful chunks
• a peer removes a chunk from B when
– it is not useful for all of its neighbors (info from buffer
maps)
– the player has already consumed it
– if it is the eldest then Bfirst is incremented

• coded packets are pushed to a subset of
neighbors (the enabled set)
– it is periodically refreshed
– cardinality of the enabled set is dynamically adapted
depending on the upload bandwidth
– strategy is borrowed from BitTorrent (worst enabled
replaced by a random peer, etc.) but …..
– … ranking criterion is novel

• Upload bandwidth is fully utilized when pushing
fresh coded packet obtained from decoded
chunks
– on the contrary, a coded packet of a partially decoded
chunk can be shared only once thus limiting the
outgoing throughput
– decoding time of a peer DT, defined as the highest
sequence number of the chunks in B whose state is
decoded, minus the number of partially decoded
chunks in B
– maximum when it has already decoded the most recent
chunk without partially decoded chunks before it

• lead index (LI) defined as the difference between
the peer DT and the average DT in its
neighborhood (estimated from the buffer maps)
• The leaders are peers whose upload capacity at
least doubles the video bitrate and whose LI is
larger than a predefined threshold
• The remaining are termed followers
– Leaders rank neighbors based on their LI (other leaders
are preferred)
– Followers rank neighbors based on the number of
coded packets uploaded in the last 20 s (tit-for-tat)

Toro Verde architecture : video buffer layer
• goal: to select the decoded chunks in B to
be forwarded to the player
– The player is started for the first time when the number of decoded
chunks in a row reaches a threshold
– decoded chunks are periodically sent to the player
• buffering
– if the number of decoded chunks in B falls below a threshold
– until the number of decoded chunks exceeds a threshold
• dropping
– LI is used to detect if a peer is experiencing a high decoding delay
compared to its neighbors.
– if LI is below a negative threshold the eldest partially decoded
chunk in B is dropped (STOP CHUNK messages to the neighbors)

Toro Verde architecture : video buffer layer
• SVC where different video layers are
conveyed by separated chunks
• buffering works as usual by monitoring
only the chunks of the BL
• dropping is applied to EL chunks with
higher priority w.r.t. BL

Additional Planetlab results
• How to evaluate performance of Toro Verde
– Continuity index (CI)
– Preview delay
– Startup delay
• System parameters
– Video bitrate (in Kbps)
– Video server upload bandwidth (in Kbps)
– Upload bandwidth distribution (yielding the
resource index (RI), i.e., the ratio between the
average upload bandwidth and the video bitrate)
– Arrival and departure patterns
– Number of peers

• How to compare Toro Verde against other
proposals?
– BIG problem if prototypes are not freely available!
– Often only simulation studies
– When PlanetLab experiments are conducted full information
on system parameters are unknown or not accessible
– Nevertheless CPU and network congestion are NOT
reproducible
• How to choose Planetlab hosts?
– BIG problem, as well!
– Many unusable hosts (unreachability, bad connection
quality, DNS problems, high CPU load, varying SSH keys,
scarce free disk space)

• Video bitrate: 300 kbps
• Video server upload bandwidth: 2
Mbps
• Upload bandwidth distributions
– 256 Kbps 65% 65% 78% 85%
– 384 Kbps 25% 30% 17% 10%
– 1 Mbps 10% 5% 5% 5%
– RI 1.2 1.1 1.05 1.02
• Arrival/departure patterns
– stable
– churning, alternating arrival and departures
– mixed (half stable, half churning)
• Average number of peers: 400

• stable
– RI 1.2 1.1 1.05 1.02
– CI 0.99 0.97 0.94 0.92
– preview delay 15.4 s 16.1 s 16.8 s 22.1 s
– startup delay 42.2 s 44.1 s 47.8 s 55.9 s
• mixed (200 s)
– RI 1.2 1.1 1.05 1.02
– CI 0.96 0.96 0.94 0.92
• churn (200 s)
– RI 1.2 1.1 1.05 1.02
– CI 0.93 0.93 0.92 0.92

Paper Planetlab results
• Video bitrate: 400 kbps
• Video server upload bandwidth: 800 Kbps
• Upload bandwidth distributions
– 345 Kbps 8%
– 460 Kbps 64%
– 585 Kbps 12%
– 690 Kbps 12%
– 920 Kbps 4%
– RI 1.28
• Arrival/departure patterns
– churning (100 s)
• Average number of peers: 400
• SVC: BL is reserved ¼ of the bitrate

Paper Planetlab results

Conclusion and future work
• Contributions:
– Development of a complete P2P live streaming application
exploiting LT codes to cope with data loss and peer churning
– Novel algorithms to maximize upload bandwidth utilization
– Support for SVC
– Experimental evaluation in resource limited scenarios
• On going works:
– Deeper analysis of TVS performance w.r.t. delays and
overhead with and without SVC
– Analysis of cost-benefit of TFRC and Bloom filters
– Implementation of novel (under submission) relaying
strategies
– Extension of TVS architecture to support multi-view
– Head-to-head comparison against a cluster-based, multi-
tree, MDC encoded architecture
A.Magnetto, R.Gaeta, M.Grangetto, M.Sereno, “TURINstream: a Totally pUsh
Robust and effIcieNt P2P video streaming architecture”, to appear on IEEE
Transactions on Multimedia

P2P streaming with LT codes

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à P2P streaming with LT codes

Similaire à P2P streaming with LT codes (20)

Plus de Alpen-Adria-Universität

Plus de Alpen-Adria-Universität (20)

Dernier

Dernier (20)

P2P streaming with LT codes