We start by generating a GNR(n) mesh, i.e., a mesh in which each peer is given n .... additional class 1 peer but because of its special status and behaviour (it ...
Adaptive Overlays: A Feasibility Study Richard Lobb, Ana Paula Couto da Silva, Emilio Leonardi, Marco Mellia, Michela Meo
ABSTRACT This report proposes and investigates a simple fully-distributed mechanism for constructing and maintaining the overlay topology in mesh-based P2P-TV systems. Our algorithm optimizes the topology to better exploit large bandwidth peers, so that they are automatically moved close to the source. This improves the chunk delivery delay so that all peers benefit, not just the high bandwidth ones. A key property of the proposed scheme is its ability to indirectly estimate the upload bandwidth of peers without explicitly knowing or measuring it. Simulation results show that our scheme significantly outperforms overlays with homogeneous properties, achieving up to 50% performance improvement. Moreover, the algorithm is robust to both parameter setting and changing conditions, e.g., peer churning.
1. Introduction Peer-to-peer Live Streaming (P2P-TV) systems are candidates for becoming the next Internet killer applications, as testified by the growing success of commercial systems such as PPLive, SopCast and many others. These systems, which allow users to “watch television” over the Internet, have very low infrastructure costs, enabling almost anyone to become a content provider to the whole world. Freed from normal broadcasting constraints, any user can potentially watch any content anywhere. In a P2P-TV system, hosts running the application, called peers, form an overlay topology by setting up virtual links over which information is transmitted and received. A source peer is responsible for injecting the video stream, by chopping it into segments called chunks of a few kilobytes, which are then sent to a subset of its neighbouring peers. Each peer can then contribute to the chunk diffusion process by retransmitting chunks to its neighbours following a swarming like behaviour, as in file sharing P2P systems like BitTorrent. The major differences between P2P-TV systems and traditional P2P file sharing applications are i) that the source is generating the stream in real time, ii) that data must be received by peers at constant rate, and iii) that chunks must arrive almost in sequence so that they can be immediately played at the receiver. Therefore, the main performance indices to be optimized in P2P-TV systems are the chunk delivery delay, i.e., the delay from when the source emits the chunk to when a peer receives it, and the chunk loss rate. To this extent, typical P2P file sharing applications mechanisms, such as BitTorrent’s tit-for-tat algorithm, are not well suited to this scenario, since they target throughput optimization rather than delay. In this report we consider unstructured (mesh-based) P2P-TV systems, focusing our attention on the design of efficient distributed mechanisms for the construction and the maintenance of the overlay topology, given nodes with heterogeneous upload bandwidths. The performance of these P2P-TV systems is mainly determined by two mechanisms: the scheduling policy with which a peer decides which chunk to distribute to which of its neighbours; and the overlay construction, which determines the neighbourhood of each peer, i.e., the topology over which chunks are distributed. Several works have focused on chunk scheduling algorithms [1, 2, 3, 4, 5, 6], devising, proposing and analyzing numerous different ‘optimal or near optimal’ methods. For the case of bandwidth-heterogeneous networks it has been shown that it is important to preferentially distribute chunks to high-bandwidth nodes first, so that chunk replication occurs as rapidly as possible [4, 5]. From a chunk-scheduling perspective, a fully connected overlay is theoretically ideal in that a peer can then always make an optimal choice of peer as target for any chunk. From a practical standpoint, however, maintaining large neighbourhoods increases the complexity of the scheduling algorithm, forces each peer to maintain a large amount of information and wastes bandwidth since peers have to frequently exchange signalling messages with all their neighbours. Hence it is essential to restrict the overlay topology so that each peer has only a limited set of neighbours available.
–1–
The overlay has to adapt to the peers’ resources (e.g., bandwidth), to the “churn” of peers, and to variations in network status. In this report we propose a simple distributed algorithm to achieve these goals and we show that we obtain significant performance improvement of up to 50% with respect to static overlays. Our scheme does not need an a priori knowledge of each peer’s upload bandwidth, but simply responds to its observed performance, measured in terms of how many other peers it is able to serve. It thus reacts appropriately when a peer’s performance is substandard, e.g., due to high CPU load or network demands from other applications. The problem of the overlay topology optimization in mesh-based P2P-TV system has been almost neglected in the literature. To the best of our knowledge, apart from [9], performance of mesh-based systems has always been analyzed assuming the overlay topology to be either a fully connected mesh or a static random graph with given degree. In [9] the problem of building an efficient overlay topology has been formulated as an optimization problem. However, the proposed approach, which is deterministic and assumes perfect knowledge of the overlay edge costs, appears impracticable for large unstructured P2P-TV systems. Furthermore, the considered scenario in which the stream delivery delay is mainly due to the transport network latency differs significantly from the scenario considered in this paper and more-commonly adopted in literature [1, 2, 3, 4, 6] where system performance is constrained by peer upload bandwidth.
2. The Algorithm We start by generating a GNR(n) mesh, i.e., a mesh in which each peer is given n random neighbours, so the degree is approximately 2*n. Currently we mainly use n = 5. We then initiate push-based chunk diffusion, using a modified LATEST_BA strategy in which the probability of selecting a neighbour as a target for the latest chunk is some function of the neighbour's upload bandwidth (see section 3). During diffusion, each peer independently scans and adjusts its neighbourhood every n received chunks1, where n is typically around 50, as follows. On each scan, compute the number of unused links in the current neighbourhood as a percentage of the number used. If the number is less than LOW_TIDE_PERCENT, construct the set of all the neighbours of the peer's existing neighbours and select new neighbours from that set. If the number is greater than HIGH_TIDE_PERCENT, cull a suitable subset of the existing neighbours. In detail, the algorithm is: adjust_neighbourhood: used_links = all out-links used since last call unused_links = all out-links unused since last call min_unused = max(1, used_links.size() * LOW_TIDE_PERCENT / 100) max_unused = used_links.size() * HIGH_TIDE_PERCENT / 100; if (unused_links.size() < min_unused) // Need to grow neighbourhood growth_factor = max(0.1, 0.4 * (1 – t / Tstartup)) Note 1 num_links_wanted = max(1, used_links.size() * growth_factor) candidate-set = empty for each out-link // Loop to find all neighbours' neighbours candidate-set += out-link.peerAtEnd.getAllNeighbours() candidate-set -= (this.getAllNeighbours + this) Note 2 num_to_take = min(num_links_wanted, candidate_set.size()) new_neighbours = stochastic_select(num_to_take, candidate-set) for each new_neighbour out-links += link to new neighbour
Note 3
else if (unused_links.size() > max_unused) // Need to shrink neighbourhood for each link in unused_links
Note 4
1
Synchronisation of neighbourhood adjustments is avoided firstly because the randomisation of bandwidth ensures that chunks arrivals are themselves not synchronised and secondly because the chunk-number at which each peer performs its first neighbourhood adjustment is a random number in the range 0 to n-1.
–2–
if link.peerAtEnd.num_in_links()
