While CoolStreaming [32] and GridMedia [69] exhibit good performance and efficient stream distribution when there is ample bandwidth available, all users in these sys-tems observe poor performance when the resources are constrained. Because of lack of fairness and incentives mechanisms, even users who contribute significant band-width experience poor performance when there are insufficient resources to support all users.
While fairness in P2P file-sharing systems has been a much studied subject, few suggestions have been proposed to solve fairness in the context of P2P streaming.
One approach [38, 69, 17] uses the idea of substreams, and suggests that peers form substream-trading partnerships. Users who contribute enough bandwidth would be able to form enough partnerships to obtain the entire stream. However, forming re-liable partnerships is tricky. CoolStreaming[32] suggests that maintaining more than several substream subscriptions is costly, let alone finding partners to trade subscrip-tions with. In the approach of SubstreamTrading [38] a free-rider could pretend to
form a substream trade, and steal free bandwidth during a complex timeout-based evaluation period. The evaluation in [38], which is limited to simulations, experiments only with up to 10% of free-riders.
Ross et al. suggest to use multiple description coding (MDC) to encode the stream [36]. The more coding layers a peer can collect for a particular stream segment, the finer will be the viewing quality. The idea is that a particular peer does not need to collect all of the encodings to view a stream with a good quality and thus allowing some update miss rate is acceptable. However, this encoding scheme is very expensive and will require a user to download data at a very high rate even if not all of the encodings are to be collected.
Ross et al. suggest breaking up the stream into layers of granularity [37], where higher-bandwidth peers can collect more fine layers and, thus be rewarded with higher quality stream. The main drawback of this approach is that the higher granularity layers are useless to more poorly provisioned peers, and thus some of the more granular updates will only be available at a subset of peers, making the stream update exchange less efficient.
An improvement to Chainsaw [46] offers to augment a streaming system with several ad-hoc heuristics to allow high contributing nodes to receive a good quality stream. However, beyond their preliminary results, even their best suggestion results in high-contributors observing a 10% update miss rate, an unacceptable miss rate for video streaming.
SecureStream [23] suggests several security measures of dealing with data cor-ruption, as well as auditing peers using peer reputation or third-party auditors. Of course, peer-based reputation is susceptible to collusion where peers can exagger-ate one another’s reputation. Auditing requires third party participation, time to evaluate a peer, and selection of threshold parameters for a given scenario.
BAR Gossip [34], and its improvement, FlightPath [33], are probably the most elaborate suggestions to date. In these systems the time is split into short rounds, typically 1 second, during which pairs of peers exchange data. These systems enforce deterministic pseudo-random pairings of peers. In each round, each pair of peers exchanges an agreed amount of data, guaranteeing peerwise fairness. Deviation from the pairings or the exchange protocol constitutes a proof of misbehavior, or a POM.
Upon examining a POM the server can effectively kick a misbehaving user out of the system by broadcasting her id to the other peers. While these systems enforce fair or rational behavior via POMs, they have a number of drawbacks. The main drawback is that the system requires a large bandwidth overhead. If a peer is unlucky and it cannot get enough data in a single pairing, FlightPath allows multiple pairings for a peer in each round. As a result of these multiple data exchanges, FlightPath requires nodes to use 250 Kb/s upload bandwidth on average to transmit a 200 Kb/s stream.
Some nodes peak at 400 Kb/s, or 100% above the rate of the stream. Basically, these systems sacrifice efficiency for fairness. So while fairness is enforced the system can only guarantee a reliable transmission of a stream whose rate is not more than a half of the peers’ upload capacity. In the predecessor system, BAR Gossip, the peak may be as high as 200% above the stream rate. (This is primarily due to Bar Gossip’s requirement for a peer to send junk data when it has no useful data to send).
The second major drawback is that by enforcing this strict bandwidth exchange the system does not allow its excess upload capacity to be used to accommodate under-provisioned users. Although FlightPath allows up to 10% of peerwise imbalance in the amount of data exchanged and sacrifices strict fairness, this 10% is the limit on how much extra capacity can be allocated to accommodate users who are even temporarily under capacity.
FairStream guarantees that peers who contribute upload capacity at above the
streaming rate will be able to obtain and deliver the stream of good quality. In contrast to BarGossip and FlightPath, FairStream does not require any complex pro-tocols or encryption. FairStream uses no overhead beyond the data-sharing protocol overhead of 3-4%. In addition, any excess bandwidth in the system is allocated to accommodate other users. The small overhead of 3-4% comes from the auxiliary BitTorrent-like messages which peers use to notify one another of the stream updates that they have and to request these updates from one another.
FairStream leverages the efficiency of the BitTorrent-like data distribution tech-niques of the popular P2P streaming systems. Yet, it is able to augment these systems with fairness without sacrificing performance. Interestingly, while there has been much debate on how to improve BitTorrent’s request policy to improve performance (i.e whether to use in-order, rarest-first, or random) [32, 69, 24, 67], very little focus has been placed on the reply policy used by the P2P streaming systems.
While most systems ignore the evaluation of the reply policy or at best suggest a balanced first-come-first-served (FCFS) as in [48], FairStream explores the potential of the reply policy choice. In particular FairStream’s fair reply policy always picks a peer with a minimum deficit. This simple choice allows strong fairness properties and resiliency to strategic peers who try to garner more bandwidth by contributing little. FairStream accomplishes these properties without the need for peer reputation metrics or centrally scheduled data exchange.