Incentives Build Robustness in BitTorrent

• p. 1 Section 1, paragraph on primary contribution

  We evaluate BitTyrant performance on real swarms, establishing that all peers, regardless of upload capacity, can significantly improve download performance while reducing upload contributions.

• p. 9 Section 5.1

  We imposed a 128 KB/s upload capacity limit on each client and compared completion times.

• p. 9 Section 5.1

  We expect relative performance gains to be even greater for clients with greater upload capacity.

Judge's note: Read page 1 and page 9. Section 5.1 and the Figure 10 caption give a single 128 KB/s cap for the 114 real swarms. Page 9 says "We expect relative performance gains to be even greater for clients with greater upload capacity" and that sensitivity to upload rates is evaluated on PlanetLab. Page 9 also says BitTyrant "cannot always improve performance". The intro sentence can be read loosely as summarising the whole evaluation, so this is an overstatement in wording rather than a data error.

Second check: another model agreed

• p. 4 Figure 2, y-axis and curve (about 900 s at 8000 KB/s, about 650 s at 6400 KB/s)

  Expected TFT matching time (s)

• p. 14 Appendix A, text before Equation 9

  T = 30s is the period after which optimistic unchokes are switched

• p. 14 Table 2, row active(r)

  Size (in peers) of the active transfer set for upload capacity rate r

Only the authors can say what is right here.

Judge's note: Read the Figure 2 image on page 4: the y-axis tops out at 900 and the curve reaches about 900 s at 8000 KB/s and about 650 s at 6400 KB/s. Equation 9 on page 14 is T·active(r)·(bracket). Writing q = S(s)^(2ω), the bracket as printed is the sum over n of n(1−q^n)q^(n(n−1)/2); this equals 1 at q = 0 and is above 1 for 0 < q < 1 (about 1.10 at q = 0.1, about 1.64 at q = 0.5). So the result is at least 30·active(r): 2010 s at r = 8000 and 1770 s at r = 6400, more than double the plotted values. The Section 3.1 example (6,400 KB/s, "more than 4 GB") matches the figure, since 6400 KB/s × 650 s is about 4.2 GB. Figure values were read by eye, but the gap is far larger than reading error. Only the authors can say whether the figure used a different T, active-set size or formula.

Second check: another model agreed

• p. 7 Section 4.1, paragraph beginning "In both BitTorrent and BitTyrant"

  unchoked in order until the sum of up terms for unchoked peers exceeds the upload capacity

• p. 7 Figure 9, under-brace annotation

  choose k | ∑ki=0 ui ≤ cap

Judge's note: Read both on the page 7 image. The under-brace in Figure 9 reads "choose k | sum_{i=0}^{k} u_i ≤ cap", and the line above it says "until the upload capacity is reached". Read literally, the prose includes one more peer than the pseudocode. The prose is probably loose wording, so this is a minor inconsistency.

Second check: another model agreed

• p. 14 Appendix A, Equation 1

  p recip(rP , rQ) = 1 −(1 −S(rP ))active(rQ)

• p. 14 Table 2, row S(r)

  Cumulative probability of an equal-split rate r

Only the authors can say what is right here.

Judge's note: Read Equation 1 and Table 2 on the page 14 image. The lead-in defines rP as P's upload capacity. Section 3.2 (page 4) says Q does not reciprocate if all other peers in its active set send at rates greater than P's; P's sending rate to Q is split(rP). Reworking the step: the probability that one competitor sends faster is 1 − S(split(rP)), so reciprocation is 1 − (1 − S(split(rP)))^active(rQ). The form of the equation is right, but the argument as printed is not on the equal-split scale. Equations 6 and 9 make the split() conversion explicitly. The authors probably intend an implicit conversion, so this is a notation fault and the stated result stands.

Second check: another model agreed

• p. 14 Appendix A, Equation 8 and its lead-in

  Probability of a peer with rate r discovering matched TFT peer in n iterations

• p. 14 Appendix A, Equation 9

  n c(s, n)

Only the authors can say what is right here.

Judge's note: Read Equations 8 and 9 on the page 14 image and reworked them. Let q = S(s)^(2ω). Under the Equation 8 definition, the probability of first success at iteration n is q^(n−1)(1−q), and the expected number of rounds is 1/(1−q). Equation 9 as printed uses the weight (1−q^n)·q^(n(n−1)/2). The reviewer's statement that these weights are not a probability distribution is incorrect: they telescope and sum to 1. They are, however, the distribution for a process whose success probability at round n is 1−q^n, not for the cumulative definition in Equation 8. Check at q = 0.5: the n = 2 weight is 0.375 as printed against 0.25, and the printed sum is about 1.64 against an expectation of 2. So Equation 9 is not the expected number of rounds under Equation 8 as defined. The authors should say which reading of c is intended.

Second check: another model agreed

• p. 1 Section 1, right column, paragraph beginning "How does use of BitTyrant"

  due to the absence of altruisitic contributions

Judge's note: Checked on the page 1 image, right column, paragraph beginning "How does use of BitTyrant". The misspelling is in the typeset text, not an extraction artefact.

Second check: none (judge only)

• p. 12 Section 5.2, paragraph beginning "To work around this last effect"

  whose block request rates exceeds their send rates

Judge's note: Checked on the page 12 image, Section 5.2, paragraph beginning "To work around this last effect". The wording is as printed.

Second check: none (judge only)

• p. 14 Table 2, row B(r)

  Cumulative probability of a upload capacity rate r

Judge's note: Checked on the page 14 image. The parallel S(r) row uses "an equal-split rate r".

Second check: none (judge only)

• p. 14 References, entry [15]

  L. Massoulié; and M. Vojnović.

Judge's note: Checked on the page 14 image: the semicolon after "Massoulié" is printed. Reference [19] prints "L. Massoulié." without it.

Second check: none (judge only)