BitTorrent
Transcription
BitTorrent
30/08/2011 RES 224 Architecture des applications Internet P2P: BitTorrent dario.rossi Dario Rossi http://www.enst.fr/~drossi RES224 Plan • Acteurs et fonctionnement général – Swarm, torrent, tracker, seed, leecher, chunks, ... • Algorithmes et performance – Strict priority, Rarest first, Tit for tat, Anti-Snubbing, End-game mode, Chocking/Unchocking, … – Note: On ne regardera ni le type ni le format de messages • Bilan – Efficacité vs complexité • References • LEDBAT: control de congestion BitTorrent – Pas objet du controle 1 30/08/2011 Principes du partage en P2P • • Plusieurs méthodes pour localiser une ressource: – Méthode distribuée • Contact direct entre chaque utilisateur • Gnutella, eDonkey, Skype, ... – Méthode centralisée • Contact établi par une entité • Napter, Bittorrent , ... Plusieurs méthodes pour rapatrier la ressource: – Méthode atomique • Peu efficace: ressource rapatriée en entier à partir d'un seul peer • Napster, Gnutella (initiellement), … – Méthode parcellisé • Très efficace : Ressources rapatriées de plusieurs peers (en parallèle) • BitTorrent, eDonkey, P2P-TV,… Principes de BitTorrent Leecher File chunks Chunk transmission Messages over: •TCP (old) •UDP/LEDBAT (new) 2 30/08/2011 Terminologie • Torrent – Point de depart – Fichier descriptif de la ressource, contenant aussi l’addresse IP et numero de port TCP d’un tracker • Tracker – Bootstrap server – Elément central qui permet aux peers de prendre contact les uns avec les autres (ne possède pas la ressource) • Swarm – Ensemble des peers participants au partage d’une meme ressource – Consititué par plusieurs types de Peers • Leecher : Peer qui télécharge • Seed : Peers qui upload seulement (possède une copie complète) Terminologie • Parcelisation – Permets plusieurs échanges simultanées: • Upload des chunks dès qu’on les possède • Download les chunks qu’on ne possède pas – Le fichier partagé est divisé en plusieurs parties égales • Appelées Chunks (typiquement 256Ko) – Divisés à leur tour en plusieurs morceaux • Appellés Pieces (15Ko) 3 30/08/2011 .torrent • Fichier .torrent – Necessaire par un peer pour participer au partage d’une ressource (e.g., fichier de données) avec BitTorrent – Localisé avec une methode indépendante de BitTorrent (en général stoqué sur serveur Web) • Ce fichier contient: – Liste des chunks (pour savoir qu’est qu’il faut telecharger) – Mapping entre les différents chunk (pour reconstruire le fichier ensuite) – Checksum des chunk (pour en vérifier l’intégrité) – L’identifiant d’un tracker (adresse IP/numéro de port) • Multi-tracking • Trackerless (Kad DHT, Peer Exchange PEX gossiping) Tracker • Role: connaître les adresses IP et numero de ports des peers: – Restituer une liste partielle de peers pour un torrent – Aucune préférence, environ 50 peers choisis aleatoirement • Meilleurs choix sont possibles: e.g., selection basée sur la proximité des peers, ou distance inter-AS (IETF ALTO) • • Ne posséde pas d’information relative: – Aux chunks que chaque peer possède – A la capacité d’upload des peers Les mises à jour avec le Tracker se font par les peers : – Périodiquement (environ 30 min) – Au premier contact (bootstrap) – Quand un peer quitte le systeme – Quand un peer a besoin de nouveaux peers 4 30/08/2011 Swarm • Le swarm a un but – améliorer les performances de téléchargement • Pour cela, deux objectifs precis: – Optimiser le temps de téléchargement du fichier • plus de seed = plus des sources potentielles – Contraindre les leechers au téléchargement • Obliger au partage: pas d’upload, pas de download! • Pour cela, deux moyens – Le choix des chunks (et des pièces) à télécharger – Le choix des peers avec lesquels on échange Algorithmes • Pipelining: – Utilisation de requêtes multiples pour soin de performance: ouverture de plusieurs connections en parallèle (environ 5) – Chaque connection telecharge des pieces • Selection des pieces: – augmenter la disponibilité (Rarest First) et la rapidité d’obtention des chunks (Strict Priority, Random First Piece) • Selection des peers: – Tit for tat = résoudre le dilemme du prisonnier • Travailler pour le bien de tous pour améliorer ses propres performances (optimistic unchoking) • Pénaliser ceux qui ne répondent pas à cette règle (choke, anti-snubbing) 5 30/08/2011 Pieces: Strict Priority • But: – Obtenir le plus vite possible des chunks complets • Fonctionnement : – Si on envoie une requête pour une pièce d’un chunk – Alors on devra envoyer des requêtes pour les autres pieces du meme chunk en priorité aux autre chunks • Interet – L’upload n’est possible qu’une fois le chunk totalement téléchargé – Enfait, seulement une fois le chunk téléchargé on peut verifier son integrité et validité (checksum dans le .torrent) Chunks: Rarest First • But: – minimiser les chevauchements (overlap) des chunks Non chevauchement Chevauchement • Interet: – Equalization des ressources • pas de “hotspot” i.e., de ressource peu disponible – Meilleur utilisation de la capacité disponible • faire en sorte qu’il y a toujours quelque chose à telecharger • il est moins probable qu’à un certain instant tous les peers soient interessés par le meme chunk peu (ou pas) disponible 6 30/08/2011 Chunks: Rarest First • Fonctionnement – Quand un Peer veut envoyer une requête pour un nouveau chunk – Il demande aux autres Peers voisins les chunk qu’ils possèdent – Il envoie une requête pour celui qui est le moins présent • Remarque – Le choix Rarest First est locale, car un peer ne contacte que ses voisins – Au meme temps, comme le voisinage des Peers change, les choix locales ont tendance à converger vers de choix globales Chunks: Rarest First On contacte les Peers pour connaître les chunks qu’ils possèdent et que nous n’avons pas déjà (1,2,3,4) On comptabilise les disponibilités de chaque chunk On choisit aléatoirement parmi les plus rares : Random(2, 3) 7 30/08/2011 Pieces: Random First Piece • Exception des algorithme précédents – Quand on vient juste de rentrer dans le systeme, on ne possède pas encore un chunk – Probleme: on ne peut pas uploader, pour cela on doit obtenir rapidement un chunk • Fonctionnement – Tant qu’on ne possède pas un chunk complet – Envoie de requête pour des pièces aléatoires de chunks Pieces: Endgame Mode • • • Interet: – Aider des leecher à devenir des seeds, plus de sources dans le systeme Problemes – Malgré Rarest First, certains chunks peuvent rester globalement plus rare que d’autres (Rarest First est appliqué localement) – Aussi, en fin de téléchargement, on est plus contraint sur le choix des chunks à télécharger Fonctionnement: – Pour eviter de rester bloqués, meme si toutes les pièces qu’il nous reste à telecharger sont toutes hautement demandées – On envoie une requête pour toutes les pièces manquantes à tous les peers avec lesquels on communique 8 30/08/2011 Peers: Choke/Unchoke • Probleme – Si aucun Peer n’upload, alors le partage est impossible • Solution – Enforcer la reciprocité des echanges, en arrêtant l’upload vers des Peers dont on télécharge peu • Fonctionnement (toutes les 10 secondes) – – – – calculer le taux de téléchargement de chaque voisin conserver les 4 meilleurs rétablir l’upload vers ceux qui en font à nouveau partie (unchoke) couper l’upload vers ceux qui ne figurent plus dans le classement (choke) Peers: Optimistic Unchoking • Problemes – Empêcher qu’on n’échanges que dans un groupe réduit – Ne pas exclure les nouveaux arrivant – Permettre de découvrir d’autres peers (possibilité d’obtenir une meilleur taux d’upload) • Solution – Procès avec choix aletoires (avec une frequence plus lente) • Fonctionnement (toutes les 30 secondes) – choix aléatoire d’un peer parmi les 4 vers qui on upload – on lui coupe l’upload (choke) – on choisit un peer aléatoirement parmi ceux à qui on upload le moins – on lui rétablit l’upload (unchoke) 9 30/08/2011 Peer: Anti-snubbing • Probleme – Snub = uploader sans télécharger (inverse du free-riding) – Lié au choke, quand on ne fait pas partie des 4 meilleurs uploads des peers avec qui on échange • Solution – Se créer les condition pour l’optimistic unchoke (très peu uploader) • Fonctionnement : – Si un Peer, a qui on permet l’upload, nous bloque pendant plus de 1 min (choke) – On lui coupe l’upload (choke) – On attend un optimistic unchoke en notre faveur avant de rétablit l’upload (unchoke) Peer: Seeding • Seeding – Le seul but d’un seed est d’uploader • Fonctionnement – Un seul algorithme proche du choke – Uploader vers ceux auxquels on upload le plus – Idée: maximiser le transfer vers ceux qui peuvent devenir seeds plus rapidement • Remarque – Ils existent d’autres algorithmes lié au seeding, – E.g., au debut quand il n’existe qu’un seul seed (super-seeding) 10 30/08/2011 Bilan BitTorrent: Efficacité • Localisation – Connaissances simple des Peers qui partagent grâce • • • • Au reseau DHT (trackerless) À une entité centralisée (tracker) Possibilité de plusieurs trackers au meme temps (multi-tracker) Possibilité d’utiliser les methodes multi-tracker et trackerless au meme temps • Diffusion – Diffusion rapide grace • Chunk permettent le pipelining et telechargement en parallel • Au politiques de choix des chunks et des peers • A la dissuasion du free-riding (reciprocation et force à l’upload) Bilan BitTorrent: Complexité • Beaucoup d'extension – – – – – Plusieurs trackers Table de hashage (trackless) Super-seeding Encryption LEDBAT congestion control • Introduite Decembre 2008 • Default Avril 2010 Client • Beacoup de clients – µTorrent, Azureus, BitTornado, BitTyrant, Xunlei … • Matrice clients vs extension – Un seul protocole, mais beaucoup d’implementations – Importance de la normalisation (standards) – BitTorrent Enhancement Protocol (BEP) Extension Supporté Pas supporté n/a 11 30/08/2011 References • Mandatory readings – P. Marciniak et al., Small is not always beautiful, USENIX IPTPS 2008, Tampa Bay, FL Feb 2008 http://hal.inria.fr/inria-00246564/en/ – A. Legout et al., Clustering and sharing incentives in BitTorrent, ACM SIGMETRICS, San Diego CA, Jun 2007, http://hal.inria.fr/inria-00137444/en/ • Optional readings – C. Testa and D. Rossi, The Impact of uTP on BitTorrent completion time IEEE P2P 2011, Kyoto Aug 2011 http://www.enst.fr/~drossi/paper/rossi11p2p.pdf Pas objet du controle A crash course on LEDBAT, the new BitTorrent congestion control protocol Dario Rossi Joint work with Claudio Testa, Silvio Valenti, Luca Muscariello, Giovanna Carofiglio, ... PAM’10 ICCCN’10 LCN’10 Globecom’10 P2P’11 Zurich + Zurich + Denver + Miami + Kyoto + ... April 2010 August 2010 October 2010 December 2010 August 2011 12 30/08/2011 News from congestion control world • BitTorrent announces closed source code, data transfer over UDP • BitTorrent + UDP = Internet meltdown! • After BitTorrent denial and some discussion... • Everybody agreed that Internet not gonna die • But is UTP/LEDBAT the best approach ? BitTorrent and LEDBAT • BitTorrent had to explain itself – Positive side effect of the Internet meltdown buzz • BitTorrent co-chairs the LEDBAT IEFT WG – Low Extra Delay Background Transport Protocol – delay-based protocol – designed for low-priority transfers • Protocol goals – Efficiently use the available bandwidth – Keep delay low on the network path – Quickly yield to regular TCP traffic Novel ingredient: Congestion control to relieve self-induced congestion at the access • Open questions – Does LEDBAT really achieve its goals? – What about BitTorrent implementation of LEDBAT? page 26 13 30/08/2011 LEDBAT evolution TCP v5.2.2 Oct ‘08 α1 v1.9-13485 Dec ‘08 α2 v1.9-15380 Mar ’09 β1 v1.9-16666 Aug ‘09 RC1 v2.0.1 Apr’10 Open source Closed source First LEDBAT draft Draft as WG Item After IETF 77 Simulation Testbed Testbed Testbed Packet size [Bytes] 1500 α2 β1 TCP α1 vv1.9-15380 1.9-16666 v5.2.2 v1.9-13485 Mar Aug ‘09 ’09 Oct Dec ‘08 ‘08 Draft First LEDBAT assource WG Open source Closed draft Item 1250 1000 750 500 250 0 0 10 20 30 Time [s] 40 50 •TCP transfers, full playload •α1 small packet overkill !! •α2 variable framing (not in draft) •β1 finer bytewise cwnd control •25 october 2010: IETF draft v3 page 27 Outline • Analysis of LEDBAT with a twofold methodology: • Controlled simulation – LEDBAT algorithm – TCP vs LEDBAT – LEDBAT vs LEDBAT – Fairness issue – Future Work • Experimental measurements – Testbed description – Implementation evolution – Bandwidth/Delay Impairments – ADSL experiments – Multiflow experiments – Future Work page 28 14 30/08/2011 Pas objet du controle LEDBAT: the new BitTorrent congestion control protocol Dario Rossi Joint work with Claudio Testa Silvio Valenti and Luca Muscariello ICCCN’10 Zurich August 2010 TCP: Loss-based congestion control • • Objective of congestion control – Limit sender rate to avoid overwhelming the network with packets TCP detects congestion by means of packet losses – Increment the congestion window (cwnd) of one packet each RTT – Halve the congestion upon losses losses cwnd t – The buffer always fills up -> high delay for interactive applications 15 30/08/2011 LEDBAT: Delay-based congestion control • Use Delay as congestion signal (TCP Vegas) – Increasing delay = increasing queue -> need to decrease rate LEDBAT monitors the delay on the forward path – sender and receiver timestamp packets – sender maintains a minimum over all delays (base delay) – LEDBAT tries to add just a small fix delay (TARGET) – a linear controller adjusts the cwnd • TARGET cwnd TARGET is reached • enqueue only TARGET packets • low extra delay and no loss t LEDBAT operations • Pseudocode in Draft 1) One-way delay @RX: estimation remote_timestamp = data_packet.timestamp ack.delay = local_timestamp() - remote_timestamp ack.send() @TX: delay = ack.delay update_base_delay(delay) update_current_delay(delay) 2) Base delay = min(delays) 3) Queuing delay estimation queuing_delay = current_delay() - base_delay() off_target = TARGET - queuing_delay cwnd += GAIN * off_target / cwnd 4) Linear controller • • TARGET = 25ms (“magic number” fixed in Draft) GAIN = 1/TARGET (our choice compliant with Draft) 16 30/08/2011 Simulation preliminaries • • We implemented LEDBAT as a new TCP flavor in ns2 Simulation scenario ∆T • • B Link between routers is the bottleneck 10Mb/s, others 100Mb/s Parameters – buffer size B – Time between flow start ∆T Simulations: LEDBAT vs TCP CWND [pkts] 80 5,6 40 2 3 4 0 TCP LEDBAT Total 1 Queue [pkts] 40 • • 20 0 1. TCP and LEDBAT start together 2. As soon as q=20pkt -> delay=25ms -> LEDBAT decreases 3. TCP causes a loss and halves its rate 4. Queue empties, LEDBAT restarts 5. TCP is more aggressive, LEDBAT always yields 6. Cyclic losses 4 8 Time [s] LEDBAT is lower priority than TCP Total link utilization increases (w.r.t TCP alone) 12 17 30/08/2011 Simulations: LEDBAT vs LEDBAT 80 1. LEDBAT flows start together 2. Queue builds up 3. As soon as q=20pkts -> delay=25ms -> linear controller settles 4. Queue keeps stable 5. No changes until some other flow arrives CWND [pkts] Total 40 LEDBAT 1 LEDBAT 2 0 Queue [pkts] 40 • 20 • 0 4 8 LEDBAT flows efficiently use the available bandwidth The bandwidth share is fair between LEDBAT flows 12 Time [s] Fairness issues • • 80 What if second flow starts after the first one? Different view of the base delay -> different TARGET -> unfairness ∆T = 5s, B=40 2nd flow starts before queue builds up Same TARGET, but the latecomer gets a smaller share 40 CWND [pkts] 0 80 5 15 25 ∆T = 10s, B=40 40 0 80 5 15 25 ∆T = 10s, B=100 Same as before but larger buffer Second gets all, first in stavation 40 0 2nd flow starts when first has reached its TARGET TARGET_2 = 2 * TARGET_1 after loss, fairness is restored: base delay estimate is corrected 5 15 Time [s] 25 18 30/08/2011 Simulation wrap-up • LEDBAT is a promising protocol – efficient but yields to TCP – ... but affected by latecomer advantage – ... and tuned with magic numbers • Further work (not in today talk) – Sensitivity analysis, i.e., how to select the magic numbers (LCN’10) – LEDBAT modification to solve latecomer advantage (Globecom’10) – Overall swarm completion time performance (P2P’11) – LEDBAT fluid model (submitted to IEEE Transaction on Networking) – Experiments on real swarm (ongoing) Pas objet du controle Yes, we LEDBAT: Playing with the new BitTorrent congestion control algorithm Dario Rossi Joint work with Claudio Testa and Silvio Valenti PAM’10, Zurich August 2010 19 30/08/2011 Agenda • Active testbed mesurements – Single-flow LAN experiments • Timeline of LEDBAT evolution • Emulated capacity and delay – ADSL experiments • In the wild • Interaction with cross-traffic – Multi-flow LAN experiments • Level of low-priority ? • Conclusions + future work LAN experiments (single-flow) Leecher • Application setup Switch 10/100 – uTorrent, official BitTorrent client, closed source • on native Windows (XP) • on Linux with Wine – Private torrent between the PCs Forward Backward • Network setup – Linux based router with Netem to emulate network conditions – Capture traffic on both sides, analyze traces • Experiment setup Seed Router + Netem – Flavors comparison – Delay impairment • Forward path • Backward path – Bandwidth limitation page 40 20 30/08/2011 LAN: LEDBAT evolution (1) TCP v5.2.2 Oct ‘08 α1 v1.9-13485 Dec ‘08 α2 v1.9-15380 Mar ’09 β1 v1.9-16666 Aug ‘09 RC1 v2.0.1 Apr’10 Open source Closed source First LEDBAT draft Draft as WG Item After IETF 77 Simulation Testbed Testbed Testbed Packet size [Bytes] 1500 α2 β1 TCP α1 vv1.9-15380 1.9-16666 v5.2.2 v1.9-13485 Mar Aug ‘09 ’09 Oct Dec ‘08 ‘08 Draft First LEDBAT assource WG Open source Closed draft Item 1250 1000 750 500 250 0 0 10 20 30 Time [s] 40 50 •TCP transfers, full playload •α1 small packet overkill !! •α2 variable framing (not in draft) •β1 finer bytewise cwnd control •RC1? evolution continues ! page 41 LAN: LEDBAT evolution (2) • Throughput evolution Throughput [Mb/s] – Different LEDBAT versions – Each curve in separate experiment – Also TCP BitTorrent (Linux + Win) 10 α1 TCP Linux 8 β1 6 • Observations – α1 unstable, small packets • Small packets recently broke β1 too α2 – α2 , ß1 stable smooth throughput 4 • 4 and 7 Mbps respectively TCP WinXP • Window limits 2 – LEDBAT and TCP influenced by the default maximum receive window: 0 0 60 120 Time [s] 180 240 • • • • TCP WinXP = 17 KB TCP Linux = 108 KB LEDBAT α2 = 30 KBytes LEDBAT ß1 = 45 KBytes page 42 21 30/08/2011 LAN: Constant delay • LEDBAT is delay based – constant delay for all packets – delay = k20 ms, k \in [1,5] – forward (or backward) path • Observation 120 β1 α2 5 60 0 0 240 600 Backward path 10 5 – same behavior on both directions – due to upper bound of maximum α2=20, ß1=30) receiver window (α – not a constraint since bottleneck shared among many flows 480 Delay [ms] • Experiment setup Forward path 10 Throughput [Mb/s] – it measures the one-way delay – sensitive to forward delay – Independent from backward 120 60 Delay profile 0 240 480 0 600 Time [s] page 43 LAN: Variable delay • Observations – α2 greatly affected by varying delay on the forward path – ß1 probably implements some mechanism to detect reordering – Minor impact of varying delay on backward path (ack delay only affects when decisions are taken) Throughput [Mb/s] – random uniformly distributed delay for each packet – reordering is possible! – range = 20 ± {0,5,10,20} ms – forward (or backward) path Forward path 10 120 β1 α2 60 8 6 0 0 120 360 Backward path 10 8 6 240 120 60 Delay profile 0 Delay [ms] • LEDBAT is delay based • Experiment setup 120 240 0 360 Time [s] page 44 22 30/08/2011 LAN experiments (multiple flows) Leechers Switch 10/100 • Application setup – uTorrent β1 flavor only – Private torrents – Each couple seeder/leecher shares a different torrent • Network setup – Simple LAN environment – No emulated conditions • Experiment setup – Varying ratios of TCP/LEDBAT flows – Different TCP network stack • native Linux stack • Windows settings emulated over Linux (to measure losses) Router + Netem Seeds 45 LAN: Multiple TCP and LEDBAT flows TCP windows TCP linux 0.98 0.98 0.98 0.98 0.96 1.00 0.75 0.56 0.33 1.00 0.67 0.94 0.93 0.92 0.96 1.00 0.64 0.74 0.87 1.00 0 0.5 TCP LEDBAT 0.5 LEDBAT 1 1 TCP Bandwidth Breakdown Efficiency Fairness 4-0 3+1 3-1 2+2 2-2 1+3 1-3 0+4 0-4 4+0 4-0 3+1 3-1 2+2 2-2 1+3 1-3 0+4 0-4 4+0 TCP+LEDBAT TCP+LEDBAT Observations • • • • Throughput breakdown between X+Y competing TCP+LEDBAT competing flows Efficiency is always high Fairness among flows of the same type (intra-protocol) is preserved TCP-friendliness depends on TCP parameters – TCP Linux stronger than LEDBAT, LEDBAT stronger than TCP WinXP 46 23 30/08/2011 ADSL experiments • Application setup Leecher – uTorrent β1 flavor only – native Windows (XP) only – private torrent ADSL • Network setup Internet – real ADSL modems – wild Internet • uncontrolled delay, bandwidth • Interfering traffic • Experiment setup – LEDBAT alone in the wild – LEDBAT with cross TCP traffic ADSL • On forward path • On backward path Seed page 47 ADSL experiments Throughput [Mb/s] 0.6 • 5 Throughput β1 4 3 0.4 2 RTT 0.2 0 • TCP forward LEDBAT alone TCP backward LEDBAT alone RTT [s] LEDBAT alone 0.8 1 100 200 300 Time [s] 400 500 LEDBAT alone – Stable throughput, closely matching nominal DSL capacity LEDBAT connection competing with TCP on forward and backward path – LEDBAT actually yields to TCP on the forward path – TCP on backward path has nasty influence on LEDBAT throughput: • due to shacky RTT (>1 sec due to ADSL buffer!) • affecting the time at which decisions are taken 600 0 page 48 24 30/08/2011 Measurement wrap-up • Main messages – Behavior evolved: • β1 addressed many issues (has RC1 fixed the others?) • Draft tells only part of the story – Efficiency goal: • Provided that enough flows on bottleneck (or increase window limit) • Compromised by interfering traffic on backward unrelated path – Low-priority goal: • Reasonably met, but is LEDBAT low-priority level tunable ? • Depends on TCP settings as well: meaning of Low-priority itself is fuzzy • Future work – Interaction with other BitTorrent mechanisms (e.g., peer selection, tit-for-that, etc.) – Impact on the users QoE (i.e., torrent completion time ?) – More heterogeneous settings (e.g., larger scale experiments, access technology, BitTorrent vs our implementation, etc.) 49 ?? || // 25