P2P Video Streaming Systems Yong Liu et' al' - PowerPoint PPT Presentation

Loading...

PPT – P2P Video Streaming Systems Yong Liu et' al' PowerPoint presentation | free to view - id: 24df23-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

P2P Video Streaming Systems Yong Liu et' al'

Description:

Find new partners if existing one leaves you ;) Use trackers like regular ... Do Even Better' By Qian Zhang Hong Kong University of Science and Technology ... – PowerPoint PPT presentation

Number of Views:183
Avg rating:3.0/5.0
Slides: 98
Provided by: csci8211t
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: P2P Video Streaming Systems Yong Liu et' al'


1
P2P Video Streaming Systems(Yong Liu et. al.)
  • Presented by
  • -Srivenkatesh Kumar Vaithianathan

2
Evolution of Video Streaming
  • The good old client server model
  • Well, let us reject this idea with no further ado
    )
  • Using CDNs for Video Streaming
  • YouTube The darling of masses!!!
  • Scalability of CDN Servers is a ? as IPTV grows
  • Akamai has(d) entire bandwidth of 300
    gigabit/sec, 2006
  • P2P IPTV
  • Users act as Clients and Servers OMG thats news
    to me!
  • 200,000 simultaneous users watched a live
    broadcast of a 4 hour event with bit rates
    ranging from 400-800 gigs
  • Aggregate bandwidth reached 100 gigabits per
    second

3
P2P Streaming Approaches
  • Approaches
  • Tree Based
  • The vestige of IP Multicast based streaming
  • Vulnerable to Peer churn
  • Dependency on higher level peer
  • Mesh Based
  • No defined structure (Chaos theory works!!!)
  • Dynamic peering and data exchange
  • Unpredictable No guarantees on packet arrival
  • May suffer from quality degradation as a result

4
P2P Streaming Paradigms
  • Live Streaming
  • Real time dissemination of content
  • Playback on different users synchronized
  • Video on Demand
  • Users have flexibility to watch
  • Playback is not synchronized
  • Not naturally adaptable to either tree based or
    mesh based approaches Tweak Tweak Tweak!!

5
P2P Live Streaming Tree Based
  • Single Tree
  • IP Multicast at Application Layer
  • Levels of peers Hierarchical
  • Considerations Depth and Fan-out
  • Higher depth leads to larger delay for the leaves
  • Fan-out is bounded by uploading capacity of nodes
  • Tree maintenance Nodes leave non-gracefully
  • Tree recovery Higher level nodes - greater impact

6
P2P Live Streaming Tree Based
  • Single Tree Contd
  • Tree Construction and Maintenance approaches
  • Centralized
  • Peers contact a central server
  • Server has timeouts and heartbeats to find peer
    departure
  • Server indicates clients about topology changes
  • Server becomes a performance bottleneck
  • Server is a single point of failure
  • And we get back to the same conclusion over and
    over Anything centralized is simply unscalable
  • Distributed
  • Right option but not explained in the paper ?

7
P2P Live Streaming Tree Based
  • Single Tree Contd
  • Inspite of Distributed algorithms for peer
    maintenance, peer churns greatly affect
    performance
  • Leaf nodes are only receivers
  • Lesser peer bandwidth utilization (since fan-out
    is big and leaves dont contribute)
  • In short, the only uses of the Single Tree
    approach
  • The paper got one page worth of content for free
    !!!!
  • Not to forget two good looking diagrams!!!
  • And I have got three slides for free ?

8
P2P Live Streaming Tree Based
  • Multi-Tree
  • Server divides up the data in multiple streams
  • Peers subscribe to all sub-streams
  • Each Sub-stream has a different sub tree
  • All sub trees look different
  • Peers are at different levels in each sub-tree
  • Leaf nodes in some sub-trees upload data in others

9
P2P Live Streaming Tree Based
  • In a fully balanced multi-tree streaming with m
    (2) sub-streams the node degree of each sub-tree
    is m (2)
  • A single peer is positioned in an internal node
    in only one sub-tree (e.g. peer 0) and uploads
    only one stream to its m (2) children in that
    sub-tree
  • In all other sub-trees the peer is positioned at
    a leaf node

10
P2P Live Streaming Mesh Based
  • Avoids the problems in tree based approach
  • A single node failure does not cut off an entire
    tree
  • Peers establish and terminate peering
    relationships dynamically
  • High peering degree robust to peer churn
  • Find new partners if existing one leaves you )
  • Use trackers like regular peer-to-peer systems
  • Constantly update peer list prepare for the
    eventuality. Your partner might leave any
    time!!!
  • Exchange keep-alive to peers to notify existence

11
P2P Live Streaming Mesh Based
  • Peering Strategies
  • Everyone has their own strategy
  • Peering based on
  • Work and resource availability
  • Quality of current connections
  • Content availability
  • Peers change partners voluntarily No alimony!!!

12
P2P Live Streaming Mesh Based
  • Data Exchange Strategies
  • Chunks instead of streams
  • Sequencing of chunks
  • Out of order arrival and buffering
  • Push and Pull methodologies
  • Push
  • Actively pushing received chunks
  • Wastage of bandwidth by duplication
  • Pull
  • Buffer maps of available chunks exchanged
  • Peers pull chunks seeing availability

13
Tug of War - Push and Pull
  • How to reduce the delay of pull mechanism while
    keeping the advantages of pull mechanism?
  • Use pull mechanism as startup
  • Then packets will be pushed directly from the
    neighbors if possible
  • In each interval, every node subscribes the
    pushing packets from the neighbors
  • Packets loss during push time interval will be
    recovered by pull mechanism
  • Thanks to Understanding the Power of Pull-based
    P2P Streaming Protocol We Can Do Even Better
    By Qian Zhang Hong Kong University of Science and
    Technology

14
P2P Video on Demand (VoD)
  • Watch whatever whenever wherever ever
  • We only talk about same file sharing here!!!
  • Asynchronous Different users of the same file
    are at different points in the file
  • None of the previous approaches can be applied
    as is
  • Tree
  • User receive in order sent by Server (Synchronous
    by nature)
  • Mesh
  • The previous problem still persists (receiving
    chunks before playback time)
  • And a new headache share among asynchronous
    peers

15
P2P VoD Tree Based
  • Adapt the original tree based approach with some
    patch ups here and there Literally!!!
  • Sessions group together users who almost started
    out together
  • Two streams
  • Base stream
  • Synchronous
  • Start from server
  • Patch stream
  • Asynchronous
  • Start either from server or from users who cache

16
P2P VoD Tree Based
17
P2P VoD Cache and Relay
  • Users who began almost together form a cluster
    based on the caching window maintained by the
    peers who joined earlier
  • If a peer comes very late, and it misses the
    caching window of all users, it starts a new
    connection with the server
  • Cache size is critical - decides shape of network
  • directory service to maintain which cached user
    to get data from
  • DEFEATS!!!! IP Multicast

18
P2P VoD Mesh Based
19
P2P VoD Mesh Based
  • Server transmits diverse contents to users -
    Swarming
  • Users mostly exchange rather than pull from
    server
  • Problem Data received in random order
  • Problem User Control??? No way!!!
  • Problem How this solves the VoD problem?
  • Problem Is it worse than the original mesh
    based approach for live streaming?

20
P2P VoD Mesh Based
  • Solution Priority and Probability
  • Some chunks are marked as high priority are
    actively pursued
  • While others can come at their own whim (well,
    not exactly!!!)
  • Governed by p the probability of pursuing
  • The twin towers p and 1-p
  • Can we do better??? Pre-fetching

21
P2P VoD Mesh Based
22
Take heart!!! We are finishing
  • Open Issues
  • Nowhere close to cable standards
  • Longer channel startup and delay
  • Currently only low resolution videos
  • Lesser peers gt Poorer quality
  • Connections not ISP friendly
  • Well, we are not quite there yet
  • But still, we are working on it!!!

23
Thank you folks!!!Looking for graphs??? Cant
find one yet Dont worry The best of times is
yet to come ?
24
Challenges, Design and Analysis of a Large-scale
P2PVoD System - Huang et. al.
24
  • Presented by
  • -Lavanya Raghunath

10/29/2008
CSCI 8211 (Adv. Computer Networks)
25
Contents
25
  • Introduction
  • Design
  • Segment Size
  • Replication Strategy
  • Content Discovery and Overlay Management
  • Piece Selection
  • Transmission Strategy
  • Measurement
  • User Behavior
  • User Satisfaction
  • Health of Replication
  • Some Results

10/29/2008
CSCI 8211 (Adv. Computer Networks)
26
Why this paper??
26
  • Motivation
  • Reduce Server loading for P2P VoD services
  • No guarantee for in-order of content in P2P
    systems
  • Less synchrony in users sharing video
  • Contribution
  • Large-scale P2P VoD Design guidelines
  • Definition and Measurement of Performance
    metrics
  • Analysis and Inferences

10/29/2008
CSCI 8211 (Adv. Computer Networks)
27
Contents
27
  • Introduction
  • Design
  • Segment Size
  • Replication Strategy
  • Content Discovery and Overlay Management
  • Piece Selection
  • Transmission Strategy
  • Measurement
  • User Behavior
  • User Satisfaction
  • Health of Replication
  • Some Results

10/29/2008
CSCI 8211 (Adv. Computer Networks)
28
Design GuidelinesComponents Segments
28
  • Content servers, trackers, bootstrap servers, log
    servers, transit servers, peers
  • Segment Size

Scheduling
Nature of Streaming
Overhead
10/29/2008
CSCI 8211 (Adv. Computer Networks)
29
Replication Strategy
29
  • Availability not dealt in detail by authors!
  • Single Movie Cache (SVC )Vs Multiple Movie Cache
    (MVC)
  • Avoid Pre-fetching - average viewing 1 hour,
    upload wastage
  • Chunk/Movie to remove - LRU, LFU, Weight-based
    availability demand ratio (ATD)
  • Need of a movie 1/(ATD)

10/29/2008
CSCI 8211 (Adv. Computer Networks)
30
Content Discovery
30
  • Tracker keep track of which peers replicate a
    movie
  • Gossip method by advertising chunk bitmaps
  • Less reliance on tracker
  • Robust and Distributed control
  • DHT is used for load balancing by assigning
    movies to tracker nodes

10/29/2008
CSCI 8211 (Adv. Computer Networks)
31
Piece Selection
31
  • Sequential closest to video playback
  • Rarest-first newest in the system, increases
    spread of pieces, indirectly helps streaming
  • Anchor-based video anchor points for jump
    forward (or backward)
  • Mixed sequential and then rarest-first

10/29/2008
CSCI 8211 (Adv. Computer Networks)
32
Transmission Strategy
32
  • Which neighbor to download chunk?
  • How many simultaneous neighbors?
  • How to schedule requests?
  • Levels of aggressiveness
  • Same request to multiple peers
  • Different requests to different peers
    redirected when timed out
  • One neighbor at a time
  • 8-10 neighbors for 500kbps

Maximize download rate
Minimize overhead
10/29/2008
CSCI 8211 (Adv. Computer Networks)
33
Other Design Issues
33
  • Incentives for Contribution
  • tit-for-tat does not work due to uploading
    bandwidth constraint
  • PPLive does not allow contribution level
    adjustment! - Regular advertisement of chunk
    bitmaps monitored
  • Pace uploading rate to avoid being blocked by
    firewalls
  • Content Authentication
  • Chunk level
  • Less overhead
  • More damage, Entire chunk discarded due to single
    piece
  • Piece level
  • Weaker form of piece level

10/29/2008
CSCI 8211 (Adv. Computer Networks)
34
Contents
34
  • Introduction
  • Design
  • Segment Size
  • Replication Strategy
  • Content Discovery and Overlay Management
  • Piece Selection
  • Transmission Strategy
  • Measurement
  • User Behavior
  • User Satisfaction
  • Health of Replication
  • Some Results

10/29/2008
CSCI 8211 (Adv. Computer Networks)
35
Performance Metrics
35
  • User behavior
  • includes the user arrival patterns, and how long
    they stayed watching a movie, , time spent in
    watching movie, overlaps among peers, jumps
  • used to improve the design of the replication
    strategy
  • External performance metrics
  • includes user satisfaction and server load
  • used to measure the system performance perceived
    externally
  • Health of replication
  • measures how well a P2P-VoD system is replicating
    a content

10/29/2008
CSCI 8211 (Adv. Computer Networks)
36
User Behavior
36
  • Movie Viewing Record (MVR) generated based on
    sequence of user events

10/29/2008
CSCI 8211 (Adv. Computer Networks)
37
User Satisfaction
37
  • Simple fluency
  • Fraction of time spent watching a movie out of
    the total time spent waiting for and watching
    that movie
  • R(m, i) the set of all MVRs for a given movie
    m and user i
  • n(m, i) the number of MVRs in R(m, i)
  • r one of the MVRs in R(m, i)

10/29/2008
CSCI 8211 (Adv. Computer Networks)
38
User Satisfaction Index
38
  • Fluency Quality of content delivery
  • where
  • and
  • r(Q) users grade for average viewing quality

10/29/2008
CSCI 8211 (Adv. Computer Networks)
39
Health of Replication
39
  • Movie Level
  • number of active peers having movie chunks
  • Weighted Movie Level
  • fraction of chunks taken into account
  • Chunk Bitmap Level
  • number of copies of each chunk of a movie
  • Useful for several inferences eg. average no. of
    copies of chunks, min. no. of replicas,
    variance

10/29/2008
CSCI 8211 (Adv. Computer Networks)
40
Contents
40
  • Introduction
  • Design
  • Segment Size
  • Replication Strategy
  • Content Discovery and Overlay Management
  • Piece Selection
  • Transmission Strategy
  • Measurement
  • User Behavior
  • User Satisfaction
  • Health of Replication
  • Some Results

10/29/2008
CSCI 8211 (Adv. Computer Networks)
41
Stats on User Behavior Inter-arrival Time
41
Movie 2 is most popular with least inter-arrival
time
10/29/2008
CSCI 8211 (Adv. Computer Networks)
42
Residence Distribution of Users
42
System is Scalable if most users stay ON for
longer durations
10/29/2008
CSCI 8211 (Adv. Computer Networks)
43
Stats on Health Index of Movies
43
Replication factor is dynamic, higher for popular
movies
Greater replication of movie in demand (Movie 2)
10/29/2008
CSCI 8211 (Adv. Computer Networks)
44
Chunk Available Vs Demand
44
10/29/2008
CSCI 8211 (Adv. Computer Networks)
45
Stats on User Satisfaction Index
45
  • Insufficient Storage buffer
  • Distribution of Replicas

10/29/2008
CSCI 8211 (Adv. Computer Networks)
46
One Last Interesting Relation..
46
Impact of Rate of change of viewers on
of good/bad users fluency
10/29/2008
CSCI 8211 (Adv. Computer Networks)
47
Further research in P2P-VoD systems
47
  • How to design a highly scalable P2P-VoD system to
    support millions of simultaneous users
  • How to perform dynamic movie replication,
    replacement, and scheduling so as reduce the
    workload at the content servers
  • How to quantify various replication strategies so
    as to guarantee a high health index
  • How to select proper chunk and piece transmission
    strategies so as to improve the viewing quality
  • How to accurately measure and quantify the user
    satisfaction level

10/29/2008
CSCI 8211 (Adv. Computer Networks)
48
General Thoughts and Questions
48
  • Should distribution of replicas over the peer
    network not be measured? ? Latency in fetching
    movie?
  • Availability of a movie is a significant metric -
    could have been detailed better (consider churn
    rate)
  • How tolerant should the design be? What is the
    impact if a chunk of a movie is completely lost?

10/29/2008
CSCI 8211 (Adv. Computer Networks)
49
49
  • Thank You!!
  • Questions?

10/29/2008
CSCI 8211 (Adv. Computer Networks)
50
A Measurement Study of a Large-Scale P2P IPTV
SystemHei et al.
  • Timothy J. SaloCSci 8211October 29, 2008

51
Large-Scale P2P IPTV
  • Some History
  • Video-on-demand service was the carriers killer
    application
  • Wanted to escape commodity business of
    transporting bits
  • Deregulation, lots of competition, low margins
  • Wanted to move into content delivery, online
    shopping, gaming, ...
  • Higher margins, make more money

52
Large-Scale P2P IPTV
  • U S West / Tele-Communications, Inc.
  • Denver video-on-demand trial, 1993
  • Consumers bought lt3 movies/month
  • Refused to pay more than 3 - 4/movie
  • Hollywood takes half of that

53
Large-Scale P2P IPTV
  • Orlando Video-on-Demand Trials
  • Time Warners Full Service Network, 1994
  • Interactive television, home shopping,
    grippingly realistic video games
  • Print tickets, coupons
  • 4,000 households
  • Optical fiber
  • Compete with 15B video rental industry

54
Large-Scale P2P IPTV
  • Orlando Video-on-Demand Trials
  • SGI video servers
  • SGI Challenge and Onyx
  • Internet access was future objective (!)
  • Results
  • Generally regarded as an expensive failure

55
Large-Scale P2P IPTV
  • MBone
  • Experimental IP multicast overlay network
  • Internet-wide
  • Originally, hand-crafted topology
  • Van Jacobson, Steve Deering, 1992 2000
  • Primarily video conferencing
  • ISPs still wont support IP multicast
  • Hence, lots of overlay networks
  • Shouldnt this be done at the network layer?

56
Large-Scale P2P IPTV
  • Today
  • Carriers still trying to figure out how to get
    into content business
  • Network neutrality
  • Should carriers content receive better service?
  • May carriers throttle peer-to-peer systems?
  • Larry Lessig, Stanford Law School
  • The Policy Implications of End-to-End

57
Large-Scale P2P IPTV
  • Today
  • Competition for video-on-demand
  • Redbox
  • 10,000 locations, 1 DVD rentals
  • Netflix
  • 100,000 titles, 1-day latency, starts at
    4.99/month
  • Starting Internet download service
  • Will peer-to-peer systems eliminate alleged
    market opportunity for commercial video-on-demand?

58
Large-Scale P2P IPTV
  • A Measurement Study of ...
  • Three interesting aspects
  • Measurement target
  • P2P IPTV system (PPLive)
  • Measurement methodology
  • Reverse engineer, snoop proprietary protocols
  • Measurement results

59
Large-Scale P2P IPTV
  • Measurement Target
  • Large peer-to-peer IPTV system
  • PPLive
  • Based in China
  • Primarily Mandarin content

60
Large-Scale P2P IPTV
  • Measurement Target
  • PPLive is a P2P television network software that
    famous all over the world. It has the largest
    number of users, the most extensive coverage in
    internet.
  • Clear and easy to use user interface
  • Using P2P technology, the more users the better
    experience
  • Rich program resources,powerful research support
  • Excellent Cache technology ,free of damaging hard
    disk
  • Support a variety of languages,including
    Simplified Chinese,Traditional

61
Large-Scale P2P IPTV
  • Measurement Target

62
Large-Scale P2P IPTV
  • Measurement Target
  • Mesh-pull peer-to-peer live streaming system
  • 400,000 daily users, 200 channels (May 2006)
  • Study found peaks of 400,000 peers

63
Large-Scale P2P IPTV
  • Measurement Target
  • Components
  • Streaming engine and media player
  • End user
  • Streaming peer nodes
  • Other users
  • Tracker server
  • Provides streaming channel, peer and chunk info
  • Channel stream server
  • Serves video content in small chunks

64
Large-Scale P2P IPTV
  • Measurement Target
  • Two major protocols
  • Control protocol
  • Peer registration, channel discovery, peer
    discovery
  • P2P media chunk distribution protocol
  • Request buffer map from peer
  • Request video chunks from peer

65
Large-Scale P2P IPTV
  • Measurement Techniques
  • Reverse engineer, implement proprietary protocols
  • Peer registration protocol
  • Peer list query protocol
  • Buffer map request protocol
  • Snoop proprietary protocols
  • Identify video traffic

66
Large-Scale P2P IPTV
  • Measurement Techniques
  • Peer crawler
  • Register for a channel with root server
  • Request bootstrap peer list (50 peers)
  • Crawl through list of peers for a while
  • Sleep for a while
  • Start all over

67
Large-Scale P2P IPTV
  • Measurement Techniques
  • Peer crawler
  • Finds 95 of peers for channel lt five secs
  • Also requests buffer map from peers
  • Provides lots of info about
  • Peers
  • Status of peers
  • Peers over time

68
Large-Scale P2P IPTV
  • Measurement Techniques
  • Snoop peer-to-peer traffic
  • Assume UDP packets are control messages
  • Assume short TCP connections are control messages
  • Assume long TCP connections are video data
  • Assume short packets are control messages

69
Large-Scale P2P IPTV
  • Measurement Techniques
  • Remember, all measurements performed in U.S.,
    most of system in China
  • Measure from
  • Campus network
  • Residential access
  • Measure
  • Popular channel (CCTV3)
  • Less popular channel (CCTV10)

70
Large-Scale P2P IPTV
  • Measurement Results
  • Total peers over a week

71
Large-Scale P2P IPTV
  • Measurement Results
  • Peers per channel

72
Large-Scale P2P IPTV
  • Measurement Results
  • Flash crowd

73
Large-Scale P2P IPTV
  • Measurement Results
  • Viewers leave at the end of a movie

74
Large-Scale P2P IPTV
  • Measurement Results
  • Viewers dont like unpopular shows

75
Large-Scale P2P IPTV
  • Measurement Results
  • Everyones in China

76
Large-Scale P2P IPTV
  • Measurement Results
  • Everyones in China (except)

77
Large-Scale P2P IPTV
  • Measurement Results
  • System aims for 7 MB of buffering

78
Large-Scale P2P IPTV
  • Measurement Results
  • Up to 140 sec difference in playback time

79
Large-Scale P2P IPTV
  • Measurement Results
  • Note difference in upload rates between campus,
    residence
  • Note difference in number of active video peers
    between campus, residence

80
Large-Scale P2P IPTV
  • Measurement Results
  • Geographic distribution of peers

81
Large-Scale P2P IPTV
  • Measurement Results
  • The system seems to really work
  • Contrast that with centralized, server-based
    systems

82
Large-Scale P2P IPTV
  • Closing Observations
  • Interesting measurement target
  • PPLive
  • Interesting measurement techniques
  • Reverse engineer proprietary protocols

83
There and Back Again!!!A VoD Profitability
taleCan Internet VoD be profitableCheng
Huang et. Al
By -Srivenkatesh Kumar Vaithianathan
84
Dont lose heart!!! There is very little
  • What is this paper all about?
  • Trace bandwidth usage of existing MSN video
    service operating in Client-Server mode (9
    months)
  • Assess and estimate bandwidth usage if
    peer-assisted video service was used instead
  • Study the impact of peer-assisted service on
    cross-ISP traffic
  • Draw 16 graphs to present the results

85
Where is the data from?
  • Trace Records from MSN Video Service
  • Record Format
  • Client Information
  • Video Content fields (length of video, size of
    file)
  • Streaming fields (all details on streaming)
  • Every user interactive operation generates
    separate records
  • Hash client information to group the records by
    clients/users
  • Group by Player
  • Further group all user interactive operation
    record for a particular video playback together
  • Group by Session

86
Video Popularity Distribution
  • Fitting this graph in context
  • Popularity is independent of load
  • High degree of locality
  • The end of the curve is flat Some clips have
    same popularity level

87
Available User Bandwidth
  • Fitting this graph in context
  • Denotes the amount of bandwidth available for
    peer-assisted scheme in user machines
  • 60 of users have more than 1.5 Mbps to share
  • Incentive schemes can be used to make users give
    their bandwidth and more so during peak hours

88
User Behavior
  • Fitting this graph in context
  • How many users meddle with the control when
    watching the video? (The impatient ones!!!)
  • Smaller videos are watched to completion (figure
    1)
  • Even in the worst case 60 of session of any
    duration are non interactive (figure 2) (They
    might not watch till the end, but surely they
    dont keep moving around the video)

89
Demand Ever increasing (as ever)
  • Fitting this graph in context
  • Most importantly, establishes the fact that MSN
    video is becoming better ?
  • Apr 2006 people were satisfied with 200 kbps
  • Dec 2006 people are demanding more (320 kbps)

90
Some theory Rise now!!!
  • Didnt expect it, did we?
  • Neither did I. When I see graphs, I start
    anticipating end of the paper, but this one
    ditched me ?
  • Poissoning the system
  • Users are classified according to upload
    bandwidths
  • Arrival of a user of a given bandwidth is Poisson
  • The time till which user remains in system is
    Random
  • And a lot of math follows (ß? and åae)
  • Finally they calculate some values for Surplus
    and Demand Totally escapes me how people take
    mathematics to be a language and start talking

91
So how did the math help??
  • Poissoning the system Contd
  • Ya, as said, they calculated demand and supply
  • When Demand gt Supply, we conclude that we are in
    deficit, when Demand lt Supply, we are in surplus
    and when Demand Supply we are balanced
  • Now you may start to think - That surely does
    not need a Poisson distribution to explain!!!
  • But you thought wrong!!! they use the model which
    they described to compare some modes of operation
  • So, no escaping the math people )
  • But let us skip it owing to time and my
    incapability to explain

92
Switch to the language of commons!!!
  • Examining the no pre-fetching scheme Users
    download at playback rate r and do not pre-fetch
  • Results
  • When S gt D, if peer-assisted schemes are used,
    server rate is close to video bit rate r
  • With a little surplus, even with no pre-fetching
    of data, server rate becomes lesser than r
  • Even when system scales big, in the surplus mode,
    r can be increased better video quality without
    significant increase in server bandwidth
  • Very useful because the difference is very
    obvious for even slight increase in r for
    bandwidth less than 1 Mbps

93
No pre-fetch scheme continued
  • Results Contd
  • Service provider must always increase r as much
    possible and keep the system in balanced mode
  • If you dont do that, someone else will, and you
    lose out says the laws of competitive
    economics
  • When S lt D, the server rate almost equals D S
  • When system moves from Surplus to Deficit, the
    Server resources increase dramatically
  • In balanced mode, when the number of users
    watching a video is small, no-pre-fetch does not
    do well

94
Prefetching
  • When you have surplus bandwidth, plan for the
    future
  • Note Server never does this It needs to
    minimize load and save it up for other videos. So
    all the pre-fetching is between pair
  • Which peer to select and dump data?
  • Water-leveling Lend to the poor new in the
    system
  • Greedy Give to the rich expecting them to
    donate too
  • Well, we do not run governments, so greedy works
    well too

95
Money Money Money !!!
  • Graph - Wow!!! Thats a straight line there
  • Table 1 - Large savings even if we have 3 times
    higher quality
  • Table 2 The effect wears off for less popular
    ones

96
What is in it for the ISPs?
  • Well, the answer is Nothing but problems!!!
  • More boundary crossing than within friends
  • Take the poor ISP into account Biased Peering

97
Thank you!!!Now that one is final. I am not
doing any more presentations for sure!!!And I
am out of the dais if no-one has anything to ask
About PowerShow.com