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