3.2 Algorithm
3.2.1 Leecher Behavior
We first describe the basic algorithm run by the leechers. Let Sentij be the total number of bytes that a leecher Li has sent to a leecher Lj, and Recvij be the total number of bytes that Li has received from Lj. Each Li maintains a deficit variable DFij for each Lj, where DFij = Sentij − Recvij. Thus, a positive (negative) deficit implies that Li uploaded more (fewer) bytes to Lj than it downloaded from Lj. Initially, each DFij = 0. The values DFij are maintained in sorted order by Li in a
Li Leecher i
µi Upload rate of Li
Sentij Total bytes sent by Li to Lj Recvij Total bytes received by Li from Lj
DFij Deficit of Li with respect to Lj: DFij = Sentij− Recvij Senti Total bytes sent by Li to leechers RecviL Total bytes received by Li from leechers RecviS Total bytes received by Li from seeds
E(i) Instantaneous service error of Li: E(i) = Senti− RecviL
Max service error of Li
EM maxi(Emax(i)) Maximum service error.
block size Maximum message size Table 3.1: FairTorrent terminology.
list called SortedP eerList. When Li is ready to send the next data block, it chooses to send that block to the peer with the smallest DFij.
Procedure 3 shows the FairTorrent operation RecvBlock executed by Li when it receives a block from some peer Lj. RecvBlock checks that peer Lj is a leecher.
Subroutine ValidBlock is used to check the MD5 hash of the block. Just like BitTorrent, FairTorrent obtains the list of the MD5 hashes of all the blocks from the torrent metafile that it downloads prior to the download of the actual content file. If peer Lj is a leecher, and the block is valid, FairTorrent increments Recvij and decrements DFij by the number of bytes received from Lj, and re-inserts Lj into the SortedP eerList sorted from lowest to highest deficit values DFij.
Procedure 4 shows the FairTorrent operation SendBlock executed by Li when it is ready to send some data to its peers. Just like in BitTorrent, up to B bytes
Procedure 1 RecvBlock(peer j, data block p) if IsLeecher(j) and V alidBlock(p) then
Recvij ← Recvij + size(p) DFij ← DFij − size(p) SortedP eerList.ReInsert(j) end if
are sent at a time, where B is based on the peer’s upload capacity µi bytes/s. µi
is typically set by the user to limit consumption of bandwidth capacity. Send-Block tries to pick a leecher with the the lowest possible value of DFij and send a block, or finish sending a block, to that leecher. It examines the SortedP eerList starting at the lowest index, which contains the peer Lj with the lowest DFij. If currently Li has no pending request from Lj, (i.e. it has no useful data to send to Lj), or the connection is not writable, (i.e. there is no room in the TCP socket buffer), then the procedure examines the next peer on the list, with the next low-est deficit. SendBlock assumes the existence of several subroutines. HPRF(j), or HavePendingRequestFrom(j), returns true if there is a pending request from peer Lj. CWT(j), or CanWriteTo(j), returns true if there is room in Lj’s buffer to send a block. BytesRemainsToSend(j) returns the number of bytes remaining to send Lj from the current block being sent to Lj.
Once it selects a peer Lj to whom it can send data, FairTorrent tries to send a block, or finish sending remaining bytes of a block to Lj. The procedure can send a maximum of B bytes and the actual number of bytes remaining of the current block. FairTorrent uses blocks of size block size = 16 KB for simplicity, given the default 16 KB request size used by almost all BitTorrent-compatible clients. The subroutine SEND is used to write the actual bytes. SEND returns the number of actual bytes written, and decrements B, the bytes still available for further writes.
If a block is fully sent to Lj, i.e. BytesRemainsToSend(j)== 0, then FairTorrent
increments DFij with the size of the block sent, block size, and re-inserts Lj into the SortedP eerList. SortedP eerList maintains peers in the order of non-decreasing deficit values, and breaks ties based on the peer’s local random ordering of neighbors.
Procedure 2 SendBlock(allowed bytes B) n ← 0; sz ← Size(SortedP eerList) while (B > 0) and (n < sz) do
As SendBlock is the most important procedure in FairTorrent, we illustrate its behavior with an example of three leechers in Figure3.1. For simplicity, the example assumes leechers always have data to send to one another, expresses values in blocks rather than bytes, uses equal-size blocks, and breaks deficit ties by having each peer order its neighbors from lowest to highest peer ID. Leechers L1, L2 and L3 have upload capacities of µ1 = 3, µ2 = 2 and µ3 = 2 blocks/s, respectively. Thus, L1 sends a block every 1/3 of a second, L2 and L3 send blocks every 1/2 of a second. All peers send their first block at time 0.000. Figure 3.1 shows all the clock times at which at least one of the peers sends a block. Each peer keeps track of its deficit variables, DFij, shown underneath each peer at each clock time. Arrows show the source and
the destination of each block. At time 0.000, all the DFij = 0. Thus, L1 sends to L2. L2 and L3 each send a block to L1. When L1 sends a block to L2, it sets DF12 = 1.
Before time 0.333, it will have received a block from L2 and will have decremented DF12 back to 0. Thus, at time 0.333 DF12 = 0. Since it receives a block from L3 before time 0.333, it will set DF13 = −1. At time 0.333, L1 will send its next block.
Using procedure SendBlock, it will pick L3 as the peer to send the block to because it has lower deficit: DF13 < DF12. Thus L1 sends a block to L3 and increments DF13 to 0. Figure3.1 shows the process until the time 2.000. In these 2 seconds, each peer sent the maximum number of blocks limited by its capacity and received the same number of blocks from its neighbors. At time 2.000, the system reverts to the same state as at time 0.000. As we run for a long time period, the same behavior will repeat every 2 seconds and all deficit values will remain between −1 and 1.
In a distributed fashion, without knowing the neighbors’ capacities, FairTorrent achieved a convergence between each pair of nodes, and convergence between the total upload versus download rate for each peer. Counting the arrows between each pair of peers that indicate the number of blocks sent in the two second cycle, we see that L3 and L2 exchanged 3 blocks each with L1 (or 1.5 blocks/s) and they exchanged 1 block with each other (or 0.5 blocks/s).
It is interesting to consider how bandwidth allocations change for non-FairTorrent systems in this miniature example over time. Figure3.2 compares the bandwidth al-locations for the same example under four different systems: FairTorrent, BitTorrent, Block-based TFT, and PropShare. For each system the allocation is shown for each of the first four 10-second intervals, as the non-FairTorrent systems may readjust their allocations in the end of each 10-second round.
As shown in the above FairTorrent example, every 2 seconds L1 exchanges data at the rate of 1.5 blocks/s with both L2 and L3. L2 and L3 exchange data at the
Time: L1 (u1=3)
DF12= 0 DF13= 0 DF21= 0 DF23= 0 DF31= 0 DF32= 0 0.000
DF12= 0 DF13= -1 DF21= 0 DF23= 0 DF31= 1 DF32= 0 0.333
DF12= 0 DF13= 0 DF21= 0 DF23= 0 DF31= 0 DF32= 0 0.500
DF12= -1 DF13= -1 DF21= 1 DF23= 0 DF31= 1 DF32= 0 0.667
DF12= 0 DF13= -1 DF21= 0 DF23= 0 DF31= 1 DF32= 0 1.000
DF12= -1 DF13= 0 DF21= 1 DF23= -1 DF31= 0 DF32= 1 1.333
DF12= 0 DF13= 0 DF21= 0 DF23= -1 DF31= 0 DF32= 1 1.500
DF12= 0 DF13= -1 DF21= 0 DF23= 0 DF31= 1 DF32= 0 1.667
2.000 DF12= 0 DF13= 0 DF21= 0 DF23= 0 DF31= 0 DF32= 0
L2 (u2=2) L3 (u3=2)
Figure 3.1: FairTorrent algorithm for leechers L1, L2 and L3 with upload capacities of 3, 2 and 2.
rate of 0.5 blocks/s. The cycle repeats every 2 seconds, and thus these data exchange rates repeat every 10 second interval as shown in Figure 3.2(a).
Consider the same example using the equal-split rate heuristic of the original BitTorrent. The equal-split heuristic results in each peer splitting its capacity evenly among its neighbors, as in Figure 3.2(b). Unlike FairTorrent which quickly reaches convergence, the rates diverge when using the equal-split heuristic. Peers L2 and
L3 push 1 block/s to each neighbor. L1 pushes 1.5 blocks/s to each neighbor, but receives only 1 block/s in return from each. Thus, L1 receives 10 blocks fewer each 10-second interval.
Under Block-based TFT, L2 and L3 start by uploading 1 block/s to each peer, as in BitTorrent. L1 starts by uploading 1.5 blocks/s to each neighbor. However, L1 will not allow itself to upload more than it downloads from a neighbor by more than a certain threshold. Once the threshold with a peer is reached L1 will upload only as much as it downloads from the given peer. Assuming a threshold of two data blocks, for example, L1 will reach the threshold with each peer after 4 seconds, and then reduce its rate to 1 block/s to each neighbor. Thus, over the first 10 seconds L1 will upload at an amortized rate of 1.2 blocks/s to each neighbor, as shown in the first interval of Figure 3.2(c). In the subsequent intervals L1 will continue to upload at a rate of 1 block/s. Although the data exchange rates between all peers convergence to 1 block/s, the system under-utilizes the total upload capacity as compare to other systems, because L1 will upload 20 blocks each subsequent round instead of the 30 allowed by its upload capacity.
Consider the same example using PropShare. Each peer begins in the first 10-second round by uploading at the equal-split rate, then adjusts its rate proportionally to the exponentially weighted rate received in the recent four rounds. Thus, L2 and L3 send blocks to L1 at the rate of 1, 1.2, 1.28, and 1.31 blocks/s in each of the first four 10-second rounds respectively. This progression is depicted in Figure3.2(d).
While FairTorrent reaches convergence and 0 deficit in 2 seconds, after 40 seconds using PropShare, L1 will have accumulated a deficit of at least 24 blocks and will still not have converged even in this miniature example. This example shows that the convergence of exchange rates under PropShare can be quite slow. In addition, in a larger PropShare network, as each peer changes its active set of peers, or the set of
L1 bandwidth allocations in blocks/s between these peers over the first four 10-second intervals under four different systems: (a) FairTorrent, (b) BitTorrent’s equal-split, (c) Block-based TFT and (d) PropShare. For Block-based TFT we assume a threshold limit of 2 data blocks.
neighbors it uploads to, the exchange rates may take even longer to converge or even diverge.