Taming the Torrent:
A Practical Approach to Reducing Cross‐ISP Traffic in Peer‐to‐Peer Systems David R. Choffnes and Fabian E. Bustamante Presented by: Alan Dunn Topics in Network Protocol Design April 9, 2010Outline
• Motivation• Background – BitTorrent and CDNs • Approach – How to use CDNs
Motivation
• Peer‐to‐Peer (P2P) traffic is a significant portion of all Internet traffic (70%? Cited study omits North America, Asia…) • Largest P2P network: BitTorrent • BitTorrent traffic effect on ISPs: –+$: Users acquire broadband to use BitTorrent –‐$: BitTorrent traffic is potentially costlyMotivation (cont’d)
• ISPs want way of managing cost of BitTorrent but keeping income • Throttle traffic? –Difficult to maintain, anger users –Questionable legality • Cache content? –Extra equipment cost –Also questionable legality…Motivation (cont’d)
• Lessen traffic impact? –In particular cross‐ISP traffic – links to other ISPs can be bottleneck, may cost • How to decide which peerings lessen cross ISP traffic? –AS number? Some ISPs have many… –ISP‐based oracle • ISP service ranks peers by its preference • But ISPs have to run these, users have to trust themCDN Redirection as Oracle
• Content Distribution Networks (CDNs) redirect traffic based on connection quality • Advantages: – ISPs don’t have to commit extra resources (though get less direct control) – Users don’t have to trust ISPs • Paper’s goal: – Show how to use CDN redirection as an oracle – Empirically evaluate that this reduces cross‐ISP trafficBackground: BitTorrent
Main architecture pieces: • Torrent – File metadata • Trackers – Distribute peer sets for files • Peers – Hold file data, transfer to each otherBackground: BitTorrent (cont’d)
Tracker (1.2.3.4) music.torrent: Tracker: 1.2.3.4 Piece length: 2^18 Piece hashes: ff0123…, 789ebc…, … 1. New peer downloads torrent Peer New Peer 2 3 4 2. Peer contacts tracker 3. Tracker assigns peer set “music.torrent please” I am peer 4 music.torrent: Leechers: 2,3 Seeds: 1 Contact 1,2 4. Connect to peers “Hello” 5. (Optional) Bitmap of pieces “I have pieces 1, 2, 5, 7” 6. Requests, pieces, interest, choking music.torrent: Leechers: 2,3, 4 Seeds: 1BitTorrent: Protocol Lessons
• Tracker keeps little information about peer status, but controls peer knowledge of other peers • Peers have complete control over where they fetch pieces when they know peers exist • How to “prefer” some peers: –Ensure you are connected to them always –“Tit‐for‐tat” allocation: Ensure they have more bandwidth available from youBackground: CDNs
• CDNs contain copies of content dispersed at different network locations • Request for content leads to redirection to selected CDN servers –Eg: via URL rewriting, DNS redirectionHow a CDN redirection works:
Source: Drafting Behind Akamai, by Su et. al. (includes current paper’s authors)Background: CDNs (cont’d)
• Prior work: CDN servers (Akamai specifically) returned track live network conditions (minimize RTT) • PlanetLab nodes used to repeatedly query domains served by Akamai (every 20 s) • Retrieved servers were pinged (every 5 s) • List of top ten (by lowest RTT, 9 = best, 0 = worst) tracked over timeBackground: CDNs (cont’d)
• Calculated rank of Akamai’s picks in the RTT lineup • For some nodes, Akamai picked particularly well (here 14 or more 90% of the time) • Low‐level Akamai DNS reporting to Brazilian PlanetLab node was known to have bad redirection timesHow to use CDNs
• DNS query for CDN served sites • Keep track of result of DNS queries for a specific name • Measure similarity between query results for different BitTorrent peersHow to use CDNs (cont’d)
• Ratios per BitTorrent peer per site form a map • CDN servers cluster by /24 prefixes • Example (here using raw numbers not ratios): Peer 1 resolves a20.g.akamai.net: Results: 192.124.226.40, 192.124.226.27, 192.124.250.5, 192.124.250.1, 192.124.226.40 ‐> <192.124.226.0/24: 3, 192.124.250.0/24: 2>How to use CDNs (cont’d)
• Similarity between peers calculated via “cosine similarity” a.k.a. “dot product of unit vectors” Peer 2 resolves a20.g.akamai.net: ‐> <192.124.226.0/24: 4, 192.124.250.0/24: 2, 192.124.91.0/24: 1> Peer 1 resolves a20.g.akamai.net (from before): ‐> <192.124.226.0/24: 3, 192.124.250.0/24: 2> Similarity: = (3*4 + 2*2)/(sqrt(21)*sqrt(13)) ≈ 0.968 | || |a b b a•How to use CDNs – Extra Details
• Threshold for selection: 0.15 – For reference, in 2D: angle < 81.4⁰ • Map contents account for age: – 1) Exponentially decay all entries – 2) Increase query result to where ratio sum is 1 • Adjusting query interval – Start with bootstrap phase: Every 30 s for 2 min – Increase by 1 minute each time no change – Decrease by half each time change occurs (minimum: 30 s)How to use CDNs – Efficiency
• OK to use CDNs this way? (Not their intended purpose…) –Low bandwidth (18 KB up, 36 KB down per client per day) • Though low bandwidth does not necessarily imply low load on CDNs (eg. CPU load)… –CDN selection strategies may changeEvaluation – What to measure
• How “cross‐ISP” is traffic? – Number of IP hops, AS hops – Sufficient? (Authors themselves comment on # AS hops != # ISP changes, but then measure this anyway…) • Route quality – Important for adoption by users – RTT, packet loss rate, throughput • Differences between different CDN sites (“quality of different oracles”)Evaluation
• Plugin “Ono” for BitTorrent client Azerus (now Vuze) • Performs CDN DNS lookups –Even on behalf of non‐Ono peers to make up for number of Ono users (adds measurement error?) • Measures throughput, latency, routes (via traceroute) for each peer connection
Degree of Cross ISP Traffic
• Each point is avg. hop number for Ono‐ recommended or total peers over six‐hours • Single CDN site resolution used (LeMonde.com)Route Quality – RTT and Loss
• Seems to confirm that CDN locating correlates with latency• Connections in data have reached 4 KB/s at some point • Ono: “Significantly” higher peak rates (not shown) • Average dl: 31% higher, Median actually ~ 2 KB/s less than standard • Problem is BitTorrent uses many low‐bandwidth connections instead of few high‐bandwidth ones
