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