Una aplicación de coordenadas de red para aumentar el tráfico intra

Universidad de Buenos Aires
Facultad de Ciencias Exactas y Naturales
Departamento de Computación
Una aplicación de coordenadas de red
para aumentar el tráfico intra-ISP
en BitTorrent
Tesis presentada para optar al tı́tulo de Licenciado de la Universidad de Buenos Aires
en el área de Ciencias de la Computación
Jorge Lucángeli Obes
Director de Tesis: Dr. Claudio E. Righetti
Buenos Aires, abril de 2009
Una aplicación de coordenadas de red
para aumentar el tráfico intra-ISP en BitTorrent
Resumen
El tráfico generado por los protocolos peer-to-peer (P2P) plantea un desafı́o para los proveedores de Internet (Internet Service Providers, ISPs). Por un lado, este tráfico representa
una gran proporción del tráfico total de Internet. Por otro lado, el tráfico P2P es mayormente simétrico, mientras que las conexiones de banda ancha residencial son generalmente
asimétricas. Los protocolos P2P transforman a los clientes en proveedores de contenido, incrementando el tráfico intercambiado entre usuarios de distintos ISPs. Esto incrementa a su
vez los costos de los proveedores, pues el tráfico que sale de la red de un ISP tiene un costo
mayor para el ISP que el tráfico intercambiado entre sus propios usuarios. Frente a esta situación, los proveedores han respondido regulando agresivamente el tráfico generado por los
protocolos P2P, afectando su correcto funcionamiento. Las soluciones propuestas comparten el
enfoque de modificar los protocolos P2P para que los nodos ejecutando el protocolo prefieran
conectarse e intercambiar información con otros nodos en su mismo ISP.
Este trabajo presenta una modificación al protocolo P2P BitTorrent que incrementa el
tráfico intercambiado entre nodos en el mismo ISP sin disminuir la tasa de transferencia de
los usuarios. Nuestra propuesta consiste en modificar el algoritmo principal de BitTorrent para
que cada nodo ejecutando el protocolo prefiera intercambiar información con nodos cercanos en
términos de latencia, dado que dos nodos con baja latencia entre sı́ tienen mayor probabilidad
de estar en un mismo ISP. A diferencia de otros trabajos, nuestra propuesta no modifica el
comportamiento del tracker (servidor de información administrativa) de BitTorrent, lo que
nos permite mantener las propiedades de robustez y utilización de recursos del protocolo.
Utilizamos el mecanismo de estimación de latencia Vivaldi para evitar que los nodos tengan
que medir latencias constantemente. Realizamos una implementación de Vivaldi y BitTorrent
en un simulador que permite construir redes con enlaces similares a las conexiones de banda
ancha residencial. La experimentación con el simulador permitió, por un lado, caracterizar el
comportamiento de Vivaldi en una red de esas caracterı́sticas. Por otro lado, logramos validar
la modificación al protocolo BitTorrent, incrementando el porcentaje de tráfico entre nodos
del mismo ISP del 25 % al 33 %, sin que los usuarios sufran una disminución en su tasa de
transferencia.
i
An application of network coordinates
to increase intra-ISP traffic in BitTorrent
Abstract
Traffic generated by peer-to-peer (P2P) protocols poses a significant challenge for ISPs. On
the one hand, P2P traffic represents an important fraction of the total traffic volume. On the
other hand, P2P traffic is mainly symmetric, while most residential broadband connections
are asymmetric. P2P protocols transform clients into content providers, causing a surge in
traffic exchanged between users of different ISPs. This increases traffic costs for ISPs as traffic
leaving the network of an ISP is more expensive for the ISP than traffic that flows between its
internal users. In return, ISPs have started to regulate the traffic generated by P2P protocols,
affecting their correct operation. Proposed solutions share the approach of modifying P2P
protocols so that nodes running the protocol prefer to connect and exchange information
with other nodes in the same ISP.
This work presents a modification of the BitTorrent P2P protocol that increases traffic
exchanged between nodes in the same ISP, without decreasing download rates for users. Our
proposal modifies BitTorrent’s main algorithm so that each node running the protocol prefers to exchange information with nodes that are close latency-wise, as two nodes with low
latency between them have a greater chance of being in the same ISP. In contrast to other
works, our proposal does not modify the behaviour of the BitTorrent tracker (administrative information server), allowing us to keep BitTorrent’s robustness and resource utilization
properties. We use the Vivaldi latency estimation mechanism so that nodes don’t have to
measure latencies constantly. We implemented both Vivaldi and BitTorrent in a simulator
that allows building networks having links with properties similar to residential broadband
connections. Experimentation with the simulator allowed us, first, to characterize Vivaldi’s
behaviour in a network of those characteristics. More important, we succeeded in validating
our modification to BitTorrent, increasing the fraction of traffic exchanged between nodes in
the same ISP from 25 % to 33 %, without decreasing download rates for users.
ii
Agradecimientos
En primer lugar querı́a agradecer a mis padres y a mi hermano, que me apoyan siempre.
A mis amigos del FDS: Andy, Utter, el Gordo, Nico, Cere, Moro, Biffo, Santi, Dan, Vero, Ana,
Maria, Vane, Sofi y Aldi. Junto a ellos nació la idea de estudiar Ciencias de la Computación.
A mis amigos de la facu: Toto, Sabi, PabloH, Eze, Fede, Luigi, Pı́ter, Guido, Mati, PabloB,
PabloR, Pancho, Lata, Tommy, Lea, Droopy y Román. No me imagino haber hecho la carrera sin
ellos.
A las profesoras del FDS que acompañaron mi interés por la computación y la matemática:
Claudia y Gloria.
A la UBA, a la FCEN y al DC: por recibirme como alumno, formarme y permitir que me
desempeñe como docente.
A los docentes del DC, que generan el mejor ambiente. Especialmente a Chapa, Diego Garbervetsky, Santi Figueira, Serge, Dani Gorı́n, Diego Bendersky, Ale Furfaro y Diego Fernández
Slezak.
Al jurado, Esteban y Fernando, por tomarse el tiempo de leer la tesis y señalarme las cosas
que se podı́an mejorar.
A mi director, Claudio, por darme la oportunidad de hacer la tesis en este tema y guiarme
durante el proceso.
Finalmente, a Tamara, la persona más importante en mi vida. Estás a mi lado para todo, y
fuiste a quien más tiempo le robé para la carrera y para la tesis.
iii
Índice
1. Introducción
1.1. Nuestro trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
3
2. Marco de trabajo
2.1. Aplicaciones peer-to-peer . . . . . . .
2.2. Ubicación del contenido en Internet . .
2.3. Las redes de banda ancha residenciales
2.4. Trabajos relacionados . . . . . . . . .
2.5. El debate sobre las coordenadas . . . .
6
6
6
6
7
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Enfoque
10
4. Vivaldi
4.1. El protocolo Vivaldi . . . . . . . . . . . . . . . . .
4.2. Interpretación fı́sica . . . . . . . . . . . . . . . . .
4.3. Desplazamiento adaptativo . . . . . . . . . . . . .
4.4. Espacios . . . . . . . . . . . . . . . . . . . . . . . .
4.5. Modificaciones al protocolo Vivaldi . . . . . . . . .
4.5.1. La modificación a Vivaldi propuesta en este
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
trabajo
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
13
14
15
16
18
5. BitTorrent
5.1. El protocolo BitTorrent . . . . . . . . . .
5.2. Comunicación entre los peers . . . . . . .
5.2.1. Mensajes del protocolo BitTorrent
5.3. Mecanismo de choking . . . . . . . . . . .
5.4. Modo fin-de-juego . . . . . . . . . . . . .
5.5. Un ejemplo de comunicación entre peers .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
20
21
22
22
6. El simulador SSFNet
6.1. La jerarquı́a de clases en SSF.OS .
6.2. Transmisión de información . . . .
6.3. La jerarquı́a de clases en SSF.Net .
6.4. Direccionamiento . . . . . . . . . .
6.5. El lenguaje DML . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
25
26
7. Implementación de Vivaldi en SSFNet
7.1. Detalles de la implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2. La red de prueba para la simulación de Vivaldi . . . . . . . . . . . . . . . . . . . .
27
27
28
8. Resultados de la simulación de Vivaldi
8.1. Visualización de las coordenadas . . . . . . . . . . . . .
8.2. Comportamiento de la componente H . . . . . . . . . .
8.3. Distancias entre los nodos . . . . . . . . . . . . . . . . .
8.4. Distancia como indicador de proximidad . . . . . . . . .
8.5. Comportamiento de las coordenadas frente a variaciones
8.6. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . .
. . .
. . .
. . .
de la
. . .
. . . .
. . . .
. . . .
. . . .
LML .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
31
32
34
37
37
9. Implementación de BitTorrent en SSFNet
9.1. BitTorrent y la estimación de latencia . . . . . . .
9.2. BitTorrent en SSFNet . . . . . . . . . . . . . . . .
9.3. Implementación de Vivaldi a cuestas de BitTorrent
9.4. Implementación de las modificaciones a Vivaldi . .
9.5. La red de prueba para SSFNet . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
40
43
43
43
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10.Resultados de la simulación de BitTorrent
10.1. Experimentación con las modificaciones a Vivaldi . . . . . . . . . . . . . . . . . . .
10.1.1. Experimentación con la ampliación del conjunto de vecinos . . . . . . . . .
45
48
49
11.Conclusiones
53
12.Trabajo futuro
55
Índice de figuras
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Tráfico P2P como porcentaje del tráfico total [1] . . . . . . . . . .
Volumen de tráfico P2P por protocolo [1] . . . . . . . . . . . . . .
Cálculo de distancia en el espacio vectores de altura . . . . . . . .
La red de prueba para la simulación de Vivaldi . . . . . . . . . . .
Red base para la construcción, con 40 nodos . . . . . . . . . . . . .
Red de 160 nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Red del sistema autónomo . . . . . . . . . . . . . . . . . . . . . . .
Visualización de las coordenadas de los nodos . . . . . . . . . . . .
Componente H contra LML . . . . . . . . . . . . . . . . . . . . . .
Histogramas de distancias, caso 10 ms . . . . . . . . . . . . . . . .
Histogramas de distancias, caso 100 ms . . . . . . . . . . . . . . .
Visualización de las coordenadas de los nodos, LML 5 ms . . . . .
Visualización de las coordenadas de los nodos, LML 10 ms . . . . .
Visualización de las coordenadas de los nodos, LML 20 ms . . . . .
Visualización de las coordenadas de los nodos, LML 50 ms . . . . .
Visualización de las coordenadas de los nodos, LML 100 ms . . . .
La red de prueba para la simulación de BitTorrent . . . . . . . . .
Visualización de las coordenadas calculadas por Vivaldi a cuestas
caso normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Visualización de las coordenadas calculadas por Vivaldi a cuestas
caso interés de subida . . . . . . . . . . . . . . . . . . . . . . . . .
Visualización de las coordenadas calculadas por Vivaldi autónomo
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
de BitTorrent,
. . . . . . . . .
de BitTorrent,
. . . . . . . . .
. . . . . . . . .
2
5
17
29
29
30
30
32
33
36
36
37
37
38
38
38
44
45
46
46
Índice de cuadros
1.
2.
3.
4.
5.
6.
7.
Distancias promedio en Vivaldi variando la LML . . . . . . . . . . . . . . . . . . .
Porcentajes de falsos positivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Distancias promedio en BitTorrent. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Porcentaje de piezas intercambiadas dentro del mismo AS e ISP . . . . . . . . . .
Cantidad total de piezas intercambiadas . . . . . . . . . . . . . . . . . . . . . . . .
Porcentaje de piezas intercambiadas dentro del mismo AS e ISP, con las modificaciones
Distancias promedio en BitTorrent con modificaciones . . . . . . . . . . . . . . . .
34
35
47
48
48
50
51
Índice de algoritmos
1.
2.
3.
4.
5.
Algoritmo
Algoritmo
Algoritmo
Algoritmo
Algoritmo
Vivaldi, versión centralizada . . . . . . . . . . . . . . . . . . .
Vivaldi, versión distribuida . . . . . . . . . . . . . . . . . . .
de Vivaldi, versión distribuida con desplazamiento adaptativo
de choking . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
de choking modificado . . . . . . . . . . . . . . . . . . . . . .
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
15
22
41
1.
Introducción
Las aplicaciones peer-to-peer (P2P) generan una gran proporción del tráfico en Internet (figura 1). Sin embargo, el volumen del tráfico no es el único problema para los proveedores de
Internet (Internet Service Providers, ISPs). Los nodos que utilizan aplicaciones P2P generan cantidades similares de tráfico downstream (tráfico de bajada, hacia el nodo) como upstream (tráfico
de subida, desde el nodo). En cambio, las conexiones de Internet de banda ancha residencial
utilizadas por gran parte de estos nodos son asimétricas: el ancho de banda downstream es mayor
que el ancho de banda upstream. Por lo tanto, las aplicaciones P2P presentan un desafı́o nuevo
para la planificación de tráfico1 en un ISP.
Esta caracterı́stica que posee el tráfico generado por las aplicaciones P2P tiene varias consecuencias. Cada nodo corriendo una aplicación P2P se conecta con otros nodos corriendo la misma
aplicación ignorando completamente la estructura de la red subyacente. Esto es esperable, ya que
uno de los principios de diseño básico de TCP/IP es el end-to-end principle [2]. Una interpretación de este principio es que un usuario de TCP/IP en el borde de la red (por ejemplo, una
aplicación P2P) no debe preocuparse por cómo su conexión con otro nodo atraviesa la red y llega
hasta ese nodo.
En la visión de un nodo corriendo una aplicación P2P cualquier otro nodo que ejecute la
aplicación es equivalente. Sin embargo, el resto de los nodos corriendo la aplicación no son iguales.
Estos nodos pueden ser computadoras accediendo a Internet desde universidades, empresas o
mediante conexiones residenciales; todos enlaces con distintas caracterı́sticas de ancho de banda2
y latencia3 . El desempeño de la aplicación P2P estará determinado por estas caracterı́sticas de las
conexiones de los nodos participantes.
Los nodos remotos, por lo tanto, no son equivalentes para una instancia de una aplicación P2P.
Otro aspecto importante a tener en cuenta es el costo. Un ISP no tiene el mismo esquema de costos
para el tráfico que ocurre entre sus nodos internos como para el tráfico que ocurre entre uno de sus
nodos internos y el resto de Internet. La visión end-to-end de las aplicaciones P2P tiene entonces
una consecuencia directa sobre los costos de los ISPs. La elección de un nodo por sobre otro puede
implicar intercambiar tráfico dentro del ISP (tráfico intra-ISP) o tráfico entre el ISP y el resto de
Internet (tráfico inter-ISP), con costos distintos para el ISP. Este tráfico inter-ISP es justamente
el que las aplicaciones P2P han incrementado. En el modelo de tráfico histórico para los ISPs,
los usuarios residenciales accedı́an a servicios (páginas Web, correo electrónico, etc.) ubicados en
lugares más o menos definidos. Las aplicaciones P2P hacen que todos los usuarios residenciales
intercambien tráfico entre ellos, cambiando el modelo de tráfico de los ISPs, e incrementando sus
costos [3].
El principal uso actual de las aplicaciones P2P es el intercambio de archivos. Analizando la
situación desde un punto de vista más global, el hecho que el intercambio de archivos no se realice
utilizando protocolos clásicos cliente-servidor podrı́a ser beneficioso para los ISPs. Para el mismo
volumen de información, el uso de protocolos P2P permite que al menos una pequeña parte del
tráfico total se intercambie entre nodos del mismo ISP. Al contario, si todos los nodos del ISP
bajan el mismo archivo desde servidores Web, no hay posibilidad de que nodos en el mismo ISP
intercambien partes del archivo. Esto sugerirı́a que el uso de protocolos P2P para el intercambio
de archivos resulta preferible para los ISPs que la alternativa cliente-servidor.
El problema con este análisis es que gran parte del éxito de los protocolos P2P se debe justamente a que permitieron aprovechar mucho ancho de banda que no estaba siendo utilizado, por
ejemplo (pero no únicamente) el ancho de banda de subida de muchas conexiones residenciales.
1 También
llamada ingenierı́a de tráfico por algunos autores.
ancho de banda de un canal de comunicación, en el sentido más técnico, es la diferencia entre la frecuencia
de corte superior e inferior. La frecuencia de corte de un canal es el punto en el que la potencia de salida se ha
reducido a la mitad. Este ancho de banda se conoce también como ancho de banda analógico. Está relacionado con
la noción de ancho de banda más usual en computación, el ancho de banda digital, que indica la cantidad de bits
que pueden ser transmitidos por el canal en un perı́odo de tiempo.
3 La latencia de un enlace de comunicación es el tiempo que tarda la información en llegar desde el emisor al
receptor. Cuando medimos la latencia ida y vuelta, es decir el tiempo que tarda la información en ir desde el emisor
al receptor y volver al emisor, hablaremos de Round Trip Time o RTT.
2 El
1
Figura 1: Tráfico P2P como porcentaje del tráfico total [1]
Con un 50 a 80 % del tráfico total de Internet generado por protocolos P2P (figura 1 y mediciones
propias en el ISP Cablevisión), no es necesariamente trivial hacer que ese tráfico utilice otros protocolos. Dicho de otra manera, parece ser que la única manera de sostener el tráfico generado por
el intercambio de archivos es utilizando protocolos P2P, y entonces la comparación del párrafo anterior deja de ser posible. Los protocolos P2P permitieron un incremento en el volúmen de tráfico
que hubiera sido difı́cil de sostener en una situación cliente-servidor, justificando la necesidad de
contener el aumento de tráfico inter-ISP.
Este trabajo surge entonces ante el aumento de volumen y el cambio de comportamiento del
tráfico IP debido a la utilización por parte de los usuarios de las aplicaciones P2P. Presentamos
un aporte que contribuye a aumentar el tráfico intra-ISP de estas aplicaciones, disminuyendo
ası́ el tráfico inter-ISP. Creemos que es necesario un enfoque mixto en el cual las aplicaciones
P2P contribuyan a que su tráfico sea más ameno para los ISPs, y éstos faciliten el intercambio de
información entre sus nodos, por ejemplo aumentando el ancho de banda disponible para tráfico
intra-ISP. Las soluciones unilaterales de los ISPs, basadas en técnicas clásicas de regulación de
tráfico, no son suficientes. Si bien han amortiguado el efecto de las aplicaciones P2P, esto ha sido
a costa de su funcionalidad. El volumen de tráfico es tan grande que la regulación debe ser muy
agresiva, dejando a las aplicaciones, en muchos casos, inutilizables. Esto ha despertado una ola de
crı́ticas a nivel mundial por parte de los usuarios, y muchas veces los reclamos han contado con
el apoyo de los organismos de control correspondientes. Tenemos como ejemplo el caso del ISP
Comcast [4] que se vio forzado a cambiar su polı́tica de regulación de tráfico luego de las crı́ticas
de los usuarios y la intervención de la FCC (el organismo de control estadounidense). Frente a
esta situación, algunas aplicaciones P2P ya están considerando incluir mecanismos para disminuir
el tráfico inter-ISP [5].
2
1.1.
Nuestro trabajo
En este contexto, nuestro trabajo presenta un mecanismo para aumentar el porcentaje de tráfico
intra-ISP dentro del total de tráfico generado por la aplicación P2P BitTorrent [6]. La elección
de BitTorrent se debe a su popularidad, siendo el protocolo P2P más utilizado en términos de
cantidad de tráfico generado (figura 2 y mediciones propias en el ISP Cablevisión). En BitTorrent,
los nodos o peers colaboran para transferir un archivo en particular. El conjunto de peers que
está bajando el archivo se denomina swarm. El archivo a distribuir se divide en piezas de tamaño
fijo, de manera de que cada peer bajando el archivo pueda ir subiendo a otros peers las piezas que
ya bajó.
Nuestro objetivo fue encontrar maneras de guiar la comunicación de los peers de un swarm de
BitTorrent para aumentar el tráfico intra-ISP. En el caso óptimo, una vez que un fragmento del
archivo a bajar es recibido por un peer de un ISP, el resto de los peers conectados al mismo ISP
obtendrı́an el fragmento de ese peer. Este serı́a el punto de tráfico inter-ISP mı́nimo: cada pieza
entra al ISP exactamente una vez, y luego es replicada dentro del ISP.
Esta situación es difı́cil de lograr. Por un lado, requerirı́a un enorme conocimiento de la estructura de los ISPs usados por los peers presentes en el swarm. Se necesitarı́a saber siempre cuando
dos peers pertenencen al mismo ISP, y con este conocimiento, guiar el intercambio de piezas. Por
otro lado, en una enorme proporción de los casos, el peer que obtiene la pieza no tendrá suficiente
ancho de banda para atender los pedidos de todo el resto de los peers que la quieren replicar dentro
del ISP, por lo tanto esta solución no será óptima en términos de throughput4 .
Elegimos tomar un camino más indirecto, en el cual cada peer aprovecha información que
puede obtener de manera local para realizar inferencias que le ayudan a elegir otros peers dentro
del mismo ISP. Haciendo que cada peer intercambie piezas preferentemente con estos peers cercanos
esperamos aumentar el tráfico intra-ISP del swarm.
El hecho básico que justifica la utilización de estos métodos indirectos es que generalmente es
mucho más fácil para un nodo llegar hasta otro nodo en su mismo ISP que hasta un nodo en otro
ISP. Los distintos ISPs tienen pocos puntos de contacto entre sı́. Por lo tanto, el tráfico IP cambia
de ISP en pocos lugares. En consecuencia, todos los nodos de un ISP pasarán por el mismo lugar
para salir del ISP, de lo cual se desprende que para comunicarse entre sı́ solamente tendrán que
llegar, en peor caso, hasta ese punto.
Como siempre, pueden existir excepciones a este hecho. Si dos nodos de un ISP en el cual
la latencia hasta ese punto de “salto” es muy alta tratan de comunicarse entre sı́, posiblemente
tengan una latencia mayor que cualquiera de ellos comunicándose con un nodo en otro ISP donde
la latencia entre el nodo y el punto de salto sea más baja. En particular, las conexiones de banda
ancha residencial tienen esta caracterı́stica: la latencia entre el nodo y el punto en el que la conexión
deja el ISP puede representar una parte grande de la latencia total. En este caso, puede ser más
rápido recorrer una vez esta latencia y luego llegar a un nodo fuera del ISP que recorrer dos veces
esa latencia para comunicar dos nodos dentro de ese ISP. Por ejemplo, consideremos dos nodos
en un ISP que provee banda ancha utilizando cablemódem. Si la latencia introducida por cada
cable coaxil es del orden de los 10 ms (un caso de congestión leve), la latencia entre ambos nodos
es de 20 ms. Si uno de esos nodos se conectara con otro nodo por ejemplo en una universidad, la
latencia total entre el ISP original y el nodo en la universidad podrı́a ser menor a 10 ms, haciendo
que la comunicación entre dos nodos en distintos ISPs tenga menor latencia que una comunicación
intra-ISP.
Estas excepciones no minimizan la situación existente actualmente en Internet: si dos nodos
están cerca en términos de latencia, es muy probable que estén en el mismo ISP. La recı́proca no
vale: es posible que dos nodos que están lejos pertenezcan al mismo ISP, especialmente si es un
ISP que abarca distintas zonas geográficas. Esto no es un problema, ya que basta identificar un
subconjunto de peers que pertenezcan al mismo ISP, no es necesario encontrarlos todos.
Nos basamos en este hecho para guiar el comportamiento de los peers. Cada peer va a preferir
otros peers dentro del swarm contra los que tenga una latencia baja. El problema es que para
conocer esta latencia es necesario medirla, y esta medición podrı́a ser muy costosa. La medición
4 Es
decir, la cantidad de bits que el swarm puede intercambiar en un perı́odo de tiempo
3
implica tráfico, ya que se requiere enviar un paquete que vaya y vuelva entre dos nodos. Una
propuesta en la que todos los nodos miden la latencia entre sı́ tendrı́a mucho costo extra.
Para evitar este costo es necesaria alguna manera de poder estimar la latencia entre los peers
del swarm. La estimación de latencia no es un problema nuevo. Se han desarrollado numerosos
mecanismos que permiten a cada nodo, con información local, estimar la latencia contra otros
nodos, evitando comunicación (o comunicación extra) con esos otros nodos. En particular, existen
esquemas de coordenadas virtuales en los cuales se asignan coordenadas a cada nodo de manera
de que la distancia entre las coordenadas sea un buen estimador de la latencia. En este trabajo
elegimos el protocolo Vivaldi [7].
Utilizamos coordenadas virtuales asignadas por Vivaldi para estimar la latencia entre los peers
del swarm de BitTorrent, de manera de guiar el intercambio de piezas de los peers y favorecer
el tráfico intra-ISP. Presentamos una variante del algoritmo central de BitTorrent que llamamos
upload appeal o interés de subida, en la que cada nodo, con las demás variables iguales, prefiere
intercambiar piezas con peers cercanos antes que lejanos. Esta modificación permite pasar, en
simulaciones, el porcentaje de tráfico intra-ISP de un 25 % a un 33 %, sin disminuir la tasa de
transferencia del swarm.
Cada nodo intercambia piezas con un subconjunto de los peers con los que está conectado.
A su vez, en la mayorı́a de los sistemas P2P cada nodo se conecta con un subconjunto aleatorio
del conjunto total de peers. Al modificar solamente el intercambio de piezas estamos manteniendo
el conjunto (aleatorio) de peers con el que cada nodo se conecta. En consecuencia, solamente
podremos aumentar el tráfico intra-ISP si dentro de ese subconjunto aleatorio hay peers en el
mismo ISP.
Otra manera atacar el problema consiste en que los nodos se conecten con subconjuntos de peers
en los cuales haya nodos del mismo ISP [8, 9, 10]. Sin embargo, varios protocolos P2P, entre ellos
BitTorrent, se basan en la elección aleatoria para garantizar propiedadez de robustez y utilización
de recursos [6]. Modificar el intercambio de piezas pero no con qué peers se conecta cada nodo nos
permite mantener estas propiedades, que otras soluciones deben considerar explı́citamente.
Creemos que el aporte principal de este trabajo es el uso exitoso de un sistema de coordenadas
para guiar el intercambio de piezas en BitTorrent, aumentando el tráfico intra-ISP. No hemos encontrado otras descripciones del uso de sistemas de coordenadas para guiar el tráfico en BitTorrent.
Vivaldi está implementado en el cliente de BitTorrent Vuze5 , pero la información de coordenadas
no es utilizada para guiar el intercambio de piezas, sino para hacer más eficientes las consultas a
una base de datos distribuida. Por otro lado, hay literatura que critica el comportamiento de los
sistemas de coordenadas en redes reales [11, 12]. Para justificar nuestro uso de Vivaldi incluimos
un análisis de su comportamiento en una red con enlaces de banda ancha residencial, analizando
qué factores de la red afectan la calidad de la estimación provista por las coordenadas.
Revisaremos primero algunos temas básicos en la sección 2, Marco de trabajo. Luego describiremos en profundidad nuestro enfoque en la sección 3. A continuación presentaremos los protocolos
Vivaldi y BitTorrent en las secciones 4 y 5; y el simulador que utilizamos en la sección 6. Describiremos las implementaciones que realizamos de Vivaldi y BitTorrent en el simulador en las
secciones 7 y 9, y revisaremos los resultados de la simulación en las secciones 8 y 10. Finalmente
presentamos nuestras conclusiones en la sección 11 y una corta descripción del trabajo futuro en
la sección 12.
5 Este
cliente se llamaba anteriormente Azureus, usaremos ambos nombres indistintamente en este trabajo.
4
Figura 2: Volumen de tráfico P2P por protocolo [1]
5
2.
2.1.
Marco de trabajo
Aplicaciones peer-to-peer
Las aplicaciones peer-to-peer (P2P) son aplicaciones de red en las que los nodos se conectan
entre sı́ sin distincion de roles. En el modelo tradicional cliente-servidor presente en Internet habı́a
una diferencia clara entre cada extremo de una conexión; el cliente realizaba el pedido y el servidor lo respondı́a. En las aplicaciones peer-to-peer ambas partes de la conexión son equivalentes,
pudiendo ambos realizar pedidos y responderlos.
El pricipal uso de las aplicaciones peer-to-peer es la distribución de archivos. A medida que el
tamaño de los archivos a distribuir en Internet aumenta, sube de la misma manera el ancho de
banda requerido por el servidor del archivo para poder proveerlo a los múltiples clientes que lo
demandan.
Inicialmente, las aplicaciones peer-to-peer permitı́an a sus usuarios solamente compartir archivos completos. La aplicación P2P permitı́a a un usuario acceder a los archivos compartidos de
todos los otros usuarios de la misma aplicación, y bajar directamente de esos usuarios. Ejemplos
de esto son Napster, Gnutella o Kazaa [13]. En el caso de Napster se contaba con un servidor
central que coordinaba la base de datos de archivos compartidos por todos los usuarios, y en el
caso de Gnutella no habı́a ningún servidor central. El mismo protocolo Gnutella permitı́a realizar
búsquedas de archivos de manera completamente distribuida [13, 14].
Fue BitTorrent, sin embargo, la primera aplicación de uso masivo en la cual los peers cooperaban para bajar un archivo en particular. Al utilizar BitTorrent, los nodos que bajan el archivo a
su vez contribuyen ancho de banda de subida, de manera de mantener casi constante el ancho de
banda que el proveedor del archivo requiere para proveerlo a un grupo creciente de nodos. Cada
nuevo nodo bajando el archivo contribuye ancho de banda de subida.
2.2.
Ubicación del contenido en Internet
El modelo cliente-servidor no es simplemente una caracterı́stica técnica. La situación en Internet, durante los últimos años, consistı́a en proveedores de contenido por un lado y consumidores
de este contenido por otro. Habı́a una clara diferenciación entre los sitios Web accedidos por los
clientes y los nodos que los clientes utilizaban para acceder a estos sitios Web. Por lo tanto, tenı́a
sentido que las aplicaciones fueran cliente-servidor, y que tanto los servicios de acceso a Internet
como el tráfico fuera asimétrico, con mayor ancho de banda y mayor tráfico en sentido downstream.
Más recientemente ha habido un desplazamiento en la generación de contenido hacia el lado
del cliente. Los blogs6 , Twitter [15] y YouTube [16] son ejemplos en los cuales la generación de
contenido está en manos de las mismas personas que lo consumen. El crecimiento de las aplicaciones
P2P en Internet no es, por lo tanto, un hecho aislado. Desde la aparición de BitTorrent las
aplicaciones P2P han ganado una fracción considerable del tráfico total en Internet, tráfico que
corresponde mayormente a transferencia de archivos. La distribución de videos (como YouTube)
está sufriendo una evolución similar, al punto de que ya se está considerando seriamente utilizar
esquemas P2P para distribuir video, especialmente video de alta definición que requiere mucho
ancho de banda [17]. Esto agravarı́a todavı́a más el problema para los ISPs.
2.3.
Las redes de banda ancha residenciales
Una de las causas de este cambio en el tráfico fue la masificación de las conexiones de banda
ancha residenciales. Tanto el mayor ancho de banda como la posibilidad de estar conectado constantemente a Internet contribuyeron a que los clientes pasaran a ser generadores de contenido.
Estas conexiones de banda ancha son ahora parte del problema. Los clientes generan mucho más
tráfico upstream que cuando las tecnologı́as de banda ancha residencial se diseñaron.
6 Un blog (apócope de weblog) es un sitio Web actualizado periódicamente que recopila cronológicamente textos
o artı́culos de uno o varios autores.
6
En el caso del cablemódem, la tecnologı́a es en sı́ misma asimétrica. Los ISPs de cablemódem
construyen redes HFC (Hybrid Fibre-Coaxial), redes hı́bridas de fibra óptica y cable coaxil. La fibra
óptica se utiliza para conectar las distintas dependencias del ISP, y el cable coaxil cubre la última
milla: la conexión entre el último equipo del ISP (el Cable Modem Termination System, CMTS) y
el primer equipo del cliente (el cablemódem). En un CMTS confluyen muchos clientes, conectados
todos al mismo cable coaxil. La conexión de bajada (desde el CMTS hacia el cablemódem) se
multiplexa en frecuencia de manera de que cada cliente disponga de un canal propio. Para la
conexión de subida (desde cada cablemódem hacia el CMTS) se utiliza un sólo canal compartido
entre todos los clientes, multiplexado en el tiempo, Cuando un cablemódem quiere transmitir al
CMTS debe pedir una ranura de tiempo antes de enviar información [18].
Esta diferencia en la implementación fı́sica tiene su consecuencia obvia en el ancho de banda
y en la latencia. El ancho de banda downstream es mayor que el ancho de banda upstream, y su
latencia es menor. Dado que el tráfico de subida debe esperar una ranura de tiempo, su latencia
suele ser muy mala, contribuyendo en enorme proporción al RTT entre el cablemódem y el CMTS
[18]. Mediciones normales de este RTT en un ISP en Argentina dan resultados de 12 ms, de los
cuales 10 ms corresponden al tramo upstream7 .
Con la tecnologı́a DSL (Digital Subscriber Line) sucede lo mismo. Tanto razones técnicas
como económicas hicieron de la versión asimétrica una opción más razonable, y de esta manera se
masificó el ADSL (Asymmetric DSL). En ADSL la última milla se cubre con cable telefónico, y se
utiliza multiplexación en frecuencia para poder utilizar la misma lı́nea para transmisión de voz y
de datos. El equivalente del CMTS en ADSL es el DSLAM, DSL Access Multiplexer. La velocidad
del enlace entre el módem DSL del cliente y el DSLAM del ISP depende mucho de la distancia
entre ambos. Para salvar este problema se utilizan técnicas de procesamiento de señales, corrección
de errores y compresión de datos [18]. Todo este procesamiento agrega latencia en la transmisión,
estando de nuevo frente a un escenario de ancho de banda asimétrico y de alta latencia, como en
cablemódem, pero por razones distintas. En ambos casos un gran porcentaje del RTT de un nodo
en una red de banda ancha residencial corresponde a la latencia introducida por la última milla.
Llamaremos a esta latencia la LML (last mile latency, latencia de la última milla).
2.4.
Trabajos relacionados
A diferencia de este trabajo, las soluciones existentes para el problema del tráfico generado por
las aplicaciones P2P se centran en guiar la elección que cada peer hace de los otros peers con los
cuales se conecta. La idea básica de guiar la elección de peers para aumentar el tráfico intra-ISP
es presentada por Bindal et al. en [8] y con una perspectiva más matemático-económica por Adler
et al. en [9]. El enfoque de [8] requiere el uso de un oráculo8 que resuelve la pertenencia de peers
a ISPs. Teniendo esta información se muestra la factibilidad de utilizarla para que el tráfico intraISP se mantenga relativamente constante a medida que aumenta la cantidad de peers, sin reducir
la velocidad de bajada del archivo.
Podemos distinguir dos corrientes opuestas en estas soluciones. En un caso, que podemos llamar
explı́cito, los nodos cooperan con los ISPs de manera directa para resolver la pertenencia de peers
a ISPs. En el otro, que podemos llamar implı́cito o indirecto, los peers utilizan información de la
red para intentar elegir peers dentro del mismo ISP.
Dentro del primer caso encontramos el proyecto P4P [10], que llevan adelante Haiyong Xie
et al. La propuesta se basa en el uso de servidores extra en las redes P2P, provistos por cada
ISP. Estos servidores estarı́an a cargo de proveer información sobre estado y topologı́a de la red,
polı́ticas del ISP y capacidad de la red. Este modelo cuenta en principio con bastante apoyo de
la industria (las pruebas realizadas, si bien algo limitadas, involucran al ISP Verizon [19] y más
recientemente, a Comcast [20]. Nuestra evaluación es que éste es un modelo ligeramente ad-hoc
pero sobre todo muy centralizado, ya que depende de un servidor único en cada ISP. Esto va en
contra del espı́ritu de los sistemas P2P, que son inherentemente distribuidos. Por otro lado, la
7 Mediciones
en el ISP Cablevisión.
oráculo a una entidad, posiblemente imaginaria, que resuelve un problema para el cual no se conoce
solución; o que de existir una manera de resolver el problema, abstrae los detalles de cómo se arriba a la solución.
8 Llamamos
7
cooperación de la aplicación P2P con el ISP debe ser explı́cita, y esto es problemático ya que
involucra confiar en el comportamiento del servidor provisto por el ISP.
A grandes rasgos, la solución planteada por el proyecto P4P intenta acercarse al óptimo utilizando información explı́cita: se obtiene la información necesaria acerca de la topologı́a de la red
del ISP, y luego se toman decisiones en base a esa información. La manera más simple de tener
acceso a esta información es que el ISP la provea, y para que esto sea posible es necesario introducir servidores nuevos en la red, propiedad de cada ISP. Como ya hemos mencionado, nos parece
una solución demasiado ad-hoc para el problema, y la introducción de servidores únicos en un
protocolo P2P va en contra de la idea básica del mismo protocolo.
Una manera de resolver la pertenencia de peers a ISPs sin requerir cooperación directa entre
ambos es utilizar el sistema WHOIS9 . Una consulta WHOIS permite conocer la entidad dueña
de una dirección IP, y de esta manera se podrı́a decidir si dos peers están en el mismo ISP o no.
El principal problema que encontramos con WHOIS es que la información es administrativa más
que topológica de la red. Existen casos en el que nodos de un mismo ISP poseen direcciones IP
en rangos que están registrados a distintas entidades, por ejemplo cuando dos ISPs se combinan.
También puede suceder que un ISP tenga registrados rangos de direcciones IP en un paı́s distinto
que en el que opera, por razones comerciales o de ruteo. Por otro lado, la respuesta de una
consulta WHOIS es el nombre de la entidad dueña de la dirección IP. La única manera de utilizar
esta información en un programa es realizando una comparación de cadenas de caracteres. Esto
tiene como consecuencia que la información obtenida de WHOIS sea discreta, en el sentido que
si la respuesta puede ser positiva o negativa, pero no hay posibilidad de valores intermedios.
Analizaremos con más detalle la posibilidad de utilizar WHOIS al discutir el trabajo futuro.
Por otra parte, en el segundo caso las soluciones existentes intentan obtener información sobre
la topologı́a de la red realizando observaciones y mediciones indirectas. Una solución de referencia
es Ono [21], desarrollado por Choffnes y Bustamante. Se proponen aprovechar la infraestructura de
CDNs (Content Distribution Networks)10 para obtener información sobre la agrupación de peers
en ISPs. Ono propone utilizar la redirección DNS provista por las CDNs para inferir la cercanı́a
de los peers de un sistema P2P.
Disminuir el tráfico inter-ISP tiene un efecto directo sobre los costos de un ISP. Creemos que
un cambio en las aplicaciones P2P que tienda a controlar el tráfico generado por ellas podrı́a
ser un incentivo para que los ISPs no limiten de la misma manera el tráfico interno que el tráfico
externo. Cuánto más ancho de banda tengan los peers del mismo ISP entre sı́, más tráfico inter-ISP
podrá transformarse en tráfico intra-ISP.
2.5.
El debate sobre las coordenadas
El crecimiento de las aplicaciones peer-to-peer ha reavivado el debate sobre la estimación de
latencia. Para las aplicaciones peer-to-peer es útil tener la posibilidad de aproximar la latencia
entre sus nodos, que suelen estar distribuidos por todo el mundo. Una estimación correcta de
la latencia que permita guiar el intercambio de datos puede ser la diferencia entre performance
aceptable y mala, del lado de la aplicación; y entre distintos esquemas de costos para el ISP.
Esto ha generado la aparición de nuevos mecanismos y protocolos dedicados a la estimación
de latencia, entre los que podemos mencionar a GNP [22], Vivaldi [7] y Meridian [12]. Tanto
GNP como Vivaldi se enmarcan en los mecanismos de coordenadas virtuales, que consisten en
9 WHOIS es un protocolo utilizado para averiguar la entidad dueña de un nombre de dominio, dirección IP o
sistema autónomo.
10 Las CDNs, como su nombre lo indica, son redes de distribución de contenido. Funcionan como nexo entre
los proveedores, por ejemplo los sitios Web de canales de televisión, y los consumidores en los ISPs. Colocando
servidores propios en los ISPs, servidores que cachean o almacenan enteramente el contenido, las CDNs se aseguran
de que los clientes lo accedan de manera local. Esto es especialmente importante para la distribución de video, en
la cual una latencia razonable es importante para que el video no se vea entrecortado.
La distribución de usuarios a servidores se realiza mediante redirecciones DNS. Cuando un usuario solicita
contenido almacenado en una CDN, la dirección IP que recibe para una URL dada se resuelve teniendo en cuenta
su localización geográfica y en la red. De esta manera, accederá a la copia del contenido presente en el servidor más
cercano (geográficamente, o en términos de latencia) a él.
8
asignar un identificador o coordenada 11 a cada nodo participante de la red. Cada nodo, teniendo
la información de su coordenada y la coordenada de un nodo remoto, puede estimar la latencia
contra ese nodo remoto realizando una operación local con las coordenadas. Meridian, en cambio,
prescinde de asignar coordenadas a los nodos y utiliza un mecanismo de medición directa.
Los mecanismos de coordenadas virtuales han sido objeto de un fuerte debate desde su introducción para su utilización en el problema P2P. Sus crı́ticos argumentan que la necesidad de
etiquetar cada nodo con un identificador acarrea inevitablemente una cuota de error que mecanismos que no utilizan coordenadas como Meridian pueden evitar. Los defensores de las coordenadas
(entre los que nos encontramos) consideran que los márgenes de error son bajos, y que incluso
ası́ la información no deja de ser útil. Este trabajo contribuye al debate mostrando que incluso
con error, las coordenadas son útiles cuando uno no quiere información absoluta de latencia sino
algo más simple: distinguir peers cercanos de peers lejanos, de manera relativa.
Gran parte de la discusión se centra en la factibilidad de utilizar los sistemas de coordenadas
en aplicaciones reales, fuera del ámbito académico. Los crı́ticos sostienen que la mayor parte de
la experimentación con sistemas de coordenadas se ha realizado en ambientes de experimentación
controlados como PlanetLab [23]. La red PlanetLab está conformada exclusivamente por nodos
en universidades y centros de investigación. Estos nodos tienen conexiones a Internet que no
sufren los problemas de latencia y ancho de banda presentados por las conexiones residenciales
de banda ancha. Por esta razón, los resultados de la experimentación sobre PlanetLab podrı́an no
ser representativos del comportamiento de una aplicación en Internet en general. En particular, la
alta LML de las conexiones de banda ancha residencial podrı́an generar coordenadas con mucho
error [7], haciendo que los sistemas de coordenadas se comporten mucho peor en la realidad que
en la experimentación en PlanetLab.
Por otro lado, la evaluación de los sistemas de coordenadas, especialmente en el ámbito académico, se suele realizar de manera autónoma. Las coordenadas se construyen para un conjunto de
nodos que no está ejecutando ninguna aplicación en particular. El objetivo, sin embargo, es que
las coordenadas contribuyan a las decisiones de alguna aplicación. El mejor caso es que la información del protocolo de coordenadas se intercambie a cuestas del tráfico normal generado por esa
aplicación, ya que entonces se estarı́a obteniendo la información necesaria para estimar la latencia
sin generar tráfico extra. No obstante, sucede que muchas veces los sistemas de coordenadas son
sensibles a los patrones de tráfico, y esta manera de intercambiar la información puede degradar
las coordenadas notablemente, como se describe en [11].
Más allá de los detalles, la cuestión básica es si Internet tiene una topologı́a suficientemente
amigable como para ser capturada por un espacio métrico de pocas dimensiones. ¿Es Internet
“plana”, en el sentido dimensional? El debate está abierto, con argumentos de ambos lados. En
[24], por ejemplo, se argumenta que las tecnologı́as P2P llevarán a un “aplanamiento” de Internet.
11 Se utiliza el término coordenada ya que estos identificadores suelen ser elementos de un espacio métrico determinado.
9
3.
Enfoque
Este trabajo propone utilizar coordenadas virtuales para la estimación de latencia en un swarm
BitTorrent. Esta información de latencia permite que los peers del swarm intercambien piezas
preferentemente con otros peers de su mismo ISP, y de esta manera se aumenta el tráfico intraISP en el swarm.
Una parte importante del uso de aplicaciones P2P se da en conexiones de banda ancha residencial. El único análisis que encontramos del comportamiento de los sistemas de coordenadas fuera
de simuladores o entornos de experimentación se encuentra en [11]. Allı́ se presenta un estudio de
la implementación del protocolo Vivaldi en el cliente de BitTorrent Azureus. Sin embargo, Azureus
no utiliza la información de coordenadas para guiar el intercambio de piezas o la elección de peers,
sino para hacer más eficiente la implementación de una DHT12 . [11] muestra las limitaciones de
Vivaldi en una implementación real en Internet intercambiando la información de coordenadas
a cuestas del tráfico de otra aplicación, y propone modificaciones a Vivaldi para superarlas. Sin
embargo, no permite caracterizar el comportamiento de Vivaldi en las condiciones de las redes de
banda ancha residencial, ni su uso como estimador de latencia para guiar el intercambio de piezas
en BitTorrent.
Fue necesario entonces caracterizar el comportamiento de Vivaldi en entornos de banda ancha
residencial. Para esto desarrollamos una implementación de Vivaldi sobre el simulador SSFNet [25],
el cual permite diseñar redes con enlaces de latencia variable y cualquier interconexión de nodos.
Ideamos además una pequeña modificación a Vivaldi que intenta minimizar el efecto negativo
de los enlaces de banda ancha residencial en la calidad de las coordenadas; la incluimos en la
implementación para poder validarla.
Elegimos Vivaldi como mecanismo de estimación de latencia en parte porque ya estaba implementado en Azureus, pero sobre todo porque es un protocolo completamente distribuido. Otros
sistemas de coordenadas previos, como GNP [22], requieren un pequeño número de nodos “distinguidos” que se utilizan para realizar el cálculo de coordenadas con mecanismos de triangulación.
Vivaldi resulta una mejor elección para la situación de un swarm de BitTorrent.
Utilizamos el simulador SSFNet inspirados por [26], donde se desarrolla una implementación de
Gnutella sobre SSFNet con el mismo objetivo de aumento de tráfico intra-ISP, aunque sin el uso de
sistemas de coordenadas. SSFNet permite construir redes especificando tanto nodos como routers
y caracterizando los enlaces en base a su latencia y tasa de transferencia. De esta manera se tiene
la posibilidad de simular un protocolo o aplicación en redes de cualquier caracterı́stica, por ejemplo
redes que incluyan enlaces de banda ancha residencial. Por otro lado, la simulación en SSFNet
cubre desde la capa de aplicación hasta la capa IP13 , por lo tanto las redes sufren congestión y de
esta manera su comportamiento se aproxima mejor a la realidad que en una simulación a nivel de
aplicación.
Construimos una red con enlaces de banda ancha residencial inspirada en un ISP grande de
Argentina y evaluamos nuestra implementación de Vivaldi. Con estos resultados desarrollamos,
también sobre SSFNet, una implementación de BitTorrent, ya que no encontramos disponible
ninguna herramienta que nos permitiera experimentar con BitTorrent al nivel que necesitábamos.
Sobre esta implementación validamos nuestra modificación al algoritmo central de BitTorrent,
que consiste en utilizar la información de cercanı́a en el momento de decidir a qué peers un nodo
va a subir piezas. En la implementación original de BitTorrent esta elección se realiza teniendo
en cuenta la tasa de transferencia de los peers hacia el nodo. Nuestra modificación utiliza la
información de latencia para desempatar entre peers que tengan tasas de subida similares. De esta
manera intentamos garantizar que los nodos no perderán velocidad de bajada, sino que redirigirán
12 Una DHT (Distributed Hash Table) es un sistema totalmente distribuido que provee un servicio de búsqueda
de pares clave-valor similar a una tabla de hash. Cualquier nodo participante en la DHT puede obtener de manera
eficiente el valor asociado a cualquier clave. La responsabilidad de mantener la asociación entre claves y valores
se distribuye entre los nodos de manera de que la llegada y partida de nodos del sistema genere una mı́nima
perturbación. Esto posibilita que las DHTs escalen a una gran cantidad de nodos manejando llegadas, partidas y
fallas constantes de sus participantes. En BitTorrent se utiliza una DHT para implementar un tracker distribuido
y ası́ eliminar el único punto centralizado del protocolo.
13 La capa de red en el modelo OSI.
10
el tráfico para, en caso que se pueda y el resto de los factores sea similar, intercambiar información
entre peers del mismo ISP. Llamamos a este mecanismo upload appeal o interés de subida.
Nuestra implementación de BitTorrent intercambia la información de coordenadas Vivaldi a
cuestas del mismo tráfico generado por el protocolo. Creemos que ésta es la manera más simple
para que las aplicaciones P2P tengan posibilidad de estimar la latencia entre los nodos corriendo la
aplicación. La carga extra de datos es mı́nima, ya que las coordenadas son como máximo 16 bytes
en mensajes que pueden tener varios kilobytes. Debido a esta decisión implementamos, para su
uso con BitTorrent, las modificaciones a Vivaldi sugeridas en [11], y las incluimos en la evaluación.
Evaluamos cómo las coordenadas construı́das por Vivaldi respetan la estructura de la red
subyacente, y la factibilidad de utilizar estas coordenadas para distinguir peers dentro del mismo
ISP. Dado que nuestro objetivo principal es aumentar el tráfico intra-ISP de los swarms BitTorrent,
esa fue la métrica que utilizamos en la evaluación de nuestra modificación al protocolo. No obstante,
también analizamos el comportamiento de Vivaldi en la implementación de BitTorrent, para poder
cuantificar el impacto de utilizar sistemas de coordenadas a cuestas de una aplicación, frente a
utilizarlos de manera autónoma.
11
4.
Vivaldi
Muchas aplicaciones de red necesitan medir o poder estimar la latencia entre los nodos utilizando la aplicación. En nuestro caso, esta información serı́a útil para guiar el comportamiento de
los peers del swarm BitTorrent.
La solución más simple es realizar la medición de latencia en cada momento en que se necesite.
Sin embargo, esto puede resultar en un gasto innecesario o peor, inaceptable si la cantidad de
nodos es grande o la medición es costosa.
Otra posibilidad es que los nodos estimen la latencia entre sı́ de manera local, sin acceder a la
red. Cada nodo deberá tener suficiente información para poder realizar la estimación, pudiendo
obtenerla de la comunicación realizada por la aplicación, o intercambiándola explı́citamente con
el resto de los nodos. Mientras este intercambio requiera menos ancho de banda que la medición directa, esta estrategia será una mejora. Por otro lado, una vez que los nodos poseen esta
información, las estimaciones no requieren acceso a la red.
Esta información podrı́a ser la “ubicación” de los nodos, de manera que la distancia entre
las ubicaciones de dos nodos sea una buena estimación de la latencia entre ellos. Buscaremos
entonces embeber 14 los nodos en un espacio métrico, asignando una coordenada a cada uno de
ellos, de manera que la distancia entre las coordenadas de cualquier par de nodos sea una buena
estimación de la latencia entre ellos.
4.1.
El protocolo Vivaldi
Vivaldi [7] es un protocolo desarrollado para atacar el problema de la estimación de latencia.
Propone un mecanismo para que cada nodo pueda ajustar su propia coordenada, a medida que
conoce las coordenadas de otros nodos y mide su latencia contra ellos; este mecanismo es independiente del espacio métrico elegido. La idea básica del protocolo es que con una cantidad de
mediciones mucho menor a la cantidad total de nodos, cada nodo podrı́a obtener una coordenada que le permita estimar la latencia contra cualquier otro nodo, conociendo solamente la
coordenada de ese nodo.
Las latencias en Internet, sin embargo, suelen escapar a intentos de describirlas en función
de geometrı́as o espacios métricos determinados. El ruteo de paquetes suele estar afectado por
decisiones de negocios, y la conectividad en el núcleo de la red debe acomodar intereses económicos.
Esto genera numerosas violaciones de la desigualdad triangular 15 : puede suceder que sea más rápido
(en términos de latencia) pasar por un nodo intermedio para llegar de un nodo a otro, que recorrer
el enlace que conecta esos dos nodos directamente.
Dado que las métricas para estos espacios deben cumplir la desigualdad triangular, una inmersión 16 de nodos de Internet en un espacio métrico nunca será exacta, pues como mı́nimo los pares
de nodos que rompen la desigualdad triangular no serán embebidos respetando la distancia entre
sı́. El protocolo Vivaldi busca minimizar la suma del cuadrado de los errores entre pares de nodos,
valor que que llamaremos E:
XX
E=
(Lij − kxi − xj k)2
i
j
Lij es la latencia entre el nodo i y el nodo j. xi y xj son las coordenadas de los nodos i y j
respectivamente, y entonces kxi −xj k es la distancia entre la coordenada del nodo i y la coordenada
del nodo j. Esta distancia será la estimación de latencia, y por lo tanto Lij − kxi − xj k es el error
de la estimación para el par de nodos i, j.
14 En
este contexto, embeber un conjunto (por ejemplo, un conjunto de nodos) en un espacio significa incluir
estos nodos en el espacio, no directamente sino asociando cada elemento del conjunto con un elemento del espacio.
De esta manera los elementos del conjunto toman la estructura del espacio, ya que las operaciones del espacio se
pueden aplicar a los elementos del conjunto utilizando los elementos del espacio asociados.
15 La desigualdad triangular afirma que en cualquier triángulo la longitud de uno de los lados no puede nunca
superar a la suma de las longitudes de los otros dos.
16 Llamamos inmersión al proceso de embeber un conjunto en un espacio métrico.
12
4.2.
Interpretación fı́sica
El algoritmo Vivaldi simula el comportamiento de una malla de resortes. Imaginemos que
tenemos puntos representando los nodos, los fijamos de manera que no se puedan mover, y los
unimos entre sı́ con resortes. El resorte que utilizamos para unir dos puntos tiene una longitud
en reposo (cuando no se lo está estirando o comprimiendo) igual a la latencia entre los nodos
representados por los puntos.
Después de conectar todos los resortes, liberamos los puntos. Es lógico pensar que el sistema
no va a quedar estático: una vez que empezamos a conectar resortes, puede ser que para conectar
algún resorte hayamos tenido que estirarlo o contraerlo. Este resorte va a hacer fuerza para volver
a su posición de reposo, pero al hacer esto va a empujar o tirar del punto que representa al nodo
y por lo tanto va a empujar o tirar de otros resortes, lo que va a generar una fuerza contraria.
El estado de reposo de la malla será cuando cada resorte tire de manera que ningún punto
se mueva: es el estado de mı́nima energı́a. En este estado, es de esperar que la longitud de cada
resorte sea parecida a su longitud en reposo: la fuerza ejercida por el resorte es proporcional al
desplazamiento desde la situación de reposo. Si el resorte estuviera muy estirado estarı́a ejerciendo
mucha fuerza y tendrı́a que estar siendo contrarrestado por otros resortes ejerciendo también
mucha fuerza. Este estado de mı́nima energı́a minimiza el error E.
La ubicación de cada punto en el estado de reposo de la malla será la coordenada final del
nodo. Dado que la longitud del resorte en ese caso será cercana a la longitud en reposo del resorte,
es de esperar que la distancia entre coordenadas (la longitud del resorte en el estado de reposo de
la malla) sea una buena estimación de la latencia (la longitud del resorte en reposo). La longitud
del resorte cuando la malla está en reposo no es similar a la longitud del resorte en reposo: en
el primer caso lo que está en reposo es la malla entera, y es posible que esto genere que el resorte
esté ligeramente estirado o comprimido.
De esta manera, cada resorte tira de los puntos a los que está sujeto con una fuerza proporcional
a la diferencia D entre su longitud en reposo (la latencia, Lij ), y su longitud con la malla en reposo
(la distancia, kxi − xj k):
D = (Lij − kxi − xj k)
Esa fuerza se ejerce en la dirección dada por el vector unidad ~u 17 correspondiente a la recta
que pasa por xi y xj . La fuerza ejercida por el resorte entre xi y xj , Fij , será:
Fij = D × ~u(xi − xj )
En cada nodo i, esa fuerza se combina con todas las otras fuerzas ejercidas por los demás
resortes para obtener la fuerza Fi que afecta al nodo:
X
Fi =
Fij
j6=i
En el caso centralizado (que sirve más que nada para ilustrar el mecanismo) un mismo proceso
calcula todas las coordenadas conociendo todas las latencias. En este caso basta mover cada punto
xi en la dirección de Fi , recomputar las fuerzas, y repetir hasta que el error de las coordenadas sea
suficientemente bajo. Eligiendo correctamente la magnitud del desplazamiento que un nodo puede
realizar en cada paso (como fracción t de la fuerza total Fi ), es posible controlar la velocidad de la
convergencia. Intuitivamente, si en cada paso dejamos que un nodo pueda moverse mucho existe la
posibilidad de que el sistema nunca converja, ya que los puntos siempre saltan sobre la ubicación
de mı́nima energı́a. Por otro lado, si los nodos se mueven poco en cada paso la convergencia podrı́a
ser muy lenta.
Mostramos el caso centralizado en el algoritmo 1. La versión distribuida del protocolo consiste
en que cada nodo simule su movimiento en la malla de resortes, un resorte por vez. Para simular
este movimiento el nodo necesitará, aparte de su coordenada:
17 El vector unidad es un vector en la misma dirección que otro dado pero de módulo 1. Usaremos ~
u(x) para
x
referirnos al vector unidad correspondiente al vector x, ~
u(x) = kxk
.
13
La latencia medida contra el nodo remoto
La coordenada del nodo remoto
Con la coordenada remota y su coordenada local el nodo puede calcular la distancia al nodo remoto. Con la información de latencia puede calcular el error, y por lo tanto saber cuánto
debe desplazarse. La dirección del desplazamiento será dada por el vector diferencia entre las
coordenadas.
De esta manera, entonces, cada vez que el nodo realiza una medición de latencia contra otro
nodo puede actualizar su coordenada simulando el movimiento del resorte que unirı́a a ambos.
Esta medición puede ser explı́cita (se genera tráfico para realizar la medición) o implı́cita (se mide
la latencia del tráfico normal que genera la aplicación). Dado que las latencias en una red pueden
variar con el tiempo, en el caso distribuido el nodo no deja nunca de actualizar su coordenada, para
poder reaccionar a los cambios en la latencia. Mostramos esta versión básica del caso distribuido
en el algoritmo 2.
Algoritmo 1 Algoritmo Vivaldi, versión centralizada
{L es una matriz que contiene la latencia entre todo par de nodos}
{x es un vector que contiene las coordenadas de cada nodo}
while error(L, x) > tolerancia do
for all i do
for all j do
e = Li,j − kxi − xj k
F = F + e × ~u(xi − xj )
xi = xi + t × F
end for
end for
end while
Algoritmo 2 Algoritmo Vivaldi, versión distribuida
{l es la latencia medida por el nodo i contra el nodo j}
e = l − kxi − xj k
xi = xi + t × e × ~u(xi − xj )
4.3.
Desplazamiento adaptativo
Es necesario elegir correctamente la magnitud del desplazamiento t para tener buenas propiedades de convergencia. Sin embargo, con un desplazamiento pequeño la convergencia es lenta, pero
con un desplazamiento grande podrı́amos tener oscilación. El problema es el hecho de que la magnitud del desplazamiento sea constante. Querrı́amos tener un desplazamiento grande al principio,
para acelerar la convergencia, pero un desplazamiento pequeño al final, para encontrar el punto
de mı́nimo error.
El objetivo es obtener buenas coordenadas. Una coordenada es buena cuando su error es bajo.
Al iniciar la aplicación la coordenada es mala, ya que se inicia de manera arbitraria (por ejemplo
al azar, con módulo 1) y por lo tanto tiene mucho error. En esa situación va a ser aceptable
desplazarse mucho, ya que se está buscando, a grandes rasgos, la zona en la cual el nodo debe
ubicarse para tener poco error. Una vez encontrada esta zona, el error será menor, y entonces se
pasará a refinar esa coordenada, desplazándose poco para no “saltar” sobre el punto óptimo.
La magnitud del desplazamiento será lineal en función del error, y la dirección del desplazamiento será dada por la coordenada remota. La magnitud del desplazamiento también dependerá del
error del nodo que informa la coordenada remota. Si ese nodo posee mucho error, desplazarse
mucho confiando en esa coordenada es incorrecto. Ahora, si el nodo local también tiene mucho
14
error, no empeorará su error desplazándose mucho. De esta manera, el objetivo es desplazarse
mucho cuando el error remoto es menor al error local, y desplazarse poco en el caso inverso. Para
lograr esto, Vivaldi utiliza la siguiente fórmula para obtener el desplazamiento en función de los
errores:
t=
el
el + er
De esta manera, si el (el error local) es mucho mayor que er (el error remoto) la expresión
tiende a 1, y si er es mucho mayor que el la expresión tiende a 0. Para estimar su error cada nodo
utiliza un promedio pesado entre la última medición y una estimación histórica. Mostramos la
versión final del caso distribuido en el algoritmo 3.
Algoritmo 3 Algoritmo de Vivaldi, versión distribuida con desplazamiento adaptativo
{ei es el error de xi (la coordenada del nodo local i)}
{ej es el error de xj (la coordenada del nodo remoto j)}
{l es la latencia medida por el nodo i contra el nodo j}
{es es el error relativo de la medición l}
i
t = ei e+e
j
l−kx −x k
i
j
es =
l
ei = es × t + ei × (1 − t)
xi = xi + t × es × ~u(xi − xj )
4.4.
Espacios
El protocolo Vivaldi es, en principio, independiente del espacio que se quiera utilizar para
embeber los nodos. La operatoria del protocolo solamente requiere que los elementos del espacio
(las coordenadas de los nodos) puedan ser sumados y multiplicados por un escalar, y que el espacio
tenga una noción de distancia.
La elección del espacio no es un problema trivial. El objetivo es elegir un espacio que respete la
topologı́a de Internet o de la red que conecta a los nodos de la aplicación. Si el espacio elegido no
embebe correctamente la topologı́a de los nodos, la estimación de las coordenadas tendrá mucho
error. Imaginemos que tenemos cuatro nodos equidistantes en latencia entre sı́. La manera lógica de
ubicar estos nodos es en los vértices de un tetraedro. Si el espacio que elegimos para las coordenadas
de Vivaldi fuera un plano bidimensional, estarı́amos simulando este tetraedro aplastado a dos
dimensiones, y de esta manera encontrarı́amos una solución con mucho más error que si hubiéramos
elegido un espacio tridimensional.
Los nodos de Internet están localizados sobre la superficie de la tierra, lo cual podrı́a sugerir
una geometrı́a euclidiana clásica o incluso una geometrı́a esférica. Sin embargo, eso requerirı́a
que fuera posible la comunicación directa entre cualquier par de nodos, lo cual no sucede en la
realidad. Internet tiene una estructura jerárquica, en la cual los proveedores pequeños compran
tráfico a proveedores más grandes, que son los que mantienen el backbone de Internet. Dos nodos
en distintos proveedores no se comunican directamente.
Esto tiene como consecuencia que la topologı́a de los nodos, si bien están presentes en la
superficie de la tierra, esté determinada en mucho mayor medida por la estructura del backbone y
las decisiones comerciales de comprar tráfico a uno u otro proveedor. Por ejemplo, si los nodos en
Latinoamérica tienen que pasar por Estados Unidos para llegar hasta Europa, es posible que sus
distancias en la red no sean similares a las distancias geográficas, y entonces un espacio esférico
embeba a las coordenadas con mucho error.
En [7] se discuten varios espacios, pero el trabajo propone una modificación al clásico espacio
euclidiano tridimensional en la cual la distancia entre dos puntos se mide desde esos puntos al plano
xy, y luego entre los puntos en el plano xy. Dicho de otra manera, la transmisión de información
entre los nodos de la red se da siempre en el plano; no hay comunicación directa entre nodos por
15
encima del plano. Esto representa la situación actual de Internet en la que la gran mayorı́a de los
nodos está conectado solamente con su ISP, y recién desde ahı́ accede a todo el resto de los nodos
de Internet.
Por lo tanto, cada nodo cubre primero la distancia entre él y su ISP (la distancia entre su
coordenada y el plano), luego cubre la distancia entre su ISP y el ISP del nodo remoto (la distancia
en el plano), y finalmente cubre la distancia desde el ISP remoto y el nodo remoto (la distancia entre
el plano y la coordenada remota). El backbone de Internet está suficientemente interconectado
como para que la transmisión se pueda ver como en un plano. En [7] llaman a este espacio
“vectores de altura” o 2D + H, ya que funciona como un plano euclidiano más la componente de
altura H.
Entonces, si un punto en el espacio euclidiano 3D está descripto por tres valores, la modificación
conserva estos tres valores, pero su operatoria es distinta. En el espacio euclidiano 3D:
(x1 , x2 , x3 ) − (y1 , y2 , y3 ) = (x1 − y1 , x2 − y2 , x3 − y3 )
k(x1 , x2 , x3 )k =
q
x21 + x22 + x23
k · (x1 , x2 , x3 ) = (k · x1 , k · x2 , k · x3 )
En el espacio vectores de altura de Vivaldi, 2D+H:
(x1 , x2 , x3 ) − (y1 , y2 , y3 ) = (x1 − y1 , x2 − y2 , x3 + y3 )
k(x1 , x2 , x3 )k =
q
x21 + x22 + x3
k · (x1 , x2 , x3 ) = (k · x1 , k · x2 , k · x3 )
La componente H o “altura”, que es siempre no negativa, se suma al calcular el vector diferencia,
y se suma de manera diferenciada al calcular la norma de cualquier vector. Esta es la manera de
expresar matemáticamente la idea de que el tráfico entre dos nodos siempre tiene que salvar el
link de acceso (por ejemplo, la conexión residencial de banda ancha) antes de llegar al backbone.
De esta manera, la latencia de esta comunicación incluye recorrer las dos alturas, y luego salvar
la distancia en el plano, que sı́ se comporta como un espacio euclidiano bidimensional (figura 3).
Un detalle importante es que si en el espacio euclidiano 3D un nodo se encontraba en una
posición en la cual estaba muy cerca de otros nodos, en todas direcciones, iba a ser empujado
de todos lados por los resortes correspondientes a estos nodos. Sin embargo, al venir de todas
direcciones, estas fuerzas se iban a cancelar, haciendo que el nodo no se moviera. Esto dejarı́a al
nodo teniendo una coordenada con mucho error, ya que está demasiado cerca de los otros nodos.
En el espacio vectores de altura el nodo siempre puede alejarse un poco más del plano euclidiano
si se encuentra demasiado cerca de muchos otros nodos, y este alejamiento aumentará la distancia
a todos los otros nodos, disminuyendo el error.
4.5.
Modificaciones al protocolo Vivaldi
En [11] se presentan tres modificaciones al protocolo Vivaldi original, con el objetivo de mejorar
su comportamiento especı́ficamente en el caso en que la información del protocolo es enviada a
cuestas del tráfico normal de la aplicación que lo utiliza. En ese trabajo se analiza en particular
la implementación de Vivaldi en Azureus.
Las modificaciones son:
Coordenadas de cinco dimensiones
Filtro de mediana
16
Distancia en el espacio euclidiano 3D
Distancia en el espacio vectores de altura
(1, 1, 5)
5
(4, 4, 3)
4
Z, H
3
2
1
0
5
4
0
3
1
2
X
2
3
4
Y
1
5 0
Figura 3: Cálculo de distancia en el espacio vectores de altura
Ampliación del conjunto de vecinos
Utilizar cinco dimensiones para las coordenadas intenta superar el problema de que tres componentes puede ser poco para capturar la información de latencias entre los nodos. Existen métodos
que permiten calcular qué porcentaje de la información es capturada por cada dimensión en un
sistema de coordenadas. Teniendo la matriz de distancias todos contra todos, se puede aplicar
PCA (Principal Component Analysis)18 . Los análisis con PCA de matrices de latencia sugieren
que se necesitan muchas dimensiones para capturar la mayor parte de la información. Sin embargo,
coordenadas con pocas dimensiones han tenido buen comportamiento en distintos experimentos.
En [11] proponen aumentar el espacio de vectores de altura a cinco dimensiones, manteniendo la
quinta componente de ese nuevo espacio con el mismo comportamiento que la tercera componente
del espacio vectores de altura original. Llamamos a este espacio, siguiendo nuestra nomenclatura,
4D + H:
(x1 , x2 , x3 , x4 , x5 ) − (y1 , y2 , y3 , y4 , y5 ) = (x1 − y1 , x2 − y2 , x3 − y3 , x4 − y4 , x5 + y5 )
q
k(x1 , x2 , x3 )k = x21 + x22 + x23 + x24 + x5
k · (x1 , x2 , x3 ) = (k · x1 , k · x2 , k · x3 , k · x4 , k · x5 )
El filtro de mediana responde a las situaciones en las cuales las mediciones de latencia son
anómalas. Es normal que retrasos en algún punto de la red generen mediciones de latencia mucho
mayores a las normales. Estos desvı́os son corregidos tomando siempre la mediana de las últimas
mediciones para realizar la actualización de las coordenadas. En [11] eligen la mediana como
estimador ya que es más resistente a valores anómalos que la media.
La ampliación del conjunto de vecinos responde a la situación en la cual la comunicación de
Vivaldi es enviada a cuestas del tráfico normal de una aplicación. Esto tiene como consecuencia
que Vivaldi no tenga control sobre con qué nodos se comunica, ni a qué ritmo. Por lo tanto, puede
18 PCA es un cambio de coordenadas, una transformación ortogonal que expresa la matriz recibida de manera
que cada componente de las nuevas coordenadas exprese la mayor cantidad de varianza posible. La matriz obtenida
con PCA resulta tener la mayor varianza en la primera componente, y de manera descendiente en las siguientes.
Además, se obtiene una medida de qué proporción de la varianza total está concentrada en cada componente.
17
suceder que la comunicación con el resto de los nodos sea poco uniforme o constante. Habrá mucha
comunicación con algunos nodos y otros que se verán una sola vez. Es necesario realizar un mı́nimo
de intercambios entre todos los nodos para que las coordenadas tengan buenas propiedades [7],
pero esto no se puede garantizar en este caso.
Para reducir este problema, en [11] proponen agrandar artificialmente el conjunto de vecinos
contra los que un nodo actualiza su coordenada. En vez de que la información provista por un
nodo remoto se utilice completamente para una sola actualización, el trabajo propone dividir
esa actualización y escalarla de manera de poder realizarla de a pasos, combinada con otras. Esta
modificación mantiene un conjunto de vecinos recientes, y cada actualización de coordenadas tiene
en cuenta toda esa información. Para que esto no signifique desplazar al nodo más de lo normal,
la fuerza Fij generada por un vecino j en el nodo i se normaliza (Fij? ) de la siguiente manera:
aM − aj
Fij? = Fij × P
k aM − ak
Donde ak indica la edad de la última medición de latencia contra el nodo k. La fuerza final
con la que se desplaza el nodo es la suma de la fuerza generada por cada nodo en el conjunto de
vecinos. aM es la edad del vecino del cual recibimos una actualización hace más tiempo. A partir
de una cierta edad, la información del vecino se descarta.
De esta manera, se escalan las fuerzas de acuerdo a cuan recientemente fueron actualizadas.
La influencia de los nodos remotos es entonces extendida en el tiempo, aún si fueron contactados
una sola vez, y en consecuencia se expande el conjunto de vecinos contra el cual se actualizan las
coordenadas.
4.5.1.
La modificación a Vivaldi propuesta en este trabajo
En [7] se argumenta que el espacio de vectores de altura embebe correctamente la topologı́a
actual de Internet porque la componente H captura la latencia del link de acceso de cada nodo.
Esta latencia es uno de los problemas al utilizar sistemas de coordenadas como Vivaldi en una red
que incluye enlaces de banda ancha residencial.
Si la distancia entre dos nodos se calculara excluyendo la componente H, estarı́amos evitando
la latencia del link de acceso (la LML) en la estimación. En el caso de dos nodos del mismo ISP,
dado que la LML comprende casi toda la latencia entre ellos, obtendrı́amos una distancia casi
nula. Para dos nodos en distintos ISPs obtendrı́amos una distancia proporcional a la latencia del
enlace inter-ISP que une a ambos ISPs. De esta manera serı́a más fácil identificar peers dentro del
mismo ISP, ya que los nodos estarı́an separados solamente por la latencia de los enlaces inter-ISP,
y de esta manera los nodos en el mismo ISP estarı́an muy cerca unos de otros.
Excluir la componente H del cálculo de distancia equivale a que la distancia entre dos nodos
sea estrictamente la distancia entre sus proyecciones en el plano xy. Por esta razón llamaremos a
esta modificación distancia en el plano. No podemos realizar este cálculo modificado al construir
las coordenadas, pues si subestimamos la distancia calcularemos también un error incorrecto.
Nuestra propuesta consiste entonces en excluir la componente H solamente para las estimaciones
de latencia requeridas por la aplicación utilizando Vivaldi. Dicho de otra manera, las coordenadas
se construyen normalmente pero cuando el programa utilizando Vivaldi pide una estimación de
distancia la componente H no se tiene en cuenta.
18
5.
BitTorrent
BitTorrent [6] es un protocolo para distribuir archivos en Internet y en redes locales en el cual
los nodos que bajan el archivo contribuyen al mismo tiempo a distribuirlo, subiendo partes del
archivo a otros nodos que lo están bajando. De esta manera es posible que un nodo con poco ancho
de banda distribuya un archivo a muchos otros, sin sufrir un incremento lineal en la demanda a
medida que crece el número de nodos bajando el archivo.
5.1.
El protocolo BitTorrent
BitTorrent es un protocolo P2P en el que los nodos que están bajando el archivo, a los que
llamaremos peers 19 , deben también subir partes de este archivo a otros peers para a su vez poder
bajar de ellos. De esta manera el costo de ancho de banda de subida es distribuido entre todos los
peers.
El conjunto de peers bajando el archivo se denomina swarm. Algunos de esos peers tendrán
el archivo completo; los llamaremos seeds. Un nodo expresa su interés en convertirse en peer y
unirse al swarm obteniendo un archivo de metainformación con extensión .torrent, y abriéndolo
en su cliente BitTorrent. Este archivo se distribuye generalmente por la Web. El archivo .torrent
contiene la descripción del torrent, y contiene además la dirección del tracker. El tracker es un
servidor encargado de mantener la información del swarm (quiénes están bajando el torrent en
cada momento) y de proveer al nodo con el conjunto inicial de peers al cual se va a conectar
para comenzar a bajar el archivo. El tracker elije aleatoriamente un subconjunto de peers para
devolverle al nodo en cuestión.
El archivo a bajar se divide en piezas de tamaño fijo para facilitar su intercambio entre los
peers. Una vez que un peer terminó de bajar una pieza entera, ya puede empezar a ofrecerla a los
demás peers. Ası́ es como las piezas y el archivo se replican una vez bajadas del nodo que tenı́a el
archivo originalmente, que es el primer seed.
5.2.
Comunicación entre los peers
Los peers se comunican entre sı́ para intercambiar estado y piezas, y de esta manera poder completar la transferencia del archivo. En todo momento, cada nodo mantiene el estado de qué piezas
posee. Cada vez que completa una pieza, avisa a todos los peers con los que está conectado, para
que eventualmente puedan empezar a pedirle esa pieza.
Para mostrar la interacción de los peers describiremos el comportamiento de un peer, al que
normalmente nos referiremos como peer local. Como BitTorrent es una aplicación P2P, todos
los peers se comportan de una manera similar. En algunas situaciones será necesario distinguir al
peer local de los otros peers con los que está conectado. A éstos últimos los llamaremos peers
remotos. Finalmente, cuando hablemos de las tasas de transferencia entre los peers lo haremos
desde la perspectiva del peer local. De esta manera, la tasa de bajada, a secas, es la tasa de
transferencia en sentido hacia el peer local; la tasa de subida, a secas, es la tasa de transferencia
desde el peer local. Sin embargo, en algunos casos invertiremos el sentido de estos términos, pero
siempre aclarando el sentido de la transferencia.
Cuando un peer inicia la comunicación con otro, el primer paso es un intercambio de información o “handshake” que tiene como objetivo verificar que ambos peers estén bajando el mismo
torrent y que ambos posean información correcta sobre el torrent. Luego del handshake los peers
intercambian un mensaje opcional que indica qué piezas posee cada uno. De esta manera, un peer
sabe al conectarse con otro si va a poder bajar piezas de él o no.
Cada conexión de un peer con otro requiere cuatro bits de estado de cada lado: choking e
interesado, para el peer local y para el peer remoto. Un nodo está interesado cuando el peer con
el que está conectado posee piezas que él no posee. El choking se utiliza para controlar la tasa
de transferencia e implementar la polı́tica que obliga a los peers a subir piezas para poder bajar.
Será descripto en profundidad en la sección 5.3.
19 Al
hablar de BitTorrent utilizaremos los términos peer y nodo indistintamente para referirnos a un participante.
19
En todo momento, entonces, cada peer sabe para cada peer remoto con el que está conectado:
Si el peer local está interesado en piezas del peer remoto.
Si el peer remoto está interesado en piezas del peer local.
Si el peer local mantiene en estado choking al peer remoto.
Si el peer remoto mantiene en estado choking al peer local.
Las conexiones entre peers son simétricas (es decir, que no importa quién la haya iniciado,
ambos pueden bajar piezas). La transmisión en cada sentido ocurre cuando el nodo receptor
está interesado y el nodo proveedor no está choking. Por esta razón son necesarios los cuatro bits
de estado: de a pares controlan la transferencia en cada sentido. Las conexiones se inician en estado
no interesado y choking, de ambos lados.
Las piezas en las que se dividió el archivo se parten a su vez en bloques de un tamaño apropiado
para poder ser transmitidos de manera completa. Toda la comunicación se realiza utilizando
TCP20 .
De esta manera, el funcionamiento básico de un cliente de BitTorrent consiste en conectarse
con los peers recibidos del tracker, obtener información sobre qué piezas tiene cada peer al que se
conectó, y comenzar a pedir piezas de acuerdo a esto. Si bien la especificación original de BitTorrent
no prevee ningún orden de bajada para las piezas, artı́culos subsecuentes [6] recomiendan utilizar
el algoritmo rarest first. En este algoritmo el cliente debe elegir la pieza que esté menos repetida
entre los peers que este nodo conoce. De esta manera se incentiva que las piezas se repliquen
de manera uniforme, y entonces todos los nodos pueden subir a todos los nodos, aumentando la
velocidad de bajada para todo el swarm.
Hay una excepción a esta regla: la primera pieza que un peer baja se elije al azar. Dado que sin
una pieza completa un peer no puede subirle a otros peers, es vital conseguir una pieza completa
rápidamente, ya que sin nada para subir será complicado obtener buenas velocidades de bajada.
Por esta razón se evita hacer rarest first para la primera pieza, ya que hacer esto implicarı́a que
la primera pieza fuera una pieza poco repetida, la cual va a tardar obviamente más en bajar que
cualquier otra, porque hay menos peers que la tienen.
Como las piezas se transmiten vı́a TCP en subdivisiones (bloques), la prioridad siempre es
completar una pieza antes de empezar a bajar una pieza nueva; primero se deben completar todos
los bloques que componen una pieza antes de empezar a bajar los bloques de la siguiente. Cada
peer comparte el archivo con granularidad de piezas, y por lo tanto si un nodo no bajó ninguna
pieza completa no podrá ofrecer ninguna pieza a sus peers, y no podrá bajar de ellos.
5.2.1.
Mensajes del protocolo BitTorrent
Una vez establecida la conexión y realizado el handshake, la comunicación entre los peers
consiste en un intercambio bidireccional de mensajes prefijados por su longitud. Cada mensaje es
de uno de los siguientes tipos:
choke. El mensaje choke indica al receptor que el emisor pasa a estar choking, y por lo tanto
no responderá pedidos de bloques.
unchoke. El mensaje unchoke indica al receptor que el emisor no está más choking, y por lo
tanto responderá pedidos de bloques.
interested. El mensaje interested indica al receptor que el emisor está interesado en
bajar piezas que el receptor posee.
20 En la implementación original del protocolo. Una implementación nueva propone reemplazar TCP por UDP
[27].
20
not interested. el mensaje not interested indica al receptor que el emisor no está interesado en bajar ninguna pieza del receptor. Suele implicar que el emisor posee todas las
piezas que el receptor dijo tener.
have. El mensaje have indica que el emisor acaba de terminar de bajar una pieza. Posee un
payload que consiste en un número entero. Ese entero es el ı́ndice (comenzando desde cero)
de la pieza en cuestión.
bitfield. El mensaje bitfield se manda solamente después del handshake. Indica las piezas
que el emisor posee. Contiene un payload consistente en una secuencia de bytes, donde los
bits de cada byte indican si el emisor posee esa pieza en particular o no. El bit más alto del
primer byte corresponde a la pieza de ı́ndice cero.
request. El mensaje request se utiliza para pedir bloques. Su payload consiste en tres
enteros: el ı́ndice de la pieza que contiene el bloque a pedir, el offset donde comienza el
bloque a pedir, y la longitud del bloque.
piece. El mensaje piece contiene el bloque respuesta a los mensajes request. Su payload
consiste en dos enteros y una secuencia de bytes. El primer entero indica la pieza de la cual
es parte el bloque, el segundo entero indica el offset desde el cual comienza el bloque, y la
secuencia de bytes es el bloque en sı́.
cancel. El mensaje cancel se utiliza para cancelar pedidos realizados con mensajes request.
Su payload es igual.
5.3.
Mecanismo de choking
El mecanismo de choking es la manera en la que BitTorrent regula el tráfico y mantiene
condiciones igualitarias entre los peers del swarm: cuanto más subo a mis peers, más ellos me
dejan bajar.
Mandar choke a un peer remoto implica que el emisor del mensaje no va a responder mensajes
request, efectivamente deteniendo la bajada del peer remoto. Recı́procamente, un peer solamente
va a poder bajar de los peers remotos que no están choking.
En todo momento, un nodo mantiene una cantidad fija de peers remotos en estado no choking.
En las versiones actuales de BitTorrent esta cantidad es cuatro. Estos cuatro peers remotos son
los que están subiendo con mayor tasa de transferencia al nodo en cuestión, sin importar si están
interesados o no. Si algún peer remoto en estado no choking no expresa interés, a pesar de haber
recibido el mensaje unchoke, entonces se elige otro peer remoto que esté interesado aunque su tasa
de subida sea menor.
Una vez que un peer termina de bajar el archivo, se convierte en seed y elige subir a quienes
están bajando más de él, en vez de elegir a quienes están subiendo más a él. Los peers en estado
no choking se recalculan cada 10 segundos, para evitar cambiar el estado de los peers demasiado
rápido. La tasa de transferencia, en ambos sentidos, se recalcula cada 20 segundos.
Además de estos cuatro peers, se elige un peer más al azar que se pasa a estado no choking
de manera optimista. El objetivo de esto es examinar peers remotos de los cuales todavı́a no se
ha bajado. Es posible que alguno de estos peers remotos pueda convertirse en un peer que sube
mucho al peer local, pero que todavı́a el peer local no lo sepa porque no han intercambiado piezas.
Este comportamiento optimista es importante para empezar las comunicaciones nuevas, ya que de
otra manera un peer que nunca ha subido no tendrı́a posibilidades de empezar a bajar para luego
poder subir. La implementación de BitTorrent, para reforzar este comportamiento, hace que las
conexiones nuevas sean tres veces más probables de ser elegidas que las demás. Este peer remoto
cambia cada 30 segundos.
El algoritmo de choking implementado en BitTorrent intenta favorecer la reciprocidad. Los
peers que más suben son los que más probabilidad tienen de recibir unchoke y poder bajar. Más
aún, si dos peers están recibiendo pocas piezas de otros peers a los que están subiendo mucho,
21
entonces les conviene comenzar a intercambiar entre ellos; recibirán mejores tasas de subida del
nuevo peer remoto que la tasa que estaban recibiendo antes.
Algoritmo 4 Algoritmo de choking
for all peer p do
if p es uno de los cuatro peers con mejor tasa de subida ∧ p está choking then
mandar unchoke a p
else if p no es uno de los cuatro peers con mejor tasa de subida ∧ p no está choking then
mandar choke a p
end if
end for
mandar unchoke a q peer al azar en estado choking
5.4.
Modo fin-de-juego
Cuando un peer está terminando de bajar el archivo, es posible que los últimos bloques de las
últimas piezas sean bajados de conexiones con poco ancho de banda, retrasando la finalización del
archivo. Para evitar esto, cuando un peer ha realizado pedidos de todas las piezas que debe bajar,
manda pedidos de todos los bloques que le faltan a todos los peers de los que está bajando. De
esta manera se contribuye a que los últimos bloques no tarden tanto en aparecer.
Dado que esto podrı́a generar mucho tráfico inútil, al recibir un bloque que habı́a sido pedido
a todos se utiliza el mensaje cancel para cancelar el resto de los pedidos. Es la utilidad principal
de este mensaje.
5.5.
Un ejemplo de comunicación entre peers
Un nodo inicia la comunicación TCP con un peer remoto. Recordar que las conexiones se
inician por default en estado no interesado y choking. Una vez realizado el handshake, intercambian
mensajes bitfield. El mensaje bitfield no es obligatorio si un peer no tiene ninguna pieza. Una
vez que ambos peers saben que piezas tiene el otro, pueden expresar su interés. Si algún lado de
la conexión estuviera interesado deberı́a mandar el mensaje interested. Es importante mantener
actualizado el estado interesado, porque de esta manera un nodo puede saber qué peers iniciarı́an
pedidos inmediatamente si fueran pasados a estado no choking.
Suponiendo que algún lado de la conexión estuviera interesado, al recibir un unchoke deberı́a
mandar mensajes request de los bloques de la pieza a bajar. Como describimos antes, el protocolo
baja de a una pieza por vez, tratando de completar una pieza antes de iniciar la siguiente. Por
lo tanto, los mensajes request serán enviados siguiendo este esquema, primero se pedirán todos
los bloques de una misma pieza antes de empezar a pedir los bloques de la pieza siguiene. El otro
lado de la conexión responderı́a con mensajes piece.
Eventualmente algún lado de la conexión completará una pieza, no necesariamente por esa
conexión. El peer que completó la pieza debe enviar al peer remoto el mensaje have indicando
esto. El peer remoto podrı́a volverse interesado, si no lo estuviera, ya que no posee esa pieza en
particular. En ese caso el peer remoto mandarı́a el mensaje interested. También podrı́a suceder
que con esa pieza, el peer local ya no tuviera nada más que bajar del peer remoto, en cuyo caso
mandarı́a el mensaje not interested.
A medida que los peers intercambian piezas, las tasas de transferencia se modifican. Los peers
intercambiarán también mensajes choke y unchoke mientras vayan cambiando el estado choking
de sus conexiones, siguiendo las tasas de transferencia.
22
6.
El simulador SSFNet
SSFNet [25] es un simulador de red desarrollado en Java y montado sobre un simulador por
eventos discretos llamado SSF (Scalable Simulator Framework). SSFNet funciona, a grandes rasgos, como una capa de abstracción entre las primitivas de simulación de SSF (eventos y canales)
y las estructuras necesarias para simular redes (hosts, routers, enlaces, protocolos y transmisión
de bits). Dado que SSF es un simulador por eventos discretos, SSFNet funciona modelando el
envı́o de información en pasos discretos de tiempo. El objeto básico de la simulación es el paquete
IP. En cada intervalo de tiempo el simulador transmite paquetes IP en los enlaces definidos por
el usuario, realizando ruteo y ejecutando los protocolos provistos por el usuario. Estos enlaces se
describen a nivel IP mediante su latencia y su tasa de transferencia máxima.
Los modelos de SSFNet se configuran de manera autónoma: cada instancia de una clase de
SSFNet se inicializa consultando una base de datos de configuraciones que puede estar presente
localmente o disponible en la Web. Los archivos de configuración se escriben en DML, un lenguaje
de descripción simple que mostraremos en la sección 6.5. Estos archivos se utilizan tanto para
configurar el modelo completo como para instanciar la simulación, con la ayuda de la base de
datos provista por SSF.
Las clases principales utilizadas en SSFNet están organizadas en dos paquetes: SSF.OS y
SSF.Net. Las clases de SSF.OS se utilizan para modelar cada host, incluyendo los componentes normalmente provistos a una aplicación por el sistema operativo, incluyendo los protocolos
como IP y TPC o UDP. Las clases de SSF.Net se utilizan para modelar la red y su conectividad,
incluyendo nodos, enlaces y sus caracterı́sticas.
6.1.
La jerarquı́a de clases en SSF.OS
El simulador provee tres clases que sirven como clases base para implementar un nuevo protocolo: ProtocolGraph, ProtocolSession y ProtocolMessage. La clase ProtocolGraph configura
e inicializa instancias de ProtocolSession. Los objetos ProtocolSession procesan la apertura y
cierre de conexiones individuales, por las cuales se transmiten instancias de ProtocolMessage.
Podemos ver a los objetos ProtocolGraph como contenedores de todos los protocolos presentes
en un host o en un router. Estos objetos crean los servicios de todos los protocolos al iniciar la
simulación, y luego pueden localizarlos a pedido de otros protocolos o aplicaciones.
La clase ProtocolSession es la clase base de la cual derivan todas las clases que representan
protocolos de red en SSFNet. Para los protocolos provistos por SSFNet (por ejemplo TCP) se
suelen tener dos clases que heredan de ProtocolSession: una que provee servicios para iniciar
nuevas conexiones y demultiplexar todos los mensajes del protocolo que llegan al host, y otra que
representa una conexión única entre dos hosts.
Los objetos ProtocolSession son nodos en el objeto ProtocolGraph que, como su nombre lo
indica, puede verse como un grafo dirigido acı́clico. Los ejes representan relaciones de “depende de”,
donde por ejemplo el objeto ProtocolSession Socket va a depender del objeto ProtocolSession
TCP. Normalmente las hojas de ese grafo serán los protocolos de aplicación, por ejemplo Vivaldi
o BitTorrent en nuestro caso. Los objetos ProtocolSession son configurados automáticamente
por el objeto ProtocolGraph utilizando DML.
Finalmente, ProtocolMessage es la clase básica para modelar fragmentos de paquetes que
serán eventualmente enviados (de manera simulada) por la red. Los objetos ProtocolMessage son
el enlace básico entre el mundo de eventos y canales de SSF, y el mundo de nodos y conexiones de
SSFNet. Los objetos ProtocolMessage son utilizados como payload por la clase PacketEvent, la
clase responsable de crear el canal de comunicación SSF que representa al enlace fı́sico entre dos
nodos.
Un objeto ProtocolMessage consiste en una lista enlazada de headers. El header a la cabeza
de la lista es el del paquete a trasmitir. La cola de la lista, una nueva lista enlazada de headers,
consiste en el payload. Lo interesante de este diseño es que representa la situación de una red real
en la que un frame Ethernet tiene un header y un payload, y ese payload a su vez tiene un header
IP y un payload, y ese payload a su vez tiene un header TCP y un payload. Al eliminar la cabeza
23
de la lista y quedarnos con su cola, el siguiente elemento de la lista es el siguiente header, y la cola
de la nueva lista es el nuevo payload.
Esto podrı́a ser contraintuitivo, porque de esta manera la última lista es aquella que tiene el
último header como header y la lista vacı́a como payload, y de esta manera no se podrı́a transmitir
más información que aquella presente en los headers. Sorpresivamente, esto no es enteramente
erróneo. SSFNet se ejecuta por defecto en una sola computadora, teniendo la posibilidad de que
los objetos que representan nodos puedan compartir memoria, y por lo tanto puedan intercambiar
mensajes simplemente intercambiando referencias a posiciones de memoria. SSFNet implementa
un modelo de transmisión de datos zero copy en el cual lo único que se copia es la referencia a la
información siendo transmitida.
6.2.
Transmisión de información
Para enviar información en SSFNet se tienen dos opciones:
Intercambiar directamente objetos ProtocolMessage, que no pueden tener payload en bytes,
y por lo tanto no generan más tráfico que el tamaño del header.
Utilizar sockets.
Si estamos interesados en realizar una simulación de un protocolo que no requiere transmisión
de grandes volúmenes de información ni envı́o confiable, podemos intercambiar directamente objetos ProtocolMessage, lo que equivaldrı́a a encapsular nuestro protocolo directamente sobre IP.
Basta crear una clase que herede de ProtocolMessage, e indicarle al servicio IP en el nodo que
envı́e la instancia de esa clase. Los objetos ProtocolMessage representan un paquete IP, por lo
tanto conocen su destino en la red.
Los sockets, en cambio, permiten especificar una cantidad de bytes “virtuales” que ocupa el
objeto que estamos mandando. De esta manera, SSFNet simula el envı́o de esa cantidad de bytes,
pero el nodo del otro lado recibe la referencia al objeto, y por lo tanto no requiere preocuparse
por cuestiones de serialización.
Más especı́ficamente, los sockets proveen dos primitivas de envı́o y recepción de información:
write(Object[] obj, int nbytes, Continuation caller)
read(Object[] obj, int nbytes, Continuation caller)
write(int num virtual bytes, Continuation caller)
read(int num virtual bytes, Continuation caller)
Las primeras dos primitivas se utilizan para intercambiar información real que los nodos necesitan para llevar adelante la aplicación, más una cantidad de bytes “virtual”. Esto equivaldrı́a al
intercambio en la realidad de un stream de bytes con header.
Las segundas dos primitivas se utilizan para intercambiar información puramente virtual, que
equivaldrı́a al intercambio en la realidad de un stream de bytes (por ejemplo, la conexión de datos
del protocolo FTP).
Normalmente las primitivas de conexión de sockets (connect() y listen()) y de envı́o y
recepción de mensaje en los sockets (read() y write()) son bloqueantes. SSFNet tuvo que buscar
una manera de simular este comportamiento bloqueante sin que un nodo detenga la simulación
del resto de los nodos. Esto se debe a que el mismo proceso del sistema operativo simula todos los
nodos, por lo tanto una llamada bloqueante no solo detendrı́a la simulación, si no que no permitirı́a
que el nodo receptor de esa llamada pueda atenderla, y de esta manera nunca se volverı́a de este
bloqueo.
La manera que el framework resolvió esto es con el uso de continuaciones. Conceptualmente,
una continuación representa, como su nombre lo indica, la manera de continuar la ejecución. Cada
llamada bloqueante recibe una continuación que indica cómo sigue el cómputo luego de que esa
24
llamada bloqueante termine. De esta manera, las llamadas se simulan bloqueantes, ya que un
nodo siempre espera a que las primitivas terminen; pero el simulador puede continuar ejecutando
eventos del resto de los nodos. Cuando el evento que desbloquea esa llamada ocurre, simplemente
se utiliza la continuación para continuar (valga la redundancia) el cómputo.
Más allá de ser una buena solución para resolver el problema, las continuaciones presentan
problemas técnicos, sobre todo con el simulador programado en Java. Dado que en Java la única
manera de tener algo similar a una clausura o a una función lambda es el uso de clases anónimas, las
continuaciones están implementadas de esta manera. Esto restringe ligeramente la implementación,
ya que la clase anónima puede acceder solamente a las variables de instancia de la clase que la
engloba, no puede acceder a las variables locales de los métodos.
La segunda herramienta importante que el simulador provee para implementar protocolos son
los timers. Nuevamente, se busca que ningún nodo detenga la simulación, y por lo tanto en vez
de dormir esperando un evento, el mecanismo para disparar eventos en el futuro que el simulador
provee son los timers. Éstos están implementados nuevamente como clases anónimas, que poseen
una sola función a ser llamada cuando el timer expire.
6.3.
La jerarquı́a de clases en SSF.Net
Las clases principales del paquete SSF.Net son:
1. Net
2. Host y Router
3. NIC
4. link
La clase Net carga toda la configuración del modelo y controla su inicialización: hosts y routers
con sus protocolos, y los enlaces conectándolos.
La clase Host deriva de ProtocolGraph y por lo tanto es totalmente configurable, soportando
cualquier objeto ProtocolGraph. Este objeto debe poseer como mı́nimo el protocolo IP, para
poder realizar ruteo, y al menos una interfaz de red, para poder interactuar con el resto de la red.
Los objetos de la clase Router son un caso especial de hosts con varias interfaces de red.
La clase NIC deriva de ProtocolSession y es la clase más baja del modelo, interactuando
directamente con SSF. Posee varias opciones de configuración para las caracterı́sticas fı́sicas del
enlace, para poder soportar redes de variadas caracterı́sticas.
Finalmente, la clase link modela un enlace de capa dos entre un conjunto de interfaces conectadas. Cualquier enlace con más de dos interfaces conectadas realizará ruteo de capa dos para los
mensajes recibidos por ese enlace.
6.4.
Direccionamiento
Cada red, host, router e interfaz de red en SSFNet requiere un identificador que debe ser
provisto por el usuario. Estos identificadores se combinan para generar nombres globales que
pueden ser usados para distinguir cada objeto de la simulación. Este modo de direccionamiento se
denomina NHI (Network Host Interface).
Dado que las redes pueden anidarse, cada objeto de la simulación hereda el identificador del
objeto que lo contiene, y agrega su identificador separado por dos puntos “:”. La red global no tiene
identificador, de manera que el nodo con identificador 7 en la subred 2 de la red 5 tendrá identificador 5:2:7. A su vez, cada interfaz agrega su identificador entre paréntesis al identificador del
nodo que la contiene, por lo tanto la interfaz 1 del nodo anterior tendrá identificador 5:2:7(1).
Las interfaces de red que estén efectivamente conectadas recibirán una dirección IP asignada
automáticamente por el simulador al calcular las tablas de ruteo. El direccionamiento NHI permite
entonces al usuario trabajar con nombres estáticos para los nodos, sin tener que preocuparse por
25
el direccionamiento IP. Dado que es normal construir redes de manera anidada, es natural y más
simple utilizar direccionamiento NHI al razonar sobre el modelo, y dejar que el simulador asigne
direcciones IP. Por otro lado, estos nombres proveen información sobre la estructura de la red, cosa
que puede ser útil al programar ciertos protocolos o, en nuestro caso, al analizar los resultados del
simulador.
6.5.
El lenguaje DML
SSFNet incluye un lenguaje simple para describir las redes y configurar las aplicaciones que
van a ejecutar en los nodos llamado DML (Domain Modeling Language). El lenguaje consiste en
conjuntos de pares clave-valor, en los cuales la clave siempre es una cadena y el valor puede ser
tanto una cadena como un nuevo conjunto de pares clave-valor.
DML soporta una forma de herencia que permite que el valor correspondiente a una clave
herede atributos de otro ya definido. Esta es la manera de crear las redes anidadas mencionadas
anteriormente, y salva mucho tiempo en la construcción de redes grandes. Permite generar redes
completamente configuradas especificando solamente su identificador, y luego combinarlas en redes
más grandes, y repetir el proceso todas las veces que el usuario quiera.
26
7.
Implementación de Vivaldi en SSFNet
Uno de los objetivos de este trabajo es caracterizar el comportamiento de Vivaldi en una red
con enlaces similares a las conexiones residenciales de banda ancha. La literatura que encontramos
sobre Vivaldi y su comportamiento se concentra en simulaciones con matrices de latencia todos
contra todos, o en experimentación sobre PlanetLab.
El problema de la experimentación sobre PlanetLab es que los nodos de esta red suelen estar ubicados en universidades. La mayorı́a de las universidades funcionan como pequeños ISPs,
comprando acceso directamente a uno o varios proveedores grande. Sin embargo, el link de acceso
en una universidad puede cubrirse con tecnologı́a Ethernet, ya que las distancias no son largas
como en el caso de un ISP normal. Estos enlaces tienen caracterı́sticas de latencia y ancho de
banda totalmente distintas a las de las tecnologı́as de banda ancha residencial. Por lo tanto, al
experimentar sobre PlanetLab se pueden obtener resultados que no necesariamente se trasladan
a redes que incluyan muchas conexiones de banda ancha residencial, como puede ser la red de un
swarm BitTorrent.
En las conexiones residenciales de banda ancha el link de acceso (la “última milla”) constituye
gran parte de la latencia total entre dos nodos. Si bien el espacio utilizado por Vivaldi respeta una
topologı́a de red en la cual los nodos no pueden comunicarse directamente, los mismos autores
de Vivaldi admiten que la LML alta de las conexiones de banda ancha residencial puede generar
coordenadas con mucho error.
En [11] se estudia la implementación de Vivaldi en Azureus, analizando el comportamiento
de las coordenadas en swarms reales. Es el primer trabajo que describe en profundidad el comportamiento de Vivaldi en el caso en que la comunicación del protocolo se realiza a cuestas de la
comunicación normal de una aplicación. Esta es la manera menos intrusiva de incorporar Vivaldi
a una aplicación, por lo tanto es importante conocer cuánto empeoran las coordenadas generadas
por Vivaldi en este caso, frente a un caso en el que el protocolo puede generar su propio tráfico.
En ese trabajo se encuentran una serie de problemas con la implementación original de Vivaldi
cuando es utilizada de esta manera, y se proponen maneras de remediarlos. Estas modificaciones
se incluyen, de manera configurable, en nuestra implementación.
El problema es que en la situación de [11] no se puede ejercer ningún control, ya que se estudian
swarms reales de BitTorrent. Es una observación pasiva del comportamiento de los swarms, y por
lo tanto algunas preguntas quedan sin respuesta. ¿Qué impacto tiene la LML en la latencia total?
¿Qué efecto tiene la LML en las distancias calculadas? ¿Cuánto afectan las conexiones residenciales
a las coordenadas? No se tiene información acerca del tipo de conexiones utilizadas por los clientes.
Por esta razón planteamos una implementación en un simulador.
Conocer el comportamiento de Vivaldi en una situación de nodos con alta LML es vital para
poder utilizarlo en BitTorrent, donde gran parte de los usuarios se conecta mediante redes de
banda ancha residencial. Aunque las coordenadas se degraden por la alta LML, si el espacio de
vectores de altura propuesto por Vivaldi tiene un buen comportamiento es de esperar que gran
parte de la LML se concentre en la componente H. De esta manera, si la distancia entre dos nodos
se mide como la distancia en el plano (evitando contar la componente H en ambos casos), se podrı́a
evitar este problema.
7.1.
Detalles de la implementación
Realizamos una implementación del protocolo Vivaldi utilizando SSFNet. Dado que Vivaldi no
requiere transmisión de grandes volúmenes de datos, decidimos incorporar toda la información requerida (coordenada y error) en un header Vivaldi, VivaldiHost, que hereda de ProtocolMessage.
Los nodos Vivaldi entonces intercambiarán instancias de esta clase que, recordemos, es la manera
básica de intercambiar paquetes en SSFNet. Intercambiar objetos ProtocolMessage equivale en
la realidad a encapsular esta información directamente en paquetes IP.
Dividimos la implementación en dos clases distintas que heredan ambas de ProtocolSession:
Vivaldi y VivaldiHost. La clase Vivaldi es la implementación del algoritmo básico del protocolo: contiene la lógica para pedir la coordenada a otro host y para actualizar la coordenada local
27
con esta información. La clase VivaldiHost contiene la lógica necesaria para guiar estas actualizaciones: en nuestro caso, son actualizaciones cada un cierto perı́odo configurable de tiempo.
En [7] analizan ciertos aspectos de implementación de Vivaldi que contribuyen a un menor
error en las coordenadas. En particular, mencionan el problema de que si los nodos intercambian
información de coordenadas solamente con otros nodos cercanos, las coordenadas se degradan
entre nodos que estén lejos entre sı́. Proponen entonces garantizar que un pequeño porcentaje
de los intercambios (un mı́nimo del 5 %) sean con nodos lejanos. En nuestra implementación,
esto se resuelve utilizando información de las direcciones NHI. Cada nodo elige al azar el nodo
remoto contra el que va a actualizar, pero antes de eso, en un gran porcentaje de los casos nos
aseguramos que sea una dirección NHI con el mismo identificador de red, y en el porcentaje restante
garantizamos que sea un identificador distinto.
En una implementación real, esta información serı́a difı́cil o incluso imposible de conseguir. Hay
dos caminos para solucionarlo: o bien podemos ignorarlo, que es lo que sucede cuando Vivaldi se
utiliza a cuestas del tráfico de otra aplicación, o podemos elegir ese pequeño porcentaje de nodos
lejanos entre los nodos contra los que ya medimos más latencia.
La implementación tuvo tres objetivos principales. Como primer paso, querı́amos comprobar
que las coordenadas generadas por Vivaldi respetaran la topologı́a de la red subyacente. Esto era
un requisito básico para que la información de las coordenadas pudiera ser utilizada para guiar el
intercambio de piezas en BitTorrent. Luego, querı́amos analizar el comportamiento del espacio de
vectores de altura en el caso de las redes de banda ancha residenciales. En particular, buscábamos
verificar que la componente H de las coordenadas en este espacio capturara razonablemente la
latencia de la última milla. Finalmente, querı́amos caracterizar la factibilidad de usar las coordenadas como método para distinguir pares de nodos en el mismo ISP, eventualmente eliminando la
componente H para evitar la influencia de la LML.
7.2.
La red de prueba para la simulación de Vivaldi
La red de prueba (figura 4) utilizada en la simulación está inspirada en la red del ISP Prima
(Cablevisión/Multicanal). Consta de siete sistemas autónomos (AS)21 , seis de los cuales contienen
clientes residenciales de banda ancha corriendo el protocolo Vivaldi. Dos ASs simulan los clientes
locales de Prima (un AS para la red de Cablevisión y el otro para la red de Multicanal), unidos
por un enlace de latencia baja (1 ms). Otros dos ASs simulan clientes nacionales de otros ISPs
(Telecom y Telefónica), unidos a los ASs anteriores por enlaces de baja latencia (2 ms). Los últimos
dos ASs simulan clientes en el extranjero, conectados al ISP que provee los enlaces internacionales
a Prima. Estos enlaces internacionales tienen una latencia mayor (75 ms). El AS restante (AS 6)
sirve de peering point22 a los ASs locales, y no tiene clientes. En total hay aproximadamente 3000
nodos corriendo Vivaldi, divididos en los seis ASs mencionados. La figura muestra un número que
corresponde a cada AS, para poder referenciarlo luego en los resultados.
Las herramientas que el simulador provee para construir redes permiten combinar redes pequeñas en redes más grandes. La manera más natural de utilizar esto es describir una red pequeña,
generar varias instancias de esta red, cada una con un identificador distinto, y luego conectar estas
instancias generando una red más grande. Para construir nuestra red de prueba primero armamos
una red pequeña que representara a un conjunto de 40 clientes cablemódem y al CMTS que los
conecta con la red del ISP (figura 5). La LML en esta red es de 10 ms, para un total de 20 ms
de RTT cablemódem-CMTS. El simulador no permite especificar latencias asimétricas. Si bien la
latencia de un enlace cablemódem es asimétrica (ver sección 2.3), el tráfico recorrerá siempre un
enlace en sentido upstream (el enlace del nodo emisor) y otro enlace en sentido downstream (el
enlace del nodo receptor). Por esta razón es válido representar la latencia de un enlace cablemódem
21 Un sistema autónomo es un conjunto de nodos IP bajo control de una o más instituciones declaradas, que
presenta una polı́tica de ruteo bien definida hacia el resto de Internet.
22 Un acuerdo de peering entre ISPs consiste en no cobrarse por el tráfico intercambiado entre ellos. Suele ocurrir
cuando dos ISPs intercambian suficiente tráfico en ambos sentidos como para que sea más barato y más simple no
cobrar por el tráfico en vez de cobrarse uno a otro. El peering point es el punto de la red en el cual los ISPs bajo
acuerdo de peering intercambian tráfico.
28
Router BGP representando a un AS sin nodos
Router BGP representando a un AS con 480 nodos cablemódem
10 ms
USA2 (AS 5)
USA1 (AS 4)
75 ms
75 ms
75 ms
1 ms
Cablevisión (AS 0)
Prima (AS 6)
1 ms
1 ms
2 ms
2 ms
Multicanal (AS 1)
2 ms
75 ms
Telefónica (AS 3)
Telecom (AS 2)
Figura 4: La red de prueba para la simulación de Vivaldi
como la mitad de su RTT, aunque en la realidad el RTT no se divida a la mitad entre el sentido
upstream y el sentido downstream.
Combinamos esta red replicándola cuatro veces y conectando las instancias con otro router.
Los enlaces internos de un ISP tiene muy baja latencia en la vida real, por lo tanto estos enlaces
tienen una latencia de 1 ms. Generamos de esta manera una red de 160 nodos (figura 6).
Para terminar la red que representa a un AS, replicamos la red anterior otras cuatro veces y
las unimos con un pequeño backbone que termina en un router BGP. De esta manera, contamos
con un AS que tiene 480 nodos corriendo Vivaldi, como muestra la figura 7. Todas las latencias
en los enlaces de la figura 7 son de 1 ms, y los rectángulos verdes muestran la red de 160 nodos
replicada.
Los ASs mencionados tienen esta estructura, y de esta manera con seis de estos ASs tenemos
en total 2880 nodos.
10 nodos cablemódem
...
10 ms
10 nodos cablemódem
...
10 ms
CMTS
10 ms
10 nodos cablemódem
...
10 ms
10 nodos cablemódem
...
Figura 5: Red base para la construcción, con 40 nodos
29
Router representando un CMTS con 40 nodos cablemódem
Router interno del ISP ejecutando OSPF
1 ms
1 ms
1 ms
1 ms
Figura 6: Red de 160 nodos
CMTS con 40 nodos cablemódem
Router interno ejecutando OSPF
Router BGP
Figura 7: Red del sistema autónomo
30
8.
Resultados de la simulación de Vivaldi
La red de prueba contenı́a aproximadamente 3000 nodos distribuidos en seis ASs. En las
pruebas ejecutamos el protocolo Vivaldi durante 10 minutos de tiempo virtual. Cada nodo actualiza
su coordenada una vez por segundo, dando un total de 600 actualizaciones por nodo. Para evitar
que las coordenadas entre nodos lejanos se degraden, un 10 % de las actualizaciones son entre
nodos de distintos ASs, y las restantes entre nodos del mismo AS. La simulación no incluye tráfico
extra, pero esto puede agregarse sin modificar el código de nuestra implementación.
8.1.
Visualización de las coordenadas
Primero verificamos si las coordenadas de los nodos respetaban la topologı́a de la red subyacente. En los gráficos vamos a representar cada nodo con un punto de color y forma determinados
por el AS al que pertenece, por lo tanto dos puntos con el mismo color y forma representan nodos
del mismo AS.
En la figura 8 mostramos las coordenadas tanto en un gráfico 3D como en un gráfico 2D. Para
el primer gráfico utilizamos la componente H como si fuera la tercera componente de un espacio
euclidiano 3D normal, y para el espacio 2D excluimos la componente H del gráfico. La vista 2D es
más útil para ver las agrupaciones de nodos, pero dado que la estimación de distancia incluye la
componente H, hay que tener en cuenta que dos nodos que aparecen cerca en la vista 2D pueden
estar más lejos de lo que parece si sus componentes H son grandes. La recı́proca también puede
suceder, dos nodos que aparecen lejos en el plano pueden no estarlo tanto en comparación con
otros si sus componentes H son pequeñas. De cualquier manera, mientras que la componente H
capture mayormente la latencia generada por el link de acceso, si dos nodos están cercanos en
el plano eso sugiere que es más probable que estén en el mismo AS, por lo tanto es útil tener la
visualización 2D.
En ambos casos, igualmente, se puede observar que las coordenadas de los nodos respetan
bastante la topologı́a de la red. Se distinguen grupos claros de nodos pertenecientes al AS 0 y al
AS 1 (los ASs de nuestro ISP), si bien algunos nodos del AS 0 aparecen separados de los demás.
Los nodos pertenecientes a los ASs 2 y 3 (los ASs de los otros ISPs nacionales) se mezclan entre sı́,
pero aparecen diferenciados del resto, y lo mismo sucede con los nodos pertenecientes a los ASs 4
y 5 (los ASs en el extranjero). Dado que el enlace que separa a los ASs 4 y 5 tiene mayor latencia
(10 ms) que el enlace que separa a los ASs 2 y 3 (2 ms), los nodos de los ASs 4 y 5 se mezclan
menos que los nodos de los ASs 2 y 3.
Los ASs 4 y 5 están conectados al resto de la red por enlaces internacionales de alta latencia,
y por lo tanto era de esperar que sus nodos quedaran bien separados del resto. El enlace que une
a esos dos ASs directamente tiene mucha menos latencia que los enlaces internacionales y por lo
tanto los nodos de ambos ASs se mezclan. Los enlaces que conectan a los ASs 2 y 3 entre sı́ y
con los ASs 0 y 1 tienen una latencia baja (2 ms), menor a la latencia del enlace de banda ancha
residencial; esto hace que la agrupación no sea tan clara, pero igualmente los nodos de los ASs 2
y 3 aparecen separados de los nodos de los ASs 0 y 1. En esta situación, si bien no todos los ASs
están claramente separados, parece probable poder aprovechar la información de distancia para
que los peers realicen elecciones guiadas y aumenten el tráfico intra-ISP.
8.2.
Comportamiento de la componente H
El siguiente paso fue analizar el comportamiento del espacio vectores de altura. La idea de
la componente H de las coordenadas en el espacio de vectores de altura es que esta componente
represente la fracción de la latencia total correspondiente al link de acceso, lo que nosotros para
las redes residenciales de banda ancha llamamos Last Mile Latency o LML.
Ejecutamos la simulación descripta arriba variando la LML entre cinco valores: 5 ms, 10 ms, 20
ms, 50 ms y 100 ms. En cablemódem el RTT total entre cablemódem y CMTS es, sin congestión,
de alrededor de 10 ms. 5 ms por lo tanto corresponderı́a a un caso óptimo, ya que 5 ms de LML
corresponden a 10 ms de RTT. El valor que utilizamos para las simulaciones de Vivaldi es de 10
31
200
35
30
25
20
15
10
5
0
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
150
100
50
Y
H
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
0
-50
-150
-100 -50
X
0
50
200
150
100
50
0
Y
-50
-100
-150
100 150
-200
-100
-150
-200
-150
(a) Vista 3D
-100
-50
0
X
50
100
150
(b) Vista 2D
Figura 8: Visualización de las coordenadas de los nodos
ms de LML, o sea 20 ms de RTT. Bajo escenarios de mucha congestión el RTT puede escalar hasta
200 ms, representado por el caso de LML 100 ms. Tomamos estos valores de mediciones directas
hechas en el ISP Cablevisión, junto con información de [18].
La figura 9 muestra la relación entre la componente H y la LML. Decidimos presentar los resultados de manera relativa para que los valores de los distintos casos de LML fueran comparables.
Para cada uno de los casos graficamos el valor de la componente H de la coordenada de cada nodo
como fracción de la LML en ese caso.
Para una gran mayorı́a de los nodos, sin importar el valor de la LML, la componente H se
mantiene en valores que no superan dos veces la LML. Esperábamos encontrar los valores de la
componente H más cercanos a una vez la LML, pero hay una distribución bastante uniforme entre
valores casi nulos y valores de dos veces la LML. De cualquier manera se distingue una correlación
importante, con un coeficiente de correlación de 0,836680.
Es interesante que los valores de la componente H se mantengan dentro del mismo rango en
términos de la LML sin importar el valor absoluto de cada LML. Esto sugiere que la componente
H refleja siempre una fracción grande de la LML sin importar su valor. Dicho de otra manera, una
LML alta no degrada las coordenadas al punto que la componente H deje de capturar la LML.
Estos resultados sugieren que es útil, para mejorar la capacidad de las coordenadas de distinguir
peers del mismo ISP, calcular la distancia en el plano. La componente H captura una fracción
considerable de la LML. Dos peers del mismo ISP tienen una latencia dominada casi totalmente
por la LML, ya que la comunicación entre ellos no recorre enlaces inter-ISP. Si calculamos la
distancia entre los peers obviando la componente H, dos peers del mismo ISP aparecerán muy
cerca, ya que no estaremos teniendo en cuenta la mayor parte de la distancia que los separa. Esto
ayuda a amortiguar el impacto de una LML alta en las coordenadas.
8.3.
Distancias entre los nodos
Para que las coordenadas puedan ser aprovechables por una aplicación necesitamos que la
distancia entre dos nodos del mismo ISP sea significativamente menor que la distancia entre dos
nodos cualesquiera. El cuadro 1 presenta el promedio de la distancia, total y en el plano, entre
nodos a distintos niveles. La red de prueba está construida combinando redes pequeñas en redes
más grandes. Asimismo, la dirección NHI de cada nodo refleja esta construcción, ya que cada
inclusión de una red pequeña para construir una red más grande agrega el identificador de la red
grande a la dirección NHI del nodo. Dado que la red de prueba se realizan tres pasos de inclusión,
las direcciones NHI tienen cuatro identificadores. Todos los nodos, entonces, tendrán una dirección
NHI de la forma:
32
4
3.5
Componente H / LML
3
2.5
2
1.5
1
0.5
0
0
20
40
60
80
100
LML
Figura 9: Componente H contra LML
ID red : ID subred : ID subsubred : ID nodo
Dos nodos que comparten los tres identificadores de más a la izquierda pertenecen a la misma
subsubred, por lo tanto representan nodos que en la realidad estarı́an conectados al mismo CMTS.
Los nodos que comparten los dos identificadores de más a la izquierda pertenecen a la misma
subred, por lo tanto corresponden a nodos que en la realidad estarı́an conectados a distintos CMTS
que a su vez se conectan al mismo router. Por último, los nodos que comparten el identificador de
más a la izquierda están en el mismo AS.
En la primera columna del cuadro se promedian las distancias entre todo par de nodos que
comparten 3 identificadores, en la segunda columna se promedian las distancias entre todo par
de nodos que comparten 3 o 2 identificadores, y ası́ sucesivamente. Es de esperar que, a medida
que nos movemos para la derecha, la distancia promedio aumente, ya que estamos promediando la
distancia incluyendo pares de nodos más lejanos. En cada caso se incluye tanto el promedio entre
las distancias totales como el promedio entre las distancias en el plano.
En todos los casos pasan dos cosas claras:
La diferencia entre promediar la distancia total o la distancia en el plano es casi constante,
sin importar el conjunto de nodos que estemos tomando. Esto es esperable ya que la LML
representa la latencia del primer y último salto entre dos nodos, y estos saltos deben ser
realizados en todos los casos. Lo sorprendente es que el valor sea tan similar en cada columna.
Esto sugiere que la componente H es afectada más por la estructura de la red que por la
distancia total entre los nodos.
El valor de esta diferencia, además, se acerca al doble de la LML. Esto también es esperable,
ya que para cualquier comunicación entre nodos la LML se debe recorrer dos veces. Esto es
más evidencia de que la componente H captura buena parte de la LML, y por lo tanto es
33
Misma
subsubred
Misma
subred
Mismo
AS
2D+H
2D
Diferencia
11.68
20.67
8.98
15.27
24.26 24.36
8.98
15.38
148.24
8.98
139.26
10
10
10
2D+H
2D
Diferencia
20.31
38.23
17.93
22.05
39.98
17.93
22.09
40.01
17.93
149.28
167.21
17.93
20
20
20
2D+H
2D
Diferencia
35.40
72.64
37.24
40.17
77.41
37.24
39.58
76.82
37.24
165.99
203.23
37.24
50
50
50
2D+H
2D
Diferencia
80.66
177.95
97.29
83.82
181.11
97.29
83.36
180.65
97.29
217.76
315.05
97.29
100
100
100
2D+H
2D
Diferencia
161.10
357.50
196.39
180.13
376.53
196.39
182.02
378.41
196.39
295.91
492.30
196.39
LML (ms)
Caso
5
5
5
Global
8.98
Cuadro 1: Distancias promedio en Vivaldi variando la LML
buena idea calcular la distancia en el plano para intentar obtener pares de peers en el mismo
ISP.
Creemos que estos resultados muestran el buen comportamiento de las coordenadas de Vivaldi
en esta red de prueba.
8.4.
Distancia como indicador de proximidad
Para seguir, quisimos ver si nodos cercanos en distancia tienen mayor probabilidad de estar
en el mismo ISP. El comportamiento de las coordenadas en la red de prueba sugerı́a que esto
debı́a ser ası́. En el cuadro 1 se puede ver que el promedio de las distancias entre nodos de un
mismo AS es bastante menor que el promedio de las distancias entre todos los nodos. Para el caso
LML 10 ms (que es el que usamos para las simulaciones de BitTorrent), la distancia promedio
entre nodos del mismo AS, como porcentaje de la distancia promedio entre todos los nodos,
es (40,01/167,21) × 100 = 23,93 %. Para el caso LML 100 ms (el peor caso) el porcentaje es
(378,41/492,30) × 100 = 76,87 %.
La distancia promedio entre los nodos de un mismo AS es un 24 % de la distancia promedio
entre todos los nodos. Esto sugiere que en promedio los nodos de un mismo AS están mucho más
cerca que un par de nodos cualesquiera, y por lo tanto podemos esperar que la distancia sea una
buena manera de elegir un nodo del mismo ISP.
Se puede observar también como se degradan las coordenadas a medida que aumenta la LML.
En el caso 100 ms la distancia promedio entre nodos de un mismo AS es más de un 75 % de la
distancia promedio entre dos nodos cualesquiera, lo cual hace mucho menos probable que elegir
un nodo cercano implique elegir un nodo en el mismo ISP.
Calculando la distancia en el plano, con LML de 10 ms, la distancia promedio intra-AS
como porcentaje de la distancia promedio global es (22,09/149,28) ∗ 100 = 14,80 %, mientras
que al calcular la distancia total el porcentaje era 24 %. Con LML 100 ms, el porcentaje es
(182,02/295,91) ∗ 100 = 61,51 %, y calculando la distancia total el porcentaje era 77 %. Sin embargo, 62 % sigue siendo varias veces superior al porcentaje del caso 10 ms (15 %), por lo tanto
parece cierto que el aumento de la LML degrada las coordenadas, si bien excluir la componente H
34
LML (ms)
10
100
Distancia total ( %)
Distancia en el plano ( %)
6.61
23.00
6.26
20.67
Cuadro 2: Porcentajes de falsos positivos
nos permite mitigar un poco esa degradación, y por sobre todo mejorar significativamente el caso
de LML 10 ms.
No obstante la diferencia entre las distancias promedio, también es importante que no haya
muchos falsos positivos. Llamamos falso positivo a un par nodos de distintos ASs que calculan
una distancia entre ellos menor que el promedio de distancias entre nodos del mismo AS (intraAS). Esto puede suceder si la distribución de distancias entre nodos de distintos ASs (inter-AS)
está muy alejada de la media: hay muchos pares de nodos inter-AS que calculan una distancia baja,
pero muchos más que calculan una distancia muy alta. Si muchos pares de nodos inter-AS son
falsos positivos, entonces sucederá que el algoritmo upload appeal eligirá incorrectamente nodos
cercanos que no están en el mismo AS.
Es necesario entonces conocer la distribución de las distancias, y no solamente su promedio. En
la figuras 10 y 11 mostramos los histogramas de distancias, para el caso 10 y 100 ms, calculando
tanto la distancia total como la distancia en el plano. Además, marcamos en todos los gráficos el
promedio de distancias intra-AS. Por otro lado, en el cuadro 2 mostramos el porcentaje de falsos
positivos en ambos casos, y para ambos cálculos de distancia.
En el caso 10 ms, calculando la distancia total, la distribución de las distancias intra-AS es
marcadamente asimétrica, con un pico aproximadamente en el valor 40. Al contrario, la distribución
de distancias inter-AS es más simétrica, con varios picos, el más grande después del valor 200.
Podemos ver que las distancias intra-AS son marcadamente menores que las distancias inter-AS.
Solamente un pequeño porcentaje de estas últimas queda por debajo del promedio de distancias
intra-AS, causando un 6.61 % de falsos positivos.
Calculando la distancia en el plano la situación se mantiene, pero los histogramas se desplazan
a la izquierda. Esto es esperable, ya que al calcular la distancia en el plano todas las distancias son
menores. Sigue habiendo solamente un pequeño porcentaje de distancias entre nodos de distintos
ASs que quedan por debajo del promedio de distancias entre nodos del mismo AS. El porcentaje
de falsos positivos se reduce ligeramente, a 6.26 %.
Pasando al caso 100 ms, calculando la distancia total, notamos como el valor alto de LML
afecta notablemente la distribución de las distancias. El histograma de distancias intra-AS es más
ancho, y esperablemente está corrido hacia la derecha, hacia valores mayores de distancia. El
histograma de distancias inter-AS es todavı́a más ancho, alcanzando valores de distancia mucho
mayores. Como era de esperar, en este caso la superposición es mucho mayor, y el porcentaje de
falsos positivos aumenta a 23 %. Sin embargo, teniendo en cuenta que 100 ms de LML es un caso
de congestión extrema, un 23 % de falsos positivos no es un resultado malo.
Calculando la distancia en el plano, para el caso 100 ms, la situación mejora ligeramente.
Ambos histogramas se mueven notoriamente hacia la izquierda, pues estamos restando 200 ms de
latencia. Sin embargo, la superposición se mantiene similar, y consecuentemente el porcentaje de
falsos positivos sólo disminuye ligeramente, a 20 %.
En los casos de LML razonable (10 ms) las distancias se comportan como esperábamos, diferenciando claramente nodos en el mismo AS, con pocos falsos positivos. Esto sugiere que el algoritmo
upload appeal podrá utilizar la estimación de latencia para elegir peers en el mismo ISP. Con una
LML mayor el porcentaje de falsos positivos aumenta, pero es sorprendente que no sea un número
mucho mayor teniendo en cuenta que la LML es mayor que cualquier enlace inter-ISP.
35
0.35
0.35
Mismo AS
Distinto AS
Promedio mismo AS
0.3
0.25
Frecuencia relativa
0.25
Frecuencia relativa
Mismo AS
Distinto AS
Promedio mismo AS
0.3
0.2
0.15
0.2
0.15
0.1
0.1
0.05
0.05
0
0
0
50
100
150
200
250
Distancia
300
350
400
450
0
(a) Distancia total
50
100
150
200
250
Distancia
300
350
400
450
(b) Distancia en el plano
Figura 10: Histogramas de distancias, caso 10 ms
0.05
0.05
Mismo AS
Distinto AS
Promedio mismo AS
Mismo AS
Distinto AS
Promedio mismo AS
0.04
Frecuencia relativa
Frecuencia relativa
0.04
0.03
0.02
0.01
0.03
0.02
0.01
0
0
0
200
400
600
Distancia
800
1000
1200
0
(a) Distancia total
200
400
600
Distancia
800
(b) Distancia en el plano
Figura 11: Histogramas de distancias, caso 100 ms
36
1000
1200
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
100
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
25
0
20
H
Y
15
10
5
-100
0
100
0
-100
Y
-100
0
X
100
-200
-200
200
-100
0
100
200
X
(a) 3D
(b) 2D
Figura 12: Visualización de las coordenadas de los nodos, LML 5 ms
200
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
45
40
35
30
25
20
15
10
5
0
100
0
Y
H
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
-100
200
100
0
-200
-100
X
-100
0
Y
-200
-200
100
-200
-100
0
100
X
(a) 3D
(b) 2D
Figura 13: Visualización de las coordenadas de los nodos, LML 10 ms
8.5.
Comportamiento de las coordenadas frente a variaciones de la LML
Presentamos, para terminar, los gráficos de las coordenadas de los nodos a medida que aumenta
la LML. Las figuras 12 a 16 muestran las coordenadas de los nodos en casos de LML 5, 10, 20, 50
y 100 ms. Se puede observar como los grupos de nodos correspondientes a los ASs van perdiendo
forma a medida que la LML aumenta. Los casos de 5 y 10 ms tienen grupos diferenciados para los
ASs 0 y 1, un grupo para los ASs 2 y 3, y otro grupo para los ASs 4 y 5. Los casos de 20 y 50 ms
mantienen estos grupos, pero la distancia entre los grupos se reduce, mostrando como el aumento
en la LML empieza a dominar por sobre los enlaces inter-ISP. Finalmente, en el caso 100 ms ya
no se distinguen grupos, pues en este caso la LML es mayor que cualquier enlace inter-ISP.
Estos resultados son consistentes con la situación de aumento de la distancia promedio intraAS contra la distancia promedio total. A medida que aumenta la LML la distancia contra un nodo
del mismo ISP no es mucho menor que la distancia promedio contra un nodo cualquiera, y de la
misma manera no se distinguen agrupamientos en los gráficos.
8.6.
Análisis
Podemos ver entonces que, en los experimentos realizados:
Con LML bajas y medias Vivaldi embebe los nodos respetando la topologı́a de la red. Se distinguen en la visualización de las coordenadas los distintos grupos de nodos correspondientes
37
0
Y
H
60
50
40
30
20
10
0
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
100
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
-100
100
0
-200
-100
Y
-100
0
100
X
200
-200
-100
(a) 3D
0
X
100
200
(b) 2D
Figura 14: Visualización de las coordenadas de los nodos, LML 20 ms
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
200
160
140
120
100
80
60
40
20
0
100
0
Y
H
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
-100
200
100
0
-300 -200
-100
0
X
-100
100
200 300
-200
Y
-200
400
-300
-200
-100
0
100
200
300
400
X
(a) 3D
(b) 2D
Figura 15: Visualización de las coordenadas de los nodos, LML 50 ms
400
350
300
250
200
150
100
50
0
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
300
200
100
Y
H
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
0
-100
-500-400
-300-200
-100 0
100 200
300 400
X
500
400
300
200
100
0
Y
-100
-200
-300
-200
-300
-500
(a) 3D
-400
-300
-200
-100
0
X
100
200
(b) 2D
Figura 16: Visualización de las coordenadas de los nodos, LML 100 ms
38
300
400
500
a cada AS.
La correlación entre LML y coordenada H es alta. Esto permite calcular la distancia entre
nodos obviando la componente H y de esta manera obviar la LML en la estimación de
latencia, sin necesitar medirla directamente.
En el caso de LML 10 ms, la distancia promedio contra otro nodo del mismo AS es solamente
un 24 % de la distancia promedio global. Calculando la distancia en el plano este porcentaje
se reduce a un 15 %, confirmando el buen comportamiento del espacio de vectores de altura
en la red de prueba. Por otro lado, el porcentaje de falsos positivos es bajo, no superando el
7 %. Esto sugiere que elegir un nodo que esté cerca es una buena manera de elegir un nodo
dentro del mismo ISP.
A medida que la LML aumenta, las coordenadas se degradan. Sin embargo, es necesario un
incremento enorme en la LML para que las coordenadas se vuelvan inútiles. El único caso
que no muestra realmente ninguna agrupación es el caso de LML 100 ms, que es un caso
muy malo de RTT cablemódem-CMTS, causado por una situación de enorme congestión.
No obstante, incluso en este caso el porcentaje de falsos positivos no supera el 24 %.
Un detalle importante a mencionar es que nuestra red de prueba incluye enlaces inter-ISP
de alta latencia, ya que estamos simulando enlaces entre ISPs de Argentina y sus proveedores de
tráfico en EEUU. Posiblemente las coordenadas se degraden más rápidamente en un ISP en EEUU
si todos los peers están en EEUU, ya que las latencias entre ISPs allı́ son menores, y entonces un
aumento de la LML repercute más. Por otro lado, para un swarm global, es claro que la situación
es más similar a la de nuestra red, lo cual haria válidos a nuestros escenarios.
39
9.
Implementación de BitTorrent en SSFNet
Nuestro objetivo principal es aumentar el tráfico intra-ISP de un swarm BitTorrent utilizando
información de coordenadas. Es necesario decidir la manera de utilizar esta información en BitTorrent. En [8] no se especifica ninguna manera de separación de peers en ISPs. Ese trabajo se
enfoca en decidir si, teniendo esa información disponible de algún oráculo, ésta se puede utilizar
para aumentar el tráfico intra-ISP. El problema es que dado que se supone un oráculo, se puede
disponer de información perfecta acerca de la agrupación de peers en ISPs. Por lo tanto, los algoritmos presentados en el trabajo consisten básicamente en hacer que el total de conexiones de
cada nodo incluya una fracción fija de conexiones contra peers del mismo ISP. Esto es posible de
hacer ya que se dispone de toda la información necesaria.
En ese trabajo analizan distintas maneras de garantizar que esta elección guiada no repercuta
en las buenas propiedades estructurales de los grafos aleatorios generados por la elección de peers
hecha por el tracker [6], ası́ como también maneras de garantizar que no disminuya la tasa de
transferencia total mientras se aumenta el tráfico intra-ISP. Nuestra solución se diferencia de [8]
en que mantenemos la elección aleatoria de peers del tracker pero modificamos el algoritmo de
choking para guiar la transferencia entre peers. La información provista por las coordenadas no es
perfecta como en ese caso, y por lo tanto optamos por un enfoque distinto.
9.1.
BitTorrent y la estimación de latencia
El protocolo BitTorrent requiere actualizar periódicamente los peers en estado no choking. Esta
elección se realiza teniendo en cuenta los peers remotos que tienen la mejor tasa de transferencia
hacia el peer local. Si esta elección tuviera en cuenta la proximidad de los peers podrı́amos limitar
el tráfico inter-ISP. Sin embargo, una elección guiada únicamente por la cercanı́a de los peers
afectarı́a la velocidad de bajada, ya que no necesariamente los peers cercanos son los que suben
más al peer local.
Con este objetivo reemplazamos la tasa de subida del peer remoto por otro número que balancea
la tasa de subida con la proximidad del peer remoto. Queremos que el algoritmo de choking
preferiera peers que están cerca por sobre los que están más lejos mientras sus tasas de subida
sean similares. De esta manera esperamos no perder velocidad final de bajada.
Implementar esta polı́tica directamente es complicado. ¿Cuándo son suficientemente similares
las tasas de subida como para desempatar con la cercanı́a? Una implementación directa implicarı́a
también más procesamiento que simplemente elegir los cuatro peers remotos con mejor tasa de
subida hacia el peer local. Por lo tanto, lo que hicimos fue actualizar, junto con la tasa de subida
del peer remoto, otro valor que llamamos el interés de subida o upload appeal (a):
u2
d
Donde u es la tasa de subida del peer remoto y d es la distancia. Este número representa
cuánto le interesa al peer local subirle a ese peer remoto, y por lo tanto es creciente en la tasa de
subida del peer remoto pero decreciente en la distancia contra el peer remoto. La idea detrás de
este valor es que la tasa de subida sea un orden de magnitud más importante que la distancia, y
por esta razón la distancia termine importando solamente en caso de que los valores de tasa de
subida sean similares. Por ejemplo, si un peer remoto está subiendo al peer local con una tasa que
es el doble de la de otro peer remoto, este último tendrá que estar cuatro veces más cerca para
lograr ser preferido por sobre el primero.
a=
9.2.
BitTorrent en SSFNet
La comunicación en BitTorrent se realiza sobre protocolo TCP. En SSFNet tenemos disponibles
las primitivas clásicas para leer y escribir en un socket TCP (read() y write()), y estas trabajan
de una manera cómoda: podemos simplemente enviar y recibir objetos de Java, pero simular la
transmisión de una cantidad arbitraria de bytes.
40
Algoritmo 5 Algoritmo de choking modificado
for all peer p do
if p es uno de los cuatro peers con mejor interés de subida ∧ p está choking then
mandar unchoke a p
else if p no es uno de los cuatro peers con mejor interés de subida ∧ p no está choking
then
mandar choke a p
end if
end for
mandar unchoke a q peer al azar en estado choking
Tenemos una clase que hereda de ProtocolSession representando el cliente BitTorrent que
corre en un nodo. Está será la única clase que herede de ProtocolSession, ya que la simulación
está planteada de manera de que no sea necesario tener un tracker. El propósito del tracker es
proveer al cliente BitTorrent de una lista de peers con la cual conectarse. En el contexto de la
simulación conocemos los peers que existen en ella, ya que conocemos la estructura de la red y
podemos identificar a los peers con direcciones NHI. Simularemos entonces la elección aleatoria
del tracker eligiendo de manera aleatoria las direcciones NHI con las que el peer se conectará. La
simulación se enfoca en recrear los patrones de tráfico encontrados en BitTorrent, y la ausencia de
un tracker autónomo no afecta las caracterı́sticas del tráfico.
Las primitivas de los sockets TCP son bloqueantes, y por lo tanto requieren continuaciones.
El mayor problema que generó la ausencia de primitivas no bloqueantes fue que tuvimos que
armar una estructura de entrada/salida asincrónica por sobre las continuaciones. Dado que un
peer en todo momento está conectado con varios otros peers, es necesario poder enviar y recibir
información en varios sockets al mismo tiempo, y si una lectura en un socket se bloquea, esto
será imposible.
Cada conexión es bastante independiente de las demás. La única sincronización necesaria es no
pedir el mismo bloque en más de una conexión, y esto solamente por una cuestión de eficiencia. Por
esta razón creamos una clase que representa una conexión particular entre dos peers, y entonces
cada objeto BitTorrent mantiene una colección de objetos de esta clase. Estos objetos manejan
los detalles de bajo nivel de la comunicación (escribir un mensaje en el socket), mientras que el
objeto BitTorrent se ocupa de la parte de alto nivel (pedido de bloques y mecanismo de choking).
Otro de los factores a tener en cuenta en el diseño fue que, teniendo objetos distintos para cada
comunicación con un peer, se vuelve necesario desacoplar el envı́o de un mensaje de la intención de
enviarlo. Dicho de otra manera, puede suceder que el objeto BitTorrent tenga que enviar por varias
conexiones un mensaje que indique que se acaba de completar una pieza (un mensaje have). Cada
conexión tiene que tener la posibilidad de “encolar” este mensaje para mandarlo luego, aunque
en ese momento esté haciendo otra cosa. Para resolver esto los objetos que representan a una
conexión poseen una cola de mensajes. Uno a uno, estos objetos enviarán los mensajes que hayan
sido encolados; si no hay mensajes a enviar se detendrán un tiempo configurable, utilizando timers.
Dado que el estado interesado y choking se mantiene por conexión, estos objetos guardarán también
esa información. Por último, estos objetos también mantienen el estado de las piezas que el peer
del otro lado de la conexión tiene.
Una vez que es configurado e inicializado, cada nodo posee la siguiente información:
Cantidad de piezas en el archivo a bajar
Tamaño de la pieza
Tamaño del bloque
Posibles nuevos peers
En caso de ser un seed, el nodo comenzará a escuchar por conexiones entrantes, pero no
comenzará a bajar el archivo. El porcentaje de seeds en un swarm real varı́a mucho, dependiendo
41
del tipo y tamaño del archivo a compartir, la popularidad del torrent y el tiempo transcurrido desde
su creación. Es normal que muchos torrents tengan pocos seeds, pero torrents populares pueden
tener incluso más seeds que peers con el archivo incompleto. En la simulación el porcentaje de
seeds es por defecto un 10 % del total de peers en el swarm.
En caso de no ser un seed, el nodo comenzará a escuchar conexiones entrantes y además
comenzará a iniciar conexiones. Las conexiones en BitTorrent son simétricas, por lo tanto una
vez que la conexión está creada, no interesa quién la creo, y por lo tanto todas las conexiones
se mantienen en una misma estructura de datos y son equivalentes para el objeto BitTorrent:
intentará bajar piezas en todas ellas, y podrá pasarlas a estado no choking a todas.
Si esto no fuera manejado correctamente, el cliente podrı́a estar pasando un seed a estado no
choking; algo inútil, pues los seeds no están bajando el archivo, y por lo tanto no pedirán piezas. Decidimos que en nuestra implementación los peers mantengan siempre su estado interesado
actualizado. De esta manera, el peer local pasa a estado no choking los cuatro peers remotos interesados que tengan mejor tasa de subida o interés de subida. Un seed, que nunca está interesado,
no será pasado a estado no choking mientras haya peers interesados.
La espera de conexiones nuevas está resuelta con continuaciones, ya que listen() es una
primitiva bloqueante. Cada vez que se completa un listen() se llama a un método auxiliar que
maneja la creación de la conexión, y luego se vuelve a bloquear esperando un nuevo listen().
El inicio de conexiones nuevas debe ser resuelto de la misma manera ya que connect() es
también una primitiva bloqueante. La posibilidad de iniciar una conexión nueva está determinada
por la cantidad de conexiones existentes: los nodos poseen un número máximo de conexiones que
pueden tener abiertas, y por lo tanto abren conexiones nuevas mientras no hayan llegado a este
número. Esto es un comportamiento normal en los clientes de BitTorrent reales.
Para simular más fielmente la realidad, los peers que no son seeds inician la bajada en distintos
momentos. Cada uno empieza a bajar el archivo después de esperar un tiempo aleatorio siguiendo
una distribución ley de potencia23 . Esto hace que la mayorı́a de los peers esperen poco tiempo,
pero que también haya algunos peers que esperen más. Al pasar este tiempo el cliente empieza
a conectarse con peers y a encolar pedidos de bloques. Aquı́ se sigue el mecanismo de elegir la
primera pieza al azar y luego elegir utilizando rarest first, siempre intentando completar primero
una pieza antes de comenzar una nueva. Para poder resolver el rarest first, toda la información
contenida en los mensajes bitfield y have recibidos es compilada en un arreglo que contiene la
cuenta global de repeticiones de cada pieza. Sin embargo, dado que no todos los peers tienen todas
las piezas, la elección en cada conexión es la pieza menos replicada entre las que el peer remoto
tiene en el momento.
Una vez pedido un bloque en cada conexión no choking se procede a configurar un timer que
reinicie este proceso después de un cierto delay configurable. Esta es la manera de resolver lo que
en una aplicación normal serı́a un sleep() o un bloqueo (en select()) hasta tener alguna entrada
en algún socket.
Cada vez que se recibe un bloque en respuesta de algún pedido se actualiza la información de
bloques y piezas. Cada vez que se completa una pieza, el objeto BitTorrent encola un mensaje
have en todas las conexiones. Para evitar mandar mensajes have superfluos, no se avisa de piezas
completas a nodos que ya las tienen, pues no le servirı́a de ninguna manera saberlo, ya que no van
a intentar bajarla.
La información de bloques y piezas es utilizada por la rutina que decide qué bloque encolar
en cada conexión. Eventualmente el nodo terminará de bajar el archivo y, por lo tanto, dejará de
conectarse con nuevos peers y pasará a modo seed. La única diferencia, recordemos, es que los
seeds eligen a los cuatro peers que más están bajando de ellos para pasar a modo no choking.
Nuevamente, para respetar mejor el comportamiento real de los peers, una vez que un peer se convierte en seed configura un timer para después de que el timer expire cerrar todas sus conexiones.
Este tiempo también sigue una distribución ley de potencia.
Este comportamiento de retrasar el inicio de la bajada y no cerrar las conexiones apenas
23 En una distribución ley de potencia la densidad de probabilidad se concentra en los valores cercanos al cero,
dando un gráfico asimétrico con cola a la derecha.
42
terminada la bajada contribuye a que el comportamiento de los peers se asemeje más a la realidad,
en la cual al publicarse un archivo .torrent inicialmente se agregan muchos peers al swarm, y
luego cada vez se van agregando menos [6]. Luego de un tiempo, los peers comienzan a terminar
el archivo, y la mayorı́a de ellos es seed por un tiempo bastante corto, pero algunos siguen siendo
seeds más tiempo [6].
9.3.
Implementación de Vivaldi a cuestas de BitTorrent
Usamos la información de distancia para modificar el algoritmo de choking y, siempre que dos
peers remotos estén subiendo al peer local con una tasa de subida similar, desempatamos con el
peer que estimemos más cercano (ver sección 9.1). Falta, entonces, explicar cómo sobrecargamos
la información de coordenadas en los mensajes de BitTorrent.
Nuestra implementación original agregaba la coordenada y el error actual en todos los mensajes intercambiados entre los nodos. Esto incluı́a los mensajes request y piece. Estos mensajes
comprenden una enorme mayorı́a de los mensajes totales intercambiados. En las pruebas preliminares, sin embargo, notamos que las coordenadas se degeneraban mucho, ya que los nodos debı́an
actualizar su coordenada contra el mismo nodo remoto muchas veces por minuto. Por lo tanto,
decidimos agregar la coordenada y el error actual de cada nodo en cada mensaje de BitTorrent
intercambiado excepto en los mensajes request y piece.
La idea detrás de esto es intercambiar mensajes de una manera más independiente que con los
cinco peers que están en estado no choking. El resto de los mensajes, choke, unchoke, interested,
not interested, have y bitfield se intercambian a un ritmo más o menos similar entre todos
los nodos, y por lo tanto proveen una base más estable para la información de coordenadas. De
esta manera, cada vez que una conexión de un nodo recibe alguno de estos mensajes, provee esta
información al nodo para que actualice la coordenada local.
9.4.
Implementación de las modificaciones a Vivaldi
Uno de los objetivos de este trabajo es analizar modificaciones al protocolo Vivaldi que tienen
como propósito mejorar su comportamiento en el caso de su utilización a cuestas de BitTorrent.
Incluimos una modificación propuesta por nosotros, el cálculo de la distancia en el plano, y tres
modificaciones propuestas en [11], el filtro de latencia, las coordenadas de cinco dimensiones, y la
ampliación del conjunto de vecinos.
Las tres primeras modificaciones se pueden realizar de manera muy simple. La operatoria
provista por nuestra implementación de coordenadas en el espacio de vectores de altura incluye
funcionalidad tanto para calcular la distancia en el plano como para utilizar coordenadas de cinco
dimensiones. Por otro lado, la propuesta en [11] para el filtro de mediana consiste en recordar una
cantidad fija de las últimas mediciones, por lo tanto una lista de mediciones de latencia basta para
poder utilizar esta mejora en la experimentación.
La ampliación del conjunto de vecinos requiere una implementación más intrusiva. Para empezar, es necesario recordar este conjunto. Al recibir una nueva medición de latencia se la debe
agregar al conjunto de vecinos, reemplazando eventualmente una medición más vieja contra el mismo vecino. Se debe actualizar la edad de las mediciones, eliminando las que sean demasiado viejas,
y recalcular la fuerza total realizando nuevamente el escalamiento del desplazamiento generado
por cada vecino.
9.5.
La red de prueba para SSFNet
La red de prueba utilizada en la simulación de BitTorrent es similar a la utilizada para las
pruebas de Vivaldi. Sin embargo, dado que el procesamiento requerido para BitTorrent es mayor,
la cantidad de nodos se redujo a 20 por AS para un total de 120 nodos.
La estructura de la red es similar, pero redujimos la cantidad de nodos por CMTS de 40 a
5. Si bien puede parecer un número bajo, la mayorı́a de los torrents que uno puede encontrar
normalmente en Internet no pasan esa cantidad de peers en un momento dado. Como nuestro
43
Router BGP representando a un AS sin nodos
Router BGP representando a un AS con 20 nodos cablemódem
10 ms
USA2 (AS 5)
USA1 (AS 4)
75 ms
75 ms
75 ms
1 ms
Cablevisión (AS 0)
Prima (AS 6)
1 ms
1 ms
2 ms
2 ms
Multicanal (AS 1)
2 ms
75 ms
Telecom (AS 2)
Telefónica (AS 3)
Figura 17: La red de prueba para la simulación de BitTorrent
interés es simular tráfico de BitTorrent por un perı́odo acotado de tiempo, 120 peers totales
parece una cantidad suficiente.
Al haber reducido la cantidad de nodos por CMTS tampoco necesitábamos anidar redes en
tantos niveles, y por lo tanto en la simulación de BitTorrent los nodos poseen una dirección NHI
con dos identificadores, el identificador de la izquierda es del AS y el de la derecha es del nodo
dentro del AS.
El único inconveniente que presentó el simulador en este caso fue que el bitrate de las conexiones
entre CM y CMTS debe ser especificado de manera simétrica, al igual que la latencia. Si bien en
el caso de la latencia esto no es un problema, ya que un paquete siempre recorre ambos sentidos
de la conexión, la asimetrı́a en el ancho de banda de las conexiones residenciales sı́ afecta el
funcionamiento de BitTorrent: una conexión residencial contribuye poco ancho de banda de subida
comparado con el que serı́a capaz de absorber para bajar. Normalmente, los algoritmos de choking
tienen como consecuencia que un usuario residencial tiene tasas de bajada no mucho mayores a su
tasa de subida. Sin embargo, en un torrent con muchos seeds o muchos usuarios con conexiones
simétricas, la tasa de bajada puede ser mucho mayor a la tasa de subida.
Nuestra solución a este problema, con el objetivo de mantener la representatividad de los
resultados, fue que el bitrate de los enlaces fuera suficientemente bajo como para que la mitad de
esa tasa fuera similar a la tasa de subida de una conexión de banda ancha residencial.
44
100
90
80
70
60
50
40
30
20
10
0
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
200
Y
H
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
100
200
100
200
X
100
Y
300
400
100
200
300
400
X
(a) 3D
(b) 2D
Figura 18: Visualización de las coordenadas calculadas por Vivaldi a cuestas de BitTorrent, caso
normal
10.
Resultados de la simulación de BitTorrent
La experimentación realizada consistió en simular un swarm de BitTorrent de 120 peers bajando
un archivo de 64 MB durante una hora. 64 MB es un tamaño razonable para obtener patrones
de tráfico caracterı́sticos de BitTorrent. Archivos más grandes solamente alargan la simulación sin
cambiar el comportamiento del tráfico [8]. El swarm tiene, al inicio, 12 seeds. Los peers comienzan
a bajar el archivo en algún momento al azar durante los primeros 10 minutos de la simulación,
siguiendo una distribución ley de potencia. Cuando un peer termina de bajar el archivo se convierte
en seed y comparte el archivo durante un tiempo al azar que sigue nuevamente una distribución
ley de potencia, con un máximo de una hora. Los seeds originales comparten el archivo durante
toda la simulación.
En el caso normal la elección de peers a pasar a estado no choking se basa únicamente en la tasa
de subida que el peer remoto mantiene con el peer normal. En el caso interés de subida, utilizamos
justamente el algoritmo interés de subida, en el cual el peer local elige a los peers remotos que
le están subiendo más, pero desempata eligiendo los que están más cerca. Incluimos también una
ejecución del protocolo Vivaldi de manera autónoma (sin correr a cuestas de BitTorrent) en la
misma red para poder comparar las coordenadas obtenidas con Vivaldi a cuestas de BitTorrent.
Como primer paso querı́amos ver las caracterı́sticas de las coordenadas calculadas por Vivaldi
cuando la información de coordenadas y error se intercambia a cuestas de los mensajes normales
de BitTorrent. En las figuras 18, 19 y 20 mostramos las coordenadas de los tres casos. Podemos
ver que no hay una diferencia marcada entre los dos casos en los que Vivaldi se implementa a
cuestas de BitTorrent. Esto es esperable ya que como no incluimos información de coordenadas
en los mensajes BitTorrent request y piece, la calidad de las coordenadas está determinada por
el conjunto de peers remotos con los que cada peer local está conectado. Este conjunto no varı́a
al utilizar el algoritmo interés de subida. En comparación, las coordenadas calculadas cuando
Vivaldi se ejecuta de manera autónoma resultan mejores, agrupando mucho mejor a los peers en
ASs. Solamente en este último caso se distinguen claramente los distintos ASs de la red de prueba.
Sospechamos que estos resultados se deben a que en el caso autónomo no hay restricciones
para la comunicación entre los nodos, mientras que al funcionar a cuestas de BitTorrent los nodos
intercambian coordenadas solamente si están conectados entre sı́. Esto lleva a que las coordenadas
tengan poco error entre los nodos que están conectados entre sı́, pero más error a nivel global.
Como hicimos para Vivaldi en la implementación autónoma, analizamos también en este caso
las distancias promedio entre pares de nodos. En la red de prueba para BitTorrent la dirección
NHI de los nodos tiene dos componentes, y por lo tanto comparamos directamente el promedio de
las distancias entre pares de nodos del mismo AS contra el promedio de las distancias entre todos
45
100
90
80
70
60
50
40
30
20
10
0
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
0
Y
H
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
0
-100
Y
0
100
X
200
-100
-100
-100
0
100
200
X
(a) 3D
(b) 2D
Figura 19: Visualización de las coordenadas calculadas por Vivaldi a cuestas de BitTorrent, caso
interés de subida
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
AS 0
AS 1
AS 2
AS 3
AS 4
AS 5
25
0
20
15
Y
H
10
5
0
0
-300
Y
-200
-100
X
0
100
-300
(a) 3D
-200
-100
X
0
(b) 2D
Figura 20: Visualización de las coordenadas calculadas por Vivaldi autónomo
46
100
Caso
Mismo AS
Global
Porcentaje
BitTorrent, normal, distancia en el plano
BitTorrent, normal
64.16
106.47
65.26
107.57
98.31 %
98.98 %
BitTorrent, interés de subida, distancia en el plano
BitTorrent, interés de subida
62.22
103.59
64.72
106.09
96.14 %
97.65 %
Vivaldi autónomo, distancia en el plano
Vivaldi autónomo
10.15
40.10
127.99
157.95
7.93 %
25.39 %
Cuadro 3: Distancias promedio en BitTorrent.
los pares de nodos.
Presentamos estos resultados en el cuadro 3. Comprobamos, de manera numérica, la diferencia
entre las coordenadas calculadas de manera autónoma y las coordenadas calculadas a cuestas de
los mensajes de BitTorrent. La poca agrupación que se ve en los gráficos de las figuras 18 y 19
se corresponde con porcentajes altos de distancia promedio intra-AS contra distancia promedio
total. En este caso dos peers del mismo AS están en promedio a una distancia que es un 98 % de la
distancia promedio entre todos los peers, lo cual hace más difı́cil distinguir nodos en los distintos
ASs, como se comprueba en los gráficos.
Como contraparte, la enorme agrupación que podemos ver en la figura 20 se corresponde con un
porcentaje bajo para el promedio de distancias intra-ISP frente al promedio de distancias global.
El promedio de las distancias entre peers del mismo AS es solamente un 25 % del promedio de las
distancias entre cualquier par de nodos.
Nuevamente, sospechamos que lo que sucede es que al utilizar Vivaldi a cuestas de BitTorrent
las coordenadas logran poco error solamente para los nodos que intercambian activamente información. Al calcular el promedio entre todos los pares de nodos, tanto dentro del mismo AS o a
nivel global, incluimos estimaciones entre pares de nodos que no se han comunicado.
Nuestro principal objetivo, de cualquier manera, fue analizar las caracterı́sticas del tráfico al
usar nuestro algoritmo de interés de subida para verificar si se obtiene un aumento en el tráfico
intra-ISP sin empeorar las velocidades de bajada de los nodos. La simulación nos permite contar la
cantidad de piezas que se intercambian dentro del swarm, y cuántas de ellas no salen de un mismo
AS o ISP. De esta manera, en el cuadro 4 presentamos tanto los porcentajes de piezas totales que
se intercambian entre nodos del mismo AS ası́ como entre nodos del mismo ISP. Recordemos que
uno de los ISPs que modelamos está constituido por dos ASs y por lo tanto necesitamos hacer la
distinción entre AS e ISP. Mostramos además cuanto mejoramos en cada caso:
Diferencia = Interés de subida − Normal
Podemos ver en el cuadro que utilizando el algoritmo de interés de subida ganamos casi cinco
puntos porcentuales de piezas que dejan de salir del ISP. Para comprobar que no estemos perdiendo
velocidad de bajada, en el cuadro 5 comparamos la cantidad total de piezas que se intercambian
en ambos casos, y podemos ver que no hay diferencia significativa. El swarm intercambia en total
aproximadamente 230000 piezas de 32 KB. Ese 5 % de piezas que dejan de salir del ISP con el uso
de interés de subida representan:
229619 ∗ 4,86 % ∗ 32 KB ≈ 348 MB
Aproximadamente 348 MB que dejan de salir del ISP, para un solo swarm de un solo
torrent de 64 MB durante una hora. Esto equivale que cinco copias y media más del
archivo se intercambien sin que el tráfico salga de los ISPs.
47
Caso
Normal ( %)
Interés de subida ( %)
Diferencia ( %)
18.50
25.36
23.06
30.22
4.55
4.86
Dentro del mismo AS
Dentro del mismo ISP
Cuadro 4: Porcentaje de piezas intercambiadas dentro del mismo AS e ISP
Caso
Piezas totales intercambiadas por el swarm
Normal
Interés de subida
229311
229619
Cuadro 5: Cantidad total de piezas intercambiadas
10.1.
Experimentación con las modificaciones a Vivaldi
La experimentación con las modificaciones es similar a la anterior. En cada caso tenemos
un swarm de 120 peers totales, con 12 seeds, ejecutando el protocolo BitTorrent durante una
hora. Medimos la cantidad de piezas totales que se intercambian, y el porcentaje de éstas que se
intercambian dentro del mismo AS (con seis ASs en total) y las que se intercambian dentro del
mismo ISP (ya que nuestra red incluye un ISP con dos ASs).
En el caso normal los nodos que se pasan a estado no choking son elegidos con el algoritmo
de choking original de BitTorrent. En los restantes ocho casos los nodos que se pasan a estado no
choking son elegidos con nuestro algoritmo de interés de subida. Lo que varı́a en estos ocho casos
es cómo se calculan las coordenadas, y cómo se calcula la distancia entre los nodos:
Calcular la distancia entre los nodos excluyendo la componente H, lo que llamamos la distancia en el plano.
Utilizar el espacio de vectores de altura con cinco dimensiones, 4D+H.
Utilizar el filtro de mediana para el cálculo de coordenadas.
Esto genera ocho posibles combinaciones de modificaciones:
Caso 2D+H: las coordenadas se calculan en el espacio de vectores de altura con tres dimensiones y la distancia se calcula tomando todas las componentes de las coordenadas.
Caso 2D: el cálculo de distancia excluye la componente H.
Caso 4D+H: las coordenadas se calculan en el espacio de vectores de altura con cinco
dimensiones.
Caso filtro de mediana: las coordenadas se calculan utilizando el filtro de mediana.
Caso 4D: las coordenadas se calculan en el espacio de vectores de altura con cinco dimensiones pero el cálculo de distancia excluye la componente H.
Caso 2D con filtro de mediana: las coordenadas se calculan en el espacio de vectores de
altura con tres dimensiones, utilizando filtro de mediana, pero el cálculo de distancia excluye
la componente H.
Caso 4D+H con filtro de mediana: las coordenadas se calculan en el espacio de vectores
de altura con cinco dimensiones utilizando filtro de mediana.
48
Caso 4D con filtro de mediana: las coordenadas se calculan utilizando el espacio de
vectores de altura con cinco dimensiones, utilizando filtro de mediana, pero el cálculo de
distancia excluye la componente H.
Para cada caso calculamos el porcentaje de piezas que no salen del mismo AS o no salen
del mismo ISP, que presentamos en el cuadro 6. Comparamos con el caso normal, midiendo la
diferencia:
Diferencia = Caso con modificaciones − Caso normal
En cada caso, además, sabemos el total de piezas intercambiadas por el swarm, y por lo tanto
calculamos la cantidad de MB que dejan de salir de los ISPs. Esto es tráfico inter-ISP que se evita,
y podemos cuantificar directamente.
Por otro lado, realizamos el análisis de distancias promedio, que presentamos en el cuadro 7.
En este caso tenemos solamente dos columnas, el promedio de las distancias entre pares de nodos
dentro del mismo AS y el promedio de las distancias entre todos los nodos. El cuadro incluye,
para cada caso, las distancias promedio totales y las distancias promedio en el plano. Este cálculo
de distancias en el plano es independiente del caso particular que se esté considerando, ya que las
distancias en el plano se pueden calcular siempre que se tengan las coordenadas. Estas distancias
se utilizan en el algoritmo de choking modificado solamente en los casos 2D, 4D y 4D con filtro
de mediana, pues son los casos que utilizan la modificación de distancia en el plano. Mostrar la
distancia en el plano en este cuadro nos permite ver si la modificación de coordenadas de cinco
dimensiones contribuye a que la componente H capture mejor la LML.
Guiar el intercambio de piezas teniendo en cuenta la distancia contribuye a aumentar el porcentaje de piezas que se intercambian dentro del mismo ISP. En el mejor de los casos, un 33 % de
las piezas no salen de los ISPs, frente a un 25 % en el caso normal. Esto significa más de 547 MB
(o 8 copias y media del archivo) que dejan de salir de los ISPs, para un swarm de un archivo de
64 MB durante una hora.
Dentro de las distintas combinaciones el mayor incremento se da al calcular la distancia excluyendo la componente H y utilizar el filtro de mediana. Sin embargo, en todos los casos las
combinaciones son mejores que las modificaciones por separado. La única excepción es calcular la
distancia en el plano que, incluso como única modificación, ofrece resultados comparables a los
casos de modificaciones combinadas. Esto es más evidencia de que calcular la distancia en el plano
contribuye a identificar más exactamente peers en ISPs. El filtro de mediana también resulta una
modificación útil, ya que en todos los casos es mejor incluir el filtro de mediana que no incluirlo.
Esto no sucede con el espacio de cinco dimensiones, ya que incluirlo mejora los resultados en un
sólo caso de cuatro totales.
Por otro lado, comparando ambos cuadros vemos una alta correlación entre los métodos que
logran una diferencia entre la distancia promedio intra-AS contra la distancia promedio global, y
su resultado en términos de piezas intercambiadas dentro del ISP. Es decir, confirmamos la idea
de que si las coordenadas son útiles para distinguir peers, entonces serán bien aprovechadas por
la implementación de BitTorrent.
Para finalizar, no encontramos evidencia de que el espacio de vectores de altura de cinco
dimensiones favorezca el comportamiento de la componente H. Analizando los casos comparables
(2D+H contra 4D+H, filtro de mediana contra 4D+H con filtro de mediana, y 2D con filtro de
mediana contra 4D con filtro de mediana) el promedio de distancias totales se mantiene igual o
varı́a poco entre los casos, pero el promedio de distancias en el plano siempre aumenta.
10.1.1.
Experimentación con la ampliación del conjunto de vecinos
No logramos obtener resultados satisfactorios con la implementación de ampliar el conjunto
de vecinos. Las coordenadas se degeneraban al punto de ser inusables. Las componentes de las
coordenadas son números reales y por lo tanto se representan en la computadora utilizando punto
49
Caso
Dentro del mismo AS
Dentro del mismo ISP
Normal
18.50 %
25.36 %
2D+H
Diferencia
MB
23.06 %
4.55 %
326.83
30.22 %
4.86 %
348.43
2D
Diferencia
MB
25.02 %
6.55 %
469.46
32.42 %
7.06 %
506.33
4D+H
Diferencia
MB
23.20 %
4.70 %
337.16
30.08 %
4.72 %
338.71
Filtro de mediana
Diferencia
MB
23.34 %
4.83 %
346.44
30.89 %
5.53 %
396.45
4D
Diferencia
MB
24.53 %
6.03 %
432.25
32.41 %
7.05 %
505.09
2D con filtro de mediana
Diferencia
MB
25.35 %
6.84 %
489.83
33.01 %
7.65 %
547.43
4D+H con filtro de mediana
Diferencia
MB
24.95 %
6.45 %
461.57
32.43 %
7.07 %
506.10
4D con filtro de mediana
Diferencia
MB
24.95 %
6.44 %
461.28
32.64 %
7.27 %
520.72
Cuadro 6: Porcentaje de piezas intercambiadas dentro del mismo AS e ISP, con las modificaciones
50
Distancia
promedio
entre nodos
del mismo AS
(ms)
Distancia
promedio
entre todos
los nodos
(ms)
Porcentaje
respecto
del total
Normal, distancia en el plano
Normal
64.16
106.47
65.26
107.57
98.31
98.98
2D+H, distancia en el plano
2D+H
62.22
103.59
64.72
106.09
96.14
97.65
2D, distancia en el plano
2D
63.86
106.60
66.02
108.76
96.73
98.02
4D+H, distancia en el plano
4D+H
71.44
108.87
73.42
110.85
97.30
98.21
Filtro de mediana, distancia en el plano
Filtro de mediana
65.52
95.53
74.66
104.67
87.76
91.27
4D, distancia en el plano
4D
73.38
106.65
75.51
108.77
97.19
98.05
2D con filtro de mediana, distancia en el plano
2D con filtro de mediana
66.73
99.93
72.98
106.18
91.44
94.11
4D+H con filtro de mediana, distancia en el plano
4D+H con filtro de mediana
79.89
94.17
90.69
104.98
88.08
89.71
4D con filtro de mediana, distancia en el plano
4D con filtro de mediana
81.71
98.76
89.18
106.23
91.63
92.97
Caso
Cuadro 7: Distancias promedio en BitTorrent con modificaciones
51
flotante; en todas las simulaciones utilizando esta modificación sucedió que las coordenadas tarde
o temprano tenı́an todas componentes con valor Not-a-Number 24 .
Resultó que esta modificación estaba causando que las actualizaciones de coordenadas de los
nodos aumentaran constantemente la componente H, incluso en los casos en los que la distancia
era mayor a la latencia. Al aumentar la componente H aumenta la distancia entre dos nodos, ya
que la componente H es siempre positiva y en el cálculo de distancia la componente H se suma.
En la siguiente actualización, el nodo se encontraba más lejos de lo que se habı́a calculado en la
actualización anterior. La distancia era todavı́a mayor a la latencia, el error era mayor que en la
actualización anterior, e incluso ası́ el desplazamiento volvı́a a aumentar la componente H.
¿Por qué no pasa esto en la ejecución normal? En la ejecución normal cada medición resulta en
una actualización. Esta medición tiene una componente H positiva. El desplazamiento calculado
también tendrá una componente H positiva, ya que la operatoria de vectores de altura ası́ lo
requiere, pero antes de ser sumado a la coordenada actual, el desplazamiento es escalado con un
factor que depende de la diferencia entre el RTT y la distancia. Este factor sı́ puede ser negativo,
en caso de que la distancia sea mayor que el RTT. De esta manera, si la distancia es mayor que el
RTT, el desplazamiento disminuirá el valor de las componentes de la coordenada, de manera de
reducir la distancia, y acercarla al RTT.
Al utilizar escalamiento de vecinos los desplazamientos se promedian de manera ponderada, y
luego se suman a la coordenada. Creemos que lo que sucede es que al promediarse, las componentes
negativas de algunos desplazamientos se ven compensadas por otras componentes positivas, y de
esta manera el desplazamiento promedio final que se suma tiene todas componentes positivas, y
de esta manera podrı́a estar aumentando la distancia de un nodo (si se aumenta la componente
H) en un caso en el que deberı́a haberse disminuı́do.
El sistema de coordenadas, al encontrar cada vez los nodos más alejados entre sı́, y de esta
manera con más y más error entre distancia y RTT, degeneraba en una situación en la que las
componentes X e Y se movı́an hacia el origen, intentando compensar el aumento de distancia
generado por la suma siempre positiva en la componente H. Eventualmente la componente H se
hacı́a infinito25 . Luego, al intentar operar con estos infinitos aparecı́an los NaNs que degeneraban
las coordenadas, ya que todas las distancias eran NaNs y por lo tanto el upload appeal también
era NaN y la elección de peers se volvı́a inútil.
Revisamos la operatoria de Vivaldi presentada en [7] y la modificación de ampliar el conjunto
de vecinos presentada en [11] y no encontramos nada que pudiera sugerir este comportamiento.
Suponemos que el hecho de que en ese trabajo las coordenadas no se utilizaran para guiar la
elección de peers hizo que no encontraran este comportamiento.
24 Not-a-Number (NaN) es un valor especial en el esquema de punto flotante que representa el resultado de una
operación indefinida.
25 El esquema de punto flotante también incluye valores especiales para representar el infinito.
52
11.
Conclusiones
Este trabajo tenı́a dos objetivos principales: caracterizar el comportamiento de una implementación de coordenadas virtuales en una red con enlaces de banda ancha residencial y utilizar
la información provista por el sistema de coordenadas para aumentar el tráfico intra-ISP de un
swarm BitTorrent.
En nuestra opinión los aportes de este trabajo son:
La aplicación de un sistema de coordenadas virtuales para guiar el tráfico de un swarm
BitTorrent.
Una implementación del protocolo Vivaldi en un simulador que permite construir redes
de cualquier caracterı́stica, incluyendo una modificación que tiene como objetivo reducir el
impacto de la latencia del link de acceso.
Un análisis detallado del comportamiento de Vivaldi en una red con enlaces de banda ancha
residencial, haciendo énfasis en cómo la latencia de estos enlaces afecta la calidad de las
coordenadas.
Una implementación de BitTorrent en el mismo simulador, que permite ver el comportamiento de un swarm de cualquier cantidad de peers bajando un archivo de cualquier tamaño.
Una modificación al algoritmo de choking de BitTorrent que pasa el porcentaje de tráfico
intercambiado entre nodos de un mismo ISP del 25 % al 33 %, sin afectar las tasas de transferencia ni los tiempos de bajada, y que funciona de manera completamente distribuida.
Un análisis detallado de las modificaciones propuestas para utilizar Vivaldi a cuestas del
tráfico de otra aplicación.
Realizamos una implementación de Vivaldi en el simulador SSFNet, que soporta construir redes
con enlaces de banda ancha residencial. Evaluamos el sistema de coordenadas en una red inspirada
en la red de un ISP de banda ancha en Argentina. El simulador nos permitió generar escenarios
de LML alta, caracterı́stica saliente de las redes de banda ancha residenciales.
Las coordenadas obtenidas por Vivaldi en la red de prueba del simulador resultaron buenas,
agrupando correctamente los nodos que pertenecı́an al mismo AS. La distancia promedio entre
dos nodos del mismo AS fue aproximadamente un cuarto de la distancia promedio entre cualquier
par de nodos, mientras que solamente un 7 % de los pares de nodos en distintos ASs calcularon
entre ellos una distancia menor que el promedio de distancias intra-AS. Por lo tanto, fue factible
utilizar la latencia estimada por las coordenadas para que los nodos de BitTorrent eligieran otros
peers de su mismo ISP. Logramos además caracterizar el comportamiento de Vivaldi en escenarios
de LML alta, mostrando que existen maneras de salvar la degradación de las coordenadas en estas
situaciones, como realizar el cálculo de distancia entre dos nodos sin tener en cuenta la componente
H de sus coordenadas.
Realizamos una implementación completa de BitTorrent en el mismo simulador. La implementación permite elegir tanto la cantidad de peers del swarm como el tamaño del archivo a compartir.
Incluimos todos los mecanismos básicos de BitTorrent: las distintas estrategias de elección de piezas, el algoritmo de choking y los mensajes de control. Debido a que realizamos la implementación
de Vivaldi a cuestas del tráfico de BitTorrent incorporamos las modificaciones propuestas en [11]
para contrarrestar la degradación de Vivaldi en esta situación.
Modificamos el algoritmo de choking de BitTorrent para que decidiera empates entre dos peers
remotos con la misma tasa de subida eligiendo al nodo más cercano. Utilizando esta implementación
pasamos de un 25 % de piezas que no salen del respectivo ISP a un 33 %. Esto significa un 30 % de
mejora o más de 500 MB de tráfico que deja de salir de los ISPs para un swarm de BitTorrent de
120 peers compartiendo un archivo de 64 MB durante una hora. Calcular la distancia excluyendo
la componente H contribuye a aumentar el tráfico intra-ISP, lo cual sugiere que la componente
H del espacio de vectores de altura captura la latencia generada por el link de acceso. Utilizar
53
un filtro de mediana para las mediciones de latencia también contribuye a aumentar el tráfico
intra-ISP, ya que evita que mediciones espurias de latencia agreguen error a las coordenadas.
Concluimos que es factible el uso de sistemas de coordenadas virtuales para que el tráfico de
las aplicaciones P2P sea más ameno para los ISPs. Las coordenadas construidas por Vivaldi son
útiles para obtener información acerca de la ubicación relativa de los nodos, aún perdiendo calidad
al ser utilizadas a cuestas del tráfico de otra aplicación y sufriendo las latencias de las conexiones
de banda ancha residencial. En lı́nea con los resultados de [21] creemos que el enfoque distribuı́do
para el problema del tráfico generado por las aplicaciones P2P tiene mejores perspectivas al ser
más fácil de implementar y tener mayores posibilidades de escalar.
54
12.
Trabajo futuro
Las coordenadas en nuestra red de prueba se degradaron notablemente al utilizar Vivaldi a
cuestas de los mensajes de BitTorrent. ¿Son tan importantes los requerimientos de conectividad
mencionados en [7] para la exactitud de las coordenadas? ¿Es factible realizar modificaciones
a un sistema de coordenadas existente o es necesario idear otro sistema que tenga en cuenta
una operatoria a cuestas desde el comienzo? Creemos que vale la pena considerar un sistema de
estimación de latencia para ser utilizado directamente en una aplicación aprovechando el tráfico
generado por ésta. De manera complementaria, también serı́a importante analizar si la operatoria
de Vivaldi a cuestas de otra aplicación se justifica cuando las coordenadas generadas por Vivaldi de
manera autónoma tienen mucho menos error. Existe la posibilidad de que el tráfico extra generado
por Vivaldi de manera autónoma sea compensado por el aumento del tráfico intra-ISP logrado al
tener coordenadas más exactas.
Por otro lado, el espacio de vectores de altura propuesto para Vivaldi es más que nada una
modificación ad-hoc que muestra un buen comportamiento en la práctica. ¿Podemos encontrar espacios que embeban mejor la estructura de Internet? Una posibilidad son las geometrı́as hiperbólicas, mencionadas ya en [7]. Estas geometrı́as tienen caracterı́sticas que las hacen apropiadas para
la estructura de Internet [28].
Nuestra implementación del protocolo BitTorrent envı́a mensajes bitfield como primer mensaje en cualquier conexión, y en ambos sentidos. Si estos mensajes tuvieran suficiente información
de coordenadas como para poder realizar una estimación de latencia al inicio de la conexión, el
peer local podrı́a evitar conexiones nuevas de peers remotos lejanos. Elegir o rechazar peers antes
de iniciar el intercambio de piezas no tendrı́a un efecto directo sobre la tasa de transferencia,
más allá de poder llevar al peer local a rechazar peers remotos que podrı́an tener mucho ancho de
banda de subida. Lo que sı́ serı́a un problema es que esta elección lleve al peer local a perder piezas
que solamente están presentes en peers remotos lejanos. Esto podrı́a resultar en que el swarm se
fragmente en grupos de nodos cercanos conectados entre sı́, ninguno de los cuales posee todas las
piezas del archivo a bajar. Las soluciones que utilizan oráculos [8, 10] consideran este problema,
pero las estrategias para evitarlo no parecen aplicarse bien al caso de los sistemas de coordenadas.
Creemos que vale la pena analizar mecanismos para, de la misma manera que balanceamos la tasa
de subida de un peer remoto con su distancia, balancear las piezas que un peer remoto posee y la
distancia a la que se encuentra.
Por último, existen tanto otros sistemas de coordenadas, como GNP [22]; otros métodos de
estimación de latencia que directamente no utilizan coordenadas virtuales, como Meridian [12]; y
otros métodos de identificación de nodos en ISPs, como WHOIS. El funcionamiento de Vivaldi lo
hace ideal para utilizar en un swarm BitTorrent, pero si otros mecanismos de estimación de latencia
tuvieran más exactitud, podrı́a ser útil considerar modificaciones más generales a BitTorrent para
poder acomodarlos. Tanto GNP como Meridian requerirı́an más estructura en el swarm BitTorrent.
Sin embargo, esta estructura no vendrı́a acompañada de servidores centrales como en el caso de
P4P, y mantendrı́a el funcionamiento distribuido del swarm. Incluso bases de datos administrativas,
como WHOIS, podrı́an complementarse bien con el enfoque de cercanı́a utilizado en este trabajo,
combinando información de la red en forma de latencia, e información administrativa en forma de
consultas a WHOIS.
55
Referencias
[1] “Internet Study 2007,” ipoque, Tech. Rep., November 2007.
[2] J. Saltzer, D. Reed, and D. Clark, “End-to-end Arguments in System Design,” ACM Transactions in Computer Systems, vol. 2, no. 4, pp. 277–288, November 1984.
[3] K. Cho, K. Fukuda, H. Esaki, and A. Kato, “The Impact and Implications of the Growth in
Residential User-to-User Traffic,” in Proceedings of SIGCOMM ’06, 2006.
[4] N. Anderson and E. Bangeman, “Comcast loses P2P religion, goes agnostic on throttling,”
September 2008. [Online]. Available: http://arstechnica.com/news.ars/post/20080919comcast-loses-p2p-religion-goes-agnostic-on-throttling.html
[5] N. Anderson, “BitTorrent has new plan to shape up P2P behavior,” December
2008. [Online]. Available: http://arstechnica.com/news.ars/post/20081209-bittorrent-hasnew-plan-to-shape-up-p2p-behavior.html
[6] B. Cohen, “Incentives Build Robustness in BitTorrent,” 2003.
[7] F. Dabek, R. Cox, F. Kaashoek, and R. Morris, “Vivaldi: A Decentralized Network Coordinate
System,” in Proceedings of IEEE SIGCOMM 2004, 2004.
[8] R. Bindal, P. Cao, W. Chan, J. Medved, G. Suwala, T. Bates, and A. Zhang, “Improving
Traffic Locality in BitTorrent via Biased Neighbor Selection,” in Proceedings of the 26th IEEE
international Conference on Distributed Computing Systems, ICDCS, 2006.
[9] M. Adler, R. Kumar, K. W. Ross, D. Rubenstein, T. Suel, and D. D. Yao, “Optimal Peer
Selection for P2P Downloading and Streaming,” in Proceedings of IEEE INFOCOM 2005,
March 2005.
[10] H. Xie, Y. R. Yang, A. Krishnamurthy, Y. Liu, and A. Silberschatz, “P4P: Provider Portal
for P2P Applications,” in Proceedings of SIGCOMM 2008, 2008.
[11] P. Gardner, J. Ledlie, and M. Seltzer, “Network Coordinates in the Wild,” in Proceedings of
NSDI ’07, April 2007.
[12] B. Wong, A. Slivkins, and E. G. Sirer, “Meridian: A Lightweight Network Location Service Without Virtual Coordinates,” SIGCOMM Computer Communications Review, October
2005.
[13] S. Androutsellis-Theotokis and D. Spinellis, “A Survey of Peer-to-Peer Content Distribution
Technologies,” ACM Computing Surveys, vol. 36, no. 4, pp. 335–371, 2004 December.
[14] H. Balakrishnan, M. F. Kaashoek, D. Karger, R. Morris, and I. Stoica, “Looking Up Data in
P2P Systems,” Communications of the ACM, vol. 46, no. 2, pp. 43–48, February 2003.
[15] “Twitter.” [Online]. Available: www.twitter.com
[16] “YouTube.” [Online]. Available: www.youtube.com
[17] N. Anderson, “Forecast: Legal P2P uses growing 10x faster than illegal ones,” October 2008.
[Online]. Available: http://arstechnica.com/news.ars/post/20081022-forecast-legal-p2p-usesgrowing-10x-faster-than-illegal-ones.html
[18] M. Dischinger, K. P. Gummadi, A. Haeberlen, and S. Saroiu, “Characterizing Residential
Broadband Networks,” in Proceedings of the 7th ACM SIGCOMM Conference on Internet
Measurement, IMC ’07, October 2007.
56
[19] R. Paul, “Verizon embraces P4P, a more efficient peer-to-peer tech,” March 2008.
[Online]. Available: http://arstechnica.com/news.ars/post/20080314-verizon-embraces-p4pa-more-efficient-peer-to-peer-tech.html
[20] N. Anderson, “Comcastic P4P trial shows 80 % speed boost for P2P downloads,” November
2008. [Online]. Available: http://arstechnica.com/news.ars/post/20081103-comcastic-p4ptrial-shows-80-speed-boost-for-p2p-downloads.html
[21] D. R. Choffnes and F. E. Bustamante, “Taming the Torrent: A practical approach to reducing
cross-ISP traffic in peer-to-peer systems,” in Proceedings of ACM SIGCOMM 2008, August
2008.
[22] T. S. E. Ng and H. Zhang, “Predicting Internet Network Distance with Coordinates-Based
Approaches,” CMU, Tech. Rep., 2002.
[23] L. Peterson, T. Anderson, D. Culler, and T. Roscoe, “A Blueprint for Introducing Disruptive
Technology into the Internet,” in Proceedings of the 1st ACM Workshop on Hot Topics in
Networks (HotNets-I), October 2002.
[24] D. Towsley, “The Internet is Flat: a Brief History of Networking in the Next Ten Years,” in
Proceedings of PODC ’08, 2008.
[25] “SSFNet.” [Online]. Available: www.ssfnet.org
[26] V. Aggarwal, A. Feldmann, and C. Scheideler, “Can ISPs and P2P Users Cooperate for
Improved Performance?” ACM SIGCOMM Computer Communication Review, vol. 37, no. 3,
2007 July.
[27] “uTP
(UDP
torrenting).”
http://forum.utorrent.com/viewtopic.php?id=49813
[Online].
Available:
[28] Y. Shavitt and T. Tankel, “Overlay Construction and Distance Estimation,” in Proceedings
of IEEE INFOCOM 2004, 2004.
57