Summary Introduction Review Challenges Proposal Problems Conclusion Peer-to-Peer IPTV Services Daniel Antonio Garcia Manzato ([email protected]) Prof. Nelson Luis Saldanha da Fonseca ([email protected]) Institute of Computing, State University of Campinas, Brazil 2 nd IEEE Workshop on Enabling the Future Service-Oriented Internet New Orleans-LA, 11/30/2008
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
IPTV: alternative delivering system to cable and broadcastService promises to be in the future InternetProblems: ⇓ visual quality, regulatory issuesTypes:
Commercial IPTVPrivate architectures⇒ limited population servedGuarantee of quality of serviceNormally provided in triple play services
Cooperative IPTVPublic architectures⇒ global population servedQuality of service sought through best effort networksCooperative environment, clients’ resources, P2PTV
Proposal of a novel P2P architecture for cooperative IPTVEvolution of this type of system, which is still in infancyIdentification of common challengesIncorporation of solutions in the architectureSearch for competitiveness with traditional televisionOffer of an efficient alternative to commercial IPTV
Tree (End System Multicast – ESM)Explicit delivery structures ⇒ data-push approach+: ⇓ delay−: No fault-tolerance, do not employ leaf nodes’ bandwidths
Multiple Trees (CoopNet, SplitStream, Chunkyspread)Redundancy of data and network paths+: ⇓ delay, fault-tolerance, employ leaf nodes’ bandwidths−: Tree management overhead, implementation complexity
P2P media streaming live (synchronized distribution)Supports peer heterogeneity and network congestion(bandwidth adaptation protocol);Employs LMDC and multiple distribution treesPeer: interior node in just one tree and leaf node in theremaining trees
Challenge: Short Start-up Delay⇒ Employment of multiple trees rather than mesh,distribution of the tree management overhead by multipleservers, distinct scheme for channel switchingChallenge: Need for Incentive Mechanisms⇒ Distinct incentive scheme for cooperation, integrated tothe architectureChallenge: Need for Some Dedicated Infrastructure⇒ Introduction of the 2nd layer of the architecture, withdedicated infrastructure (DSNs)
Challenge: Support for Flash Crowds and High Churns⇒ Employment of redundancy of data (MDC) and networkpath (multiple trees)Challenge: Support for Client Heterogeneity⇒ Employment of LMDC for bandwidth adaptation andincentive scheme with deferred remunerationChallenge: Synchronization of Client Playback⇒ Possible optimization of overlay structuresChallenge: Better NAT and Firewall Traversal⇒ Possible employment of the STUN protocol
1 RN requests an operation of channel browsing to TSN2 RN leaves the 1st set of trees and is admitted into the 2nd
set of trees, changing its state to “browsing mode”3 After channel selection, RN requests an operation of
admission with pre-selection of channel to the upper DSN4 DSN redirects RN to the least loaded TSN of that channel5 RN is admitted by the new TSN into the 1st set of trees,
Playback engine with multiple buffers FIFOChannel Switching in RNs:
Start-up delay for browsing: admission into the 2nd set oftrees + filling up playback engine’s buffersAfter start-up delay ⇒ channel switching is immediate,except when swapping scheme is necessaryProblem: synchronization of the streams from the old TSNand from the new TSN
Channel Switching in TSNs:Separation of the channels served and watched ⇒ freebrowsing without affecting descendant RNsDescriptions received from DSN through the sameconnection ⇒ no trees, no swapping, no delay, just switchof playback buffers
Benefits of temporal de-linkage between cooperation andremuneration:
Employment of cooperation from offline users (⇑ credits)Exemption of cooperation for a period of time (⇓ credits)Reception of higher stream quality (⇓ credits)Handling of asymmetric linksEmergence of TSNs (affiliate servers)
Model of affiliate servers:Comparable to the Internet advertisement business modelQualified TV content ⇒ periodic earning (+$)TSNs enlarge system capacity on demand (−$)Dynamic resource allocation vs. static provision ofinfrastructure
Storage of credits from cooperation in banking accountsAsynchronous rem. ⇒ temporal de-linkage coop./rem.
Barter Trade ⇒ for TSNs and RNsBalancing between cooperated and consumed bandwidthsCredit or debit in accounts per unit of time
Community (Reputation) ⇒ for TSNs onlyClassification of TSNs ⇒ fairness and selectionCapability-related metrics: delay and throughputBehavioral metrics: session mean time and abrupt disc.
Bandwidth optimization for DSNsComplete graph ⇒ dep. # channels, SPs and DSNsEmployment of multicast (network or application), multipletrees, mesh ⇒ ⇑ hops ⇒ ⇑ delay
Different overlay structures for RNsMultiple trees ⇒ ⇓ start-up delayEmployment of different distribution approaches andoverlays, mesh as an auxiliary structure (mTreebone)
Synchronization of ni (new TSN) with mi (old TSN)Employment of Piggybacking, larger buffers, abruptswitching (simplistic approach)
Dynamic variation of network resourcesDeferred remuneration, client heterogeneity, FCs/HCs ⇒rapid oscillation between resource scarcity/excessEmployment of dynamic adaptation by the incentivemechanism ⇒ var. of reputations, thresholds, taxes