All started from bit torrent! Distributed trackers DHT. Torrents have incentive, the more you upload the faster you get the file. Tit-for-tat.
Incentives for live streaming over p2p.
There aren't many incentives as yet because why upload at full band width if you're getting video at full rate. Introduce tit-for-tat download where u get better quality for better upload rate. This can be done be measuring speeds coming from neighbours and reciprocate upload rates to them based on their rates.
Paper - IPTV over P2P Streaming Networks: The Mesh-Pull Approach
To date, IPTV over P2P streaming networks has advanced significantly using two different approaches: tree-push versus mesh-pull.
System overview (mesh pull)
In a mesh pull system a video is divided into media chunks and is available on a video server. When a host is interested in viewing the video, it requests the available streams from the channel server. The tracker server keeps a list of users watching the same video. This information is relayed to other user, to enable them to help each other out and deliver video traffic as a group. Each host watching the video is able to connect directly to the server or just relay data to/from other users. At every host, several minutes of video chunks are cached using a sliding window and these chunks can be shared with other host watching the same video. This works by sharing buffer maps between users. Buffer maps contain the chunks presently available on a certain host. By sharing these maps, all the host know where it can find the missing/next chunk needed and it can request (pull) this chunk from the corresponding users. Each host will continually check for new partners from where it can download new chunks.
Software components
The peer software includes a P2P streaming engine and a media player. The streaming engine needs to retrieve chunks (from other users of the server), store the chunks in a cache, share these chunks with its partners and relay these chunks to the media player.
Mesh-pull streaming similar to bit torrent
Mesh pull architecture is very similar to that of bit torrent, though bit torrent is not suitable for video streaming because it does not account for real time requirements. Since bit torrent is mainly used for file transfer, there can be delays and jitter in the arriving packets. This obviously has to be done differently in IPTV streaming. One drawback encountered in mesh-pull system is fair resource management. Bit torrent employs a tit-for-tat system, whereas users with high upload and which share useful data are given more download speed and priority by other users. This fair resource sharing has not been addressed carefully in the current mesh-pull system. This leads to the lack of incentives for users to share their video stream. Why would one need to allow a high upload bandwidth when he can get the same quality with limited upload? This leads to a whole new topic in P2P systems which tackle various incentives for users. This will be discussed in section X.
System scalability: construction costs
In these mesh-pull systems, user's capabilities differ significantly, especially in terms of upload bandwidth available. In additions, peers may randomly join and leave the system after random time. These lead to two important factors in P2P systems which are peer heterogeneity and churn. These 2 factors are the major challenges in P2P IPTV systems, as one needs to provide fair service to all users with acceptable QOE and QOS. Usually peers are split into ordinary peers and super peers. These are split automatically by the system depending on the user's upload and the amount of time he is online. Super peers may be able to act as mini-servers to other users, but this leads back to the problem of why would one want to become a super peer for nothing? One might argue that a good incentive will be to provide super peers with a higher quality video, and they can relay a lower quality video to ordinary peers.
Video Playback QOS toward QOE
IPTV viewing experience is crucial for a successful system. If users experience frequent freezes, large start up delays or time lags between live events, they may use another service. Buffering will significantly improve video quality, though this will also lead to delays. Therefore a good comprise needs to be taken. Start up delay is the time from when the user selects a video and the actual streaming starts. This delay is necessary for buffering, though a large delay will reduce the QOE. Another major disadvantage of P2P systems is time lags between users and the actual event. This is particularly clear during a live football match, where some users would be minutes ahead of others. Apart from not being ideal, this will also affect the P2P architecture itself, because users with a high lag will not be able to relay useful chunks of data to other users which are ahead.
Systems also have playback deadline. When a media chunk does not arrive before its deadline, the media player can either freeze the current framer until the next frame arrives, or it skips the missing frames and resumes from the next available frame. This both lead to lower QOE.
Optimization for QoS
To address these issues discussed some optimization are discussed. The first one is to reduce the start-up delay. A simple advertisement pre loaded on the users application may be players when a new video is selected. This gives the impression that streaming started right away. This also leads to revenue form advertisement for the provider. Another system is to play a low quality video at first directly from the server. When the neighbours are found, the user can download high quality video from other peers. This can also be used when the peer network needs to be reconfigured (due to many users leaving the system etc). Instead of freezing frames, a low quality video direct from the server is requested until new peers are found.
Tree-push, mesh-pull, push-pull
Mesh-pull systems have had significant success in commercial deployments while Tree-push system have been largely running at research stage. Mesh-pull systems suffer from log start-up up delays, switching delays and large lag times. On the other hand tree-push systems do not suffer from these high delays though they may suffer from peer churn. This is when a user disconnects from the system and the tree needs to be reconfigured.
Opportunities and Challenges of Peer-to-Peer Internet Video Broadcast - Jiangchuan Liu, Sanjay G. Rao, Bo Li, and Hui Zhang
At first IP multicast architectures were used. However these had problems, especially regarding scalability and the shear amount of bandwidth required to provide quality video to many users. In recent years there has been significant improvement in the use of peer-to-peer technologies for video streaming and broadcasting. The two main advantages of using P2P are that such technology is very cost effective and easy to deploy. This is because when a user starts a video stream he is not only downloading data but is also uploading data to other users watching the same stream. This has the potential to scale up to en enormous size with only a fraction of the cost of IP multicasting, since greater demand in turn generates greater resources.
P2P technologies have been used in a wide range of applications such as Voice over IP (VOIP) and file download such as bit torrent. Video broadcast though, offers a very different challenge since it requires real0time performance and needs high bandwidth and low latency. In bit torrent the objective is to download a file, but as this is split into multiple segments, these can be downloaded out of order at very different speeds from multiple users. This obviously cannot happen in real-time video streaming.
Two solutions have emerged for P2P architecture, namely tree-based (tree-push) and data-driven randomized approaches (mesh-pull).
Comparison of Broadcast architectures
IP multicast
IP multicast reflects the basic design principles of the internet. This is implemented in the IP layer. Although pushing to higher layers can enable better functionality, it was found tat implementing at this layer achieves a far better performance. Despite the effort put in this architecture in the past, this system is very limited and rarely used. IP worked well in the unicast context, though provided features such as error, flow and congestion control has been more difficult in multicast.
Peer-to-peer architectures
There are two main architectures that may be used in p2p. This first one is infrastructure-centric architecture. This is when an organization deploys proxies at strategic locations on the internet. Users can than connect to the nearest proxies and receive unicast data. This is also referred to as Content Delivery Networks (CDNs), and has been used by Akamai. [ [i] ]
"Akamai's EdgePlatform has 73,000 servers across 70 countries and handles a significant portion of the world's Web traffic. EdgeComputing Deliver Web-based applications that scale on demand and perform faster and more reliably worldwide."
The second architecture is application end-point architecture. This is P2P at its best, where functionality is pushed to end users that are in the current multicast group (watching the same stream). Administration and maintenance s of the system is now distributed among the user's via a peer-to-peer system, instead of being handled by a remote server. The main reason for using the p2p paradigm is the ability to use the bandwidth resources of the end nodes participating in a multicast group when new participants join the group, they not only require bandwidth from other user but themselves contribute their upload to other users.
These end-point architecture are omni-present and can be setup instantly with minimal cost. On the other hand centralized architectures can proved more robust connections using dedicated and reliable proxies. End-point architectures may also have users which do not provide good performance (have a low upload bandwidth and leave and rejoin randomly) and these have a significant impact on the system. Thus, end point architectures need to be able to scale and self-organize efficiently without a central server and its overhead.
Peer-to-Peer Video Broadcast
Contrast from other P2P applications
A video broadcast system typically has a server which provides the stream and is present throughout the session. New users join with this server and then can form smaller groups to share data between themselves. The system needs to be:
Large scale: able to handle thousands of users simultaneously
High bandwidth: needs to have a high upload for the demanding video stream.
Real-time considerations: employ real time protocols such as RTP and RTCP over UDP to provide efficient real time streaming of data. Although minor buffering delays are tolerated (unlike in VOIP or Gaming which are interactive) there still needs to be efficient delivery of data without jitter or unnecessary delays.
Degradable quality: system needs to be able to deliver different quality of video depending on the user's bandwidth limitations.
The above characteristics show that real time video streaming differs from other p2p applications namely on-demand streaming, interactive video and file download. On demand streaming does require a lot of bandwidth and minimal delay and jitter though users here are asynchronous. Interactive video are more critical to latency issues but these are typically implemented in a smaller scale and between a small group of users, example Skype. P2P file download applications such as bit torrent do not require stringent real time delivery. In torrenting, the order in which a file arrives is not important and it can also take hours or even days to download a file which is not shared by many users,
P2P design issues
The main problem with p2p video broadcast is organising the end users into a high quality overlay. The following are important characteristics that need to be taken into consideration for overlay construction.
Overlay efficiency: high bandwidth and low latency are required, though a start-up delay can be tolerated.
Scalability: large number of users need to be supported.
Self-organizing: system must be robust to changes in groups (users connect and disconnect randomly)
Bandwidth control: ensure that each user cooperates with other users, and no one leeches high data rates without uploading any good data back to the system. Also consideration must be taken for users with limited bandwidth capabilities.
Overlay construction
Tree Based Approach
In this approach, peers are organised into a tree structure, with each parent node having children. This is a push architecture, since data is pushed down from higher up nodes to lower ones. This structure needs to be maintained. A node may leave the system or provide bad performance. This in turn will affect all of its children. The higher up the failure in a tree, the more nodes it may affect and this may lead to the disruption of data to many users. Another disadvantage of this system is that users on the lower end of the tree will not be utilizing their bandwidth.
Data driven approach
This approach uses mesh-pull architecture. Nodes will locate the nearest nodes which are watching the same stream. These nodes will exchange data information between them, so that every node in vicinity will know where it can get new chunks of data, and which node needs a chunk. Nodes will pull the needed chunks of video from a node which has that chunk. This system is also robust to failures since if a peer decides to leave the system, one can easily get the data from another user. This approach is very similar to that of bit torrent. The main difference is that real-time constraints apply, and segments need to be obtained efficiently.
A gossip algorithm can also be used and this is a push method. In this approach, nodes send "gossip" messages to randomly selected nodes, and these nodes will do the same until the message is spread to all nodes. This method for distributing data is not good for video streaming though since this random pushing will lead to significant delays and jitter.
The data driven approach at first sight may appear similar to techniques used in file download solution like bit torrent. However, the crucial difference here is that the real time constraints imply that segments must be obtained in a timely fashion.
