Un estudio en redes 802.11

Proyecto de Grado
Presentado ante la ilustre Universidad de Los Andes como requisito final para
obtener el Tı́tulo de Ingeniero de Sistemas
Diseño e implementación de un mecanismo de
arranque rápido de flujos transporte: Un
estudio en redes 802.11
Por
Br. Omar A. Dı́az M.
Tutor: Prof. Andrés Arcia Moret
Abril 2012
c
2012
Universidad de Los Andes Mérida, Venezuela
Diseño e implementación de un mecanismo de arranque
rápido de flujos transporte: Un estudio en redes 802.11
Br. Omar A. Dı́az M.
Proyecto de Grado — Sistemas Computacionales, 138 páginas
Resumen: El advenimiento de redes de acceso más rápidas, conlleva la necesidad
de aprovechar el ancho de banda disponible más eficientemente. Esta eficiencia debe
considerar al menos tres aspectos: el aprovechamiento rápido del ancho de banda
disponible, el mantenimiento de la justicia en el uso del ancho de banda y el aumento
efectivo del rendimiento de las transferencias. Es posible modificar TCP sin violar el
principio de extremo a extremo, para aprovechar el ancho de banda disponible en la
red más rápidamente que como se define en el algoritmo clásico de Slow Start. En
esta propuesta la retroalimentación hecha por los ACKs, no significa solamente, como
en el algoritmo clásico, que un paquete ha salido de la red, sino también que pueden
inyectarse tantos paquetes como lo indique el receptor. La idea consiste en dividir los
ACKs (divacks), para que cada uno reconozca una porción de un paquete (sin perder
la semántica de TCP), pudiendo entonces enviarse varios ACKs por un solo paquete
de datos. Esta propiedad permite controlar el ritmo de envı́o de divacks en el receptor
TCP aumentando considerablemente y a voluntad del receptor la tasa de envı́o de
datos en el emisor.
Palabras clave: Control de Congestión, División de ACK, Arranque rápido, Redes
802.11, TCP.
Índice general
Índice general
III
Índice de Figuras
VI
Índice de figuras
VI
Índice de Cuadros
XIII
Agradecimientos
XV
1. Introducción
1
1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2. Definición del Problema . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4.2. Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . . . .
6
1.5. Metodologı́a de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.6. Alcance del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.7. Estructura del Documento . . . . . . . . . . . . . . . . . . . . . . . . .
7
2. Marco Teórico
9
2.1. Protocolo de Control de Transmisión . . . . . . . . . . . . . . . . . . .
9
2.2. Control de la congestión: Slow Start y Congestion Avoidance . . . . . .
12
2.2.1. Algoritmo Slow Start . . . . . . . . . . . . . . . . . . . . . . . .
13
iii
2.2.2. Algoritmo Congestion Avoidance . . . . . . . . . . . . . . . . .
14
2.3. Envı́o de ACKs: Delayed-ACK y divacks . . . . . . . . . . . . . . . . .
14
2.3.1. Delayed-ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3.2. División de reconocimientos (divacks) . . . . . . . . . . . . . . .
16
2.4. Aclaratoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.5. Kernel Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.5.1. Implementación de TCP en el kernel Linux v2.6.35.7 . . . . . .
18
2.5.2. Parámetros TCP . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.6. Herramientas de medición y procesamiento de tráfico de red . . . . . .
22
2.6.1. Wireshark/Tshark
. . . . . . . . . . . . . . . . . . . . . . . . .
22
2.6.2. Tcpprobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.7. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3. Desarrollo de la técnica
25
3.1. División de ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2. Descripción del Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.1. Variables implicadas en la formación de los divacks . . . . . . .
28
3.2.2. Mecanismos afectados por los divacks . . . . . . . . . . . . . . .
29
3.2.3. Presentación del algoritmo . . . . . . . . . . . . . . . . . . . . .
29
3.3. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4. Implementación de la Técnica
33
4.1. Técnica de control de envı́o de divacks . . . . . . . . . . . . . . . . . .
33
4.2. Modificaciones en el Servidor . . . . . . . . . . . . . . . . . . . . . . . .
36
4.3. Modificaciones en el Cliente . . . . . . . . . . . . . . . . . . . . . . . .
40
4.4. Limitación de los divacks . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.5. Compilación del kernel . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.6. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5. Pruebas
53
5.1. Configuración de las pruebas . . . . . . . . . . . . . . . . . . . . . . . .
53
5.2. Pruebas sobre red cableada
54
. . . . . . . . . . . . . . . . . . . . . . . .
5.3. Pruebas sobre red cableada simulando una WAN . . . . . . . . . . . . .
64
5.3.1. Tiempo de retardo de 10 ms . . . . . . . . . . . . . . . . . . . .
65
5.3.2. Tiempos mayores de retardo . . . . . . . . . . . . . . . . . . . .
70
5.4. Pruebas sobre red Inalámbrica . . . . . . . . . . . . . . . . . . . . . . .
77
5.4.1. Configuración de las pruebas . . . . . . . . . . . . . . . . . . . .
77
5.4.2. Pruebas y resultados . . . . . . . . . . . . . . . . . . . . . . . .
78
5.5. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6. Conclusiones y Recomendaciones
115
Bibliografı́a
118
Referencias
118
A. Scripts utilizados para la realización y procesamiento de las pruebas120
A.1. Script para la configuración de Netem . . . . . . . . . . . . . . . . . . . 120
A.2. Script para las pruebas de descarga del cliente . . . . . . . . . . . . . . 122
A.3. Script para pruebas de descarga del sevidor . . . . . . . . . . . . . . . . 124
A.4. Scripts para el cálculo del throughput . . . . . . . . . . . . . . . . . . . 125
A.5. Scripts para la creación de las gráficas . . . . . . . . . . . . . . . . . . 128
Índice de figuras
1.1. Crecimiento de la cwnd en slow start mediante el uso de divacks. . . . .
5
2.1. Vida de una conexión TCP . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2. Comportamiento de la cwnd en slow start . . . . . . . . . . . . . . . .
13
2.3. Comportamiento de la cwnd en congestion avoidance . . . . . . . . . .
14
2.4. Envı́o de un ACK por paquete . . . . . . . . . . . . . . . . . . . . . . .
15
2.5. Delayed-ACK, un ACK por cada dos paquetes . . . . . . . . . . . . . .
16
2.6. Técnica de división de ACKs: 3 ACKs por cada paquete de datos. . . .
17
3.1. Ejemplo de la técnica de divacks. . . . . . . . . . . . . . . . . . . . . .
27
3.2. Valores de snd nxt y snd una en el emisor. . . . . . . . . . . . . . . . .
28
4.1. Proceso de envı́o de datos ante la llegada de un ACK. . . . . . . . . . .
37
4.2. Comportamiento de la función tcp clean rtx queue(). . . . . . . . . . .
39
4.3. Mecanismo de envı́o de ACKs ante la llegada de un paquete de datos. .
41
4.4. Ruta para activar algoritmo de control de congestión por omisión. . . .
50
4.5. Captura de pantalla menuconfig: Selección del algoritmo de control de
congestión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.1. Topologı́a simple Cliente-Servidor. . . . . . . . . . . . . . . . . . . . . .
54
5.2. Captura de pantalla de una traza en Wireshark, sin divacks. . . . . . .
55
5.3. Captura de pantalla de una traza en Wireshark. . . . . . . . . . . . . .
57
5.4. Captura de pantalla de una traza en Wireshark (Fin de la conexión). .
58
5.5. Comparación del crecimiento de la cwnd con y sin divacks. . . . . . . .
60
vi
5.6. Comparación del proceso de descarga de un archivo de 99 KB con y sin
divacks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.7. Descarga de archivo de 99 KB con divacks (acercamiento). . . . . . . .
62
5.8. Comparación del proceso de descarga de un archivo de 99 KB con y sin
divacks, sobre una red cableada (Traza del servidor). . . . . . . . . . .
63
5.9. Topologı́a WAN emulada con netem. . . . . . . . . . . . . . . . . . . .
65
5.10. Comparación del crecimiento de la cwnd de control, con n=9, 20 ms de
RTT y archivo de tamaño 99 kB, sobre una red cableada. . . . . . . . .
66
5.11. Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 20 ms de RTT, sobre una red cableada (Traza del cliente). 66
5.12. Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 20 ms de RTT, sobre una red cableada (Traza del servidor). 68
5.13. Comparación del crecimiento de la cwnd de control, con n=9, 20 ms de
RTT y archivo de tamaño 990 kB, sobre una red cableada. . . . . . . .
68
5.14. Comparación del proceso de descarga de un archivo de 990 KB de
control, con n=9 y con 20 ms de RTT, sobre una red cableada (Traza
del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.15. Comparación del proceso de descarga de un archivo de 990 KB de
control, con n=9 y con 20 ms de RTT, sobre una red cableada (Traza
del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.16. Comparación del crecimiento de la cwnd de control, con n=9, 50 ms de
RTT y archivo de tamaño 99 kB, sobre una red cableada. . . . . . . . .
71
5.17. Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 50 ms de RTT, sobre una red cableada (Traza del cliente). 71
5.18. Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 50 ms de RTT, sobre una red cableada (Traza del servidor). 72
5.19. Comparación del crecimiento de la cwnd de control, con n=9, 80 ms de
RTT y archivo de tamaño 99 kB, sobre una red cableada. . . . . . . . .
73
5.20. Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 80 ms de RTT, sobre una red cableada (Traza del cliente). 73
5.21. Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 80 ms de RTT, sobre una red cableada (Traza del servidor). 74
5.22. Comparación del rendimiento de descarga de un archivo de 99 kb, con
diferentes tiempos de retardo, en una red cableada. . . . . . . . . . . .
75
5.23. Comparación del tiempo de descarga de un archivo de 99 kb, con
diferentes tiempos de retardo, en una red cableada. . . . . . . . . . . .
75
5.24. Comparación del rendimiento de descarga de un archivo de 990 kb, con
diferentes tiempos de retardo, en una red cableada. . . . . . . . . . . .
76
5.25. Comparación del tiempo de descarga de un archivo de 990 kb, con
diferentes tiempos de retardo, en una red cableada. . . . . . . . . . . .
76
5.26. Maqueta de red de acceso inalámbrico. . . . . . . . . . . . . . . . . . .
77
5.27. Comparación del crecimiento de la cwnd utilizando diferentes valores de
n y tamaño de archivo de 99 kB, sobre una red inalámbrica. . . . . . .
79
5.28. Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del cliente). .
80
5.29. Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del servidor).
80
5.30. Comparación crecimiento de la cwnd utilizando diferentes valores de n
y tamaño de archivo de 198 kB, sobre una red inalámbrica. . . . . . . .
81
5.31. Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del cliente). .
81
5.32. Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del servidor).
82
5.33. Comparación del crecimiento de la cwnd utilizando diferentes valores de
n y tamaño de archivo de 990 kB, sobre una red inalámbrica. . . . . . .
82
5.34. Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del cliente). .
83
5.35. Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del servidor).
83
5.36. Comparación del crecimiento de la cwnd utilizando diferentes valores de
n, 20 ms de RTT y tamaño de archivo de 99 kB, sobre una red inalámbrica. 84
5.37. Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica (Traza
del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
5.38. Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica (Traza
del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
5.39. Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 20 ms de RTT y tamaño de archivo de 198 kB, sobre una red
inalámbrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
5.40. Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica (Traza
del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
5.41. Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica (Traza
del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
5.42. Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 20 ms de RTT y tamaño de archivo de 990 kB, sobre una red
inalámbrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
5.43. Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica (Traza
del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
5.44. Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica (Traza
del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
5.45. Comparación del crecimiento de la cwnd utilizando diferentes valores de
n, 50 ms de RTT y tamaño de archivo de 99 kB, sobre una red inalámbrica. 89
5.46. Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica (Traza
del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.47. Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica (Traza
del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
5.48. Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 50 ms de RTT y tamaño de archivo de 198 kB, sobre una red
inalámbrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
5.49. Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica (Traza
del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
5.50. Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica (Traza
del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
5.51. Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 50 ms de RTT y tamaño de archivo de 990 kB, sobre una red
inalámbrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
5.52. Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica (Traza
del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.53. Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica (Traza
del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.54. Comparación del crecimiento de la cwnd utilizando diferentes valores de
n, 80 ms de RTT y tamaño de archivo de 99 kB, sobre una red inalámbrica. 95
5.55. Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica (Traza
del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.56. Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica (Traza
del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.57. Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 80 ms de RTT y tamaño de archivo de 198 kB, sobre una red
inalámbrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.58. Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica (Traza
del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
5.59. Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica (Traza
del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
5.60. Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 80 ms de RTT y tamaño de archivo de 990 kB, sobre una red
inalámbrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
5.61. Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica (Traza
del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.62. Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica (Traza
del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.63. Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 250 ms de RTT y tamaño de archivo de 99 kB, sobre una red
inalámbrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.64. Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.65. Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.66. Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 250 ms de RTT y tamaño de archivo de 198 kB, sobre una red
inalámbrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.67. Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.68. Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.69. Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 250 ms de RTT y tamaño de archivo de 990 kB, sobre una red
inalámbrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.70. Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del cliente). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.71. Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.72. Comparación del rendimiento de descarga de archivos de tamaño 99 kB
con diferentes tiempos de retardo. . . . . . . . . . . . . . . . . . . . . . 111
5.73. Comparación del tiempo de descarga de archivos de tamaño 99 kB con
diferentes tiempos de retardo. . . . . . . . . . . . . . . . . . . . . . . . 112
5.74. Comparación del rendimiento de descarga de archivos de tamaño 198
kB con diferentes tiempos de retardo. . . . . . . . . . . . . . . . . . . . 112
5.75. Comparación del tiempo de descarga de archivos de tamaño 198 kB con
diferentes tiempos de retardo. . . . . . . . . . . . . . . . . . . . . . . . 113
5.76. Comparación del rendimiento de descarga de archivos de tamaño 990
kB con diferentes tiempos de retardo. . . . . . . . . . . . . . . . . . . . 113
5.77. Comparación del tiempo de descarga de archivos de tamaño 990 kB con
diferentes tiempos de retardo. . . . . . . . . . . . . . . . . . . . . . . . 114
Índice de Cuadros
2.1. Archivo generado por tcp probe. . . . . . . . . . . . . . . . . . . . . .
23
3.1. Algoritmo de divacks en el receptor TCP. . . . . . . . . . . . . . . . . .
31
4.1. Declaración de tcp divack (net/ipv4/tcp intput.c) . . . . . . . . . . .
34
4.2. ipv4 table[ ] (net/ipv4/sysctl net ipv4.c) . . . . . . . . . . . . . . . . .
35
4.3. Definición de nombres sysctl (include/linux/sysctl.h) . . . . . . . . . .
35
4.4. bin net ipv4 table[ ] (kernel/sysctl binary.c) . . . . . . . . . . . . . . .
36
4.5. sysctl tcp divack (include/net/tcp.h) . . . . . . . . . . . . . . . . . . .
36
4.6. Modificación
en
el
servidor
de
la
función
tcp ack()
(net/ipv4/tcp input.c). . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.7. Implementación de la técnica de divacks en el receptor TCP
(net/ipv4/tcp input.c) . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.8. Mensajes de depuración del kernel. . . . . . . . . . . . . . . . . . . . .
44
4.9. Modificación en el cliente de la función
tcp select window()
(net/ipv4/tcp output.c) . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.10. Modificación en el servidor de la función tcp reno cong avoid()
(net/ipv4/tcp input.c) . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.11. Compilación del kernel. . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.1. Diagrama de flechas de una transmisión TCP, sin divacks. . . . . . . .
56
5.2. Diagrama de flechas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5.3. Ping realizado entre el receptor y el emisor usando un retardo de 10 ms. 65
5.4. Ping realizado entre el receptor y el emisor usando un retardo de 25 ms. 70
5.5. Ping realizado entre el receptor y el emisor usando un retardo de 40 ms. 72
A.1. netem.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
A.2. Script bash del cliente para realizar las pruebas de descarga
xiii
. . . . . . 122
A.3. Script bash del servidor para realizar las pruebas de descarga . . . . . . 124
A.4. throughput.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
A.5. throughput.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
A.6. throughput-promedio.py . . . . . . . . . . . . . . . . . . . . . . . . . . 127
A.7. graficar-cwnd.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
A.8. cwnd.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
A.9. graficar-descarga.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
A.10.graficar-descarga-srv.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
A.11.graficar-throughput.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Agradecimientos
Quiero agradecer sinceramente a todos cuyo apoyo y colaboración hicieron posible
la culminación de este proyecto.
Primero a mi mamá, que con su apoyo siempre me anima a salir adelante y con su
ejemplo me impulsa a alcanzar mis metas.
A mi familia, que siempre espera lo mejor de mi lo que me motiva a poner mi mayor
esfuerzo en las cosas que hago.
Al profesor Andrés Arcia Moret, por la confianza que ha puesto en mi y su gran
ayuda, no solo en la realización de este proyecto, sino en parte importante de mi
desarrollo académico.
A mis amigos, que me han demostrado que puedo contar con ellos cuando lo necesito.
En especial a mi querida amiga Samantha Gamboa, con quien inicié este proyecto, lo
cual fue de gran ayuda y un importante impulso para seguir superando obstáculos
durante el desarrollo del proyecto.
A la Universidad de Los Andes, que ha sido mi casa de estudios, el hogar de una
nueva gran familia que ahora forma parte de mi vida. Por brindarme los medios y
conocimientos que hoy me convierten en un profesional. Me siento orgulloso de formar
parte de esta casa de estudios.
A las secretarias de la facultad de Ingenierı́a, siempre dispuestas a ayudar a resolver
cualquier problema y prestar todo su apoyo.
A todos aquellos que a pesar de que no he nombrado, han colaborado de alguna
manera al buen desarrollo y finalización de este proyecto.
xv
Capı́tulo 1
Introducción
Bajo ciertas condiciones, TCP por sı́ solo, no es capaz de aprovechar el ancho de
banda como deberı́a. Por ejemplo en caı́das abruptas de la ventana de congestión por
pérdidas aleatorias, TCP no se comporta de manera apropiada, y trata este tipo de
evento de la misma manera como lidia con la congestión de la red, desperdiciándose
ası́ mucho ancho de banda.
Hoy en dı́a TCP es uno de los protocolos fundamentales, y por lo tanto, más
difundido de Internet. Por ser un protocolo de la capa transporte su función es
comunicar aplicaciones en hosts distintos, para ello, el host emisor divide en segmentos
el flujo de datos a enviar, cada segmento es etiquetado con un número de secuencia
para garantizar el orden y confiabilidad de los datos. Cuando el host receptor recibe
un segmento en orden, éste envı́a un reconocimiento acumulativo, denominado ACK,
el cual notifica al emisor que todos los datos precedentes a ese número de secuencia
han sido recibidos y pueden ser retirados del buffer de retransmisión del emisor.
Una de las caracterı́sticas de TCP es el control de la congestión, para esto utiliza
varios algoritmos, entre los cuales se encuentran slow start y congestion avoidance.
Estos algoritmos controlan el ritmo de envı́o de datos mediante la manipulación de una
ventana de congestión (cwnd ) que limita el número de paquetes que se pueden enviar
sin haber recibido un ACK. Cuando una conexión comienza, el algoritmo slow start es
utilizado para incrementar rápidamente el tamaño de la cwnd y ası́ utilizar el máximo
ancho de banda de envı́o disponible. Durante slow start, TCP incrementa la cwnd
1.1 Antecedentes
2
a lo sumo SMSS (Sender Maximum Segment Size o Tamaño Máximo de Segmento
en el emisor) bytes por cada ACK recibido que reconoce un nuevo dato. Se puede
aprovechar esta caracterı́stica y explotarla como una vulnerabilidad, ası́, cada ACK
puede ser dividido en varios ACKs (igualmente válidos), a los que llamaremos divacks,
incrementando la velocidad con que slow start aumenta el tamaño de la cwnd y de esta
manera poder aprovechar mejor el ancho de banda disponible al inicio de una conexión.
1.1.
Antecedentes
Arcia (2009) realiza un estudio minucioso sobre la división de ACKs, en su tesis
Doctoral expone una recopilación de los estudios y propuestas realizadas sobre esta
técnica, como una forma de mejorar el rendimiento de TCP. Expone las discusiones
existentes sobre este tema y hace un análisis de la técnica basándose en simulaciones
con NS-2 con el objetivo de cuantificar los beneficios y problemas obtenidos a través
del uso de divacks (el autor acuña este término como un diminutivo de ACK dividido).
Como resultado de sus análisis, Arcia (2009) propone el uso de los divacks durante
los primeros RTT del slow start, para inducir la transmisión de una gran cantidad
de paquetes de datos en esta etapa. Esto podrı́a ser utilizado en la recuperación de
conexiones TCP luego de un timeout 1 , para la compensación de la cwnd luego de una
pérdida aleatoria, un handover
2
o simplemente para mejorar la transmisión al inicio
de la conexión y aprovechar más rápidamente el ancho de banda disponible en la red.
El comportamiento de los algoritmos de control de la congestión TCP ante
la presencia de divacks fue originalmente descrito por Savage et al. (1999), su
investigación estaba enfocada en exponer las vulnerabilidades que presentaba TCP
ante un receptor malintencionado que, aprovechándose de éstas, podrı́a controlar el
ritmo de envı́o de datos del emisor. Ellos describen por primera vez la división de ACKs
1
Si el emisor no recibe ningún ACK dentro del intervalo de tiempo esperado (timeout), los datos
son retransmitidos y cwnd se reinicia en 1 SMSS.
2
En redes inalámbricas, handover es un mecanismo que permite a un receptor TCP móvil cambiar
de una red a otra cuando la calidad del enlace es insuficiente.
1.1 Antecedentes
3
como un ataque capaz de inducir en un emisor TCP correctamente implementado, un
envı́o agresivo de datos.
Dado el comportamiento del emisor TCP ante el uso de la técnica de división de
ACKs, se han hecho ya varias propuestas con el fin de mejorar el rendimiento de TCP
en redes inalámbricas:
Jin et al. (1999) , motivados por las significativas pérdidas de paquetes que existen
en las redes inalámbricas debido a las altas tazas de errores de bits, proponen una forma
de mejorar la respuesta de TCP en esta situación. En su propuesta, cuando la estación
base detecta pérdidas, divide los ACKs entrantes en varios y los envia al host fijo (en
una red cableada). El host fijo al recibir muchos paquetes de reconocimiento (ACK),
incrementa rápidamente el tamaño de la cwnd, con lo que se aumenta la velocidad de
recuperación de TCP. Mediante la medición por simulación, los autores comprueban
que TCP muestra un mejor rendimiento utilizando esta técnica que sin ella.
Matsushita et al. (2005), por su parte utilizan la técnica de division de ACKs para
mejorar el rendimiento de TCP durante un handover vertical (handover entre redes
de tipo diferente). Cuando el nodo móvil calcula el ancho de banda de la nueva red,
controlando el ritmo de envı́o de ACKs, puede ajustar rápidamente su cwnd a este
nuevo ancho de banda, mejorando su rendimiento. Sus conclusiones también están
basadas en los resultados obtenidos a través de simulaciones.
Para hacer frente a la caı́da de la cwnd debido a pérdidas inalámbricas aleatorias
en redes cableadas-inalámbricas asimétricas (mayor ancho de banda de bajada que de
subida de datos), Hasegawa et al. (2007) proponen un método en el que resaltan tres
aspectos: el primero es un mecanismo para diferenciar una pérdida inalámbrica de una
pérdida por congestión, de manera de solo usar los divacks cuando una pérdida aleatoria
ocurre; el segundo es el control del intervalo de duración de generación de divacks, para
esto el nodo móvil guarda un estimado del tamaño de la cwnd del emisor, cuando
la pérdida aleatoria ocurre, el receptor envı́a tantos divacks como sea necesario para
recuperar la cwnd que el emisor tenı́a antes que la pérdida ocurriera; por ultimo el
control de la tasa de envı́o de divacks, ya que el envı́o de divack aumenta la carga en
el enlace de subida de datos, se hace un chequeo de la cola de datos de subida (del
1.2 Definición del Problema
4
receptor al emisor). Cuando llega un paquete de datos, se revisa esta cola, si está vacı́a
se aumenta la tasa de envı́o en r = r +1 (donde r es el número de divacks a ser
transmitido), sino, se reduce r por el número de paquetes en la cola esperando a ser
transmitidos. Este método busca adaptar el envı́o de divacks al ancho de banda de
subida disponible en la red.
1.2.
Definición del Problema
TCP fue diseñado para tratar con la congestión en la red. Cuando TCP detecta
que existe congestión en la red, aminora bruscamente el ritmo de transmisión de
datos reduciendo la ventana de congestión (cwnd ), con la cual controla la cantidad
de paquetes que se pueden enviar sin haber recibido un ACK. Luego prueba
cautelosamente el nivel de congestión en la red enviando una cantidad mayor de datos
cada vez, para evitar saturar de nuevo la red.
El problema de este comportamiento de TCP se presenta cuando ocurren eventos
como la pérdida aleatoria de paquetes o handovers, comunes en redes 802.11, donde
TCP reacciona, equivocadamente, como lo harı́a ante la presencia de congestión,
reduciendo abruptamente el tamaño de la cwnd y probando lentamente el nivel de
saturación de la red, aun cuando sabemos que hay suficiente ancho de banda disponible
ya que la reducción de la cwnd no fue provocada por la congestión.
1.3.
Justificación
Utilizando la ténica de divacks podemos luego del primer RTT3 (Round Trip Time)
enviar una ráfaga de ACKs tal que aumentemos de forma inmediata la cwnd al tamaño
que, dependiendo de la congestión estimada, asumamos como óptimo. De esta manera
aprovechamos todo el ancho de banda disponible desde el comienzo de la conexión. Este
ajuste rápido de la cwnd tiene especial utilidad para la adaptación y la recuperación
de la ventana de congestión (cwnd ) luego de una pérdida aleatoria, un handover o un
3
Round-Trip Time o tiempo de ida y vuelta, es el tiempo estimado que tarda un paquete en llegar
al receptor y su ACK al emisor.
1.3 Justificación
5
Figura 1.1: Crecimiento de la cwnd en slow start mediante el uso de divacks.
timeout, de esta manera, mediante el uso de la técnica de divacks se puede recuperar
la velocidad de transmisión de datos rápidamente.
Con la intención de clarificar el efecto del uso de divacks, se presenta en la Figura
1.1 el comportamiento teórico de la ventana de congestión (cwnd ) durante la etapa slow
start, donde se compara con el comportamiento normal (1 ACK por paquete recibido).
En slow start la ventana de congestion (cwnd ) se actualiza en SMSS bytes por cada
ACK que reconoce nuevos datos (Allman et al., 2009), siguiendo este comportamiento
se puede notar el crecimiento acelerado de la cwnd que se logra con el uso de divacks
(en este caso 4 divacks por paquete recibido), tan solo en el tercer RTT la ventana de
congestión es de 250 SMSS bytes en contraste con el escenario normal en el que tan
solo serı́a de 16 SMSS bytes.
Es un hecho que la fuerte presencia de TCP en la Internet y por la tanto su muy
difundido uso, dificulta aplicar cualquier cambio en él, por esta razón TCP no se adapta
bien a algunas tecnologı́as de transmisión de información. Haciendo uso de la técnica
de divacks, se mejora el aprovechamiento del ancho de banda disponible en una red, ası́,
se propone esta técnica para mejorar el rendimiento de TCP bajo ciertas condiciones.
1.4 Objetivos
1.4.
1.4.1.
6
Objetivos
Objetivo general
Implementar la técnica de división de ACKs (divacks) en un kernel linux para
comprobar su viabilidad en redes reales.
1.4.2.
Objetivos especı́ficos
Estudiar el efecto del envı́o de divacks sobre la cwnd, en la implementación de
TCP de un kernel linux.
Desarrollar algoritmos que permitan utilizar la técnica de división de ACKs en
el kernel Linux para aprovechar el ancho de banda disponible en redes de acceso.
Comprobar la mejora en uso del ancho de banda disponible en una red mediante
la observación de experimentos.
1.5.
Metodologı́a de trabajo
Debido a la naturaleza de este proyecto se utilizará como guı́a el Método
Experimental que se basa en el conocimiento empı́rico y la experimentación. Según
este método este proyecto se realizará en las siguientes etapas:
Identificación del Problema: Ante la ocurrencia de ciertos eventos, TCP no
reacciona correctamente, con lo cual desperdicia ancho de banda y castiga el
ritmo de transferencia de datos. Hasta donde se sabe, actualmente no existe una
implementación que trate de corregir este problema.
Formulación de la Hipótesis: Dividiendo los ACKs en el receptor (sin perder la
semántica de TCP), se podrı́an enviar varios ACKs (divacks) por cada paquete
de datos. Esta propiedad permitirı́a controlar el ritmo de envı́o de divacks en el
receptor TCP aumentando considerablemente y a voluntad del receptor la tasa
de envı́o de datos en el emisor. Ası́, serı́a posible recuperarse rápidamente de una
caı́da abrupta de la cwnd bajo ciertas condiciones.
1.6 Alcance del Proyecto
7
Prueba de Hipótesis: La experimentación se realizará de la siguiente manera: Se
montará una red simple de dos nodos modificados para utilizar la técnica de
divacks. Se realizarán las pruebas en esta red, variando ciertas condiciones y se
tomarán los datos usando el programa Wireshark, que permite examinar datos
de una red en vivo.
Resultados: Basándose en los datos obtenidos en la fase de Prueba de Hipótesis, se
podrá concluir sobre la posible utilidad de aplicar la técnica de divacks, ası́ como
las ventajas y desventajas que presenta esta técnica.
1.6.
Alcance del Proyecto
Diseñar e implementar los algoritmos necesarios para utilizar la técnica de división
de ACKs en un kernel linux. Realizar las pruebas necesarias para comprobar la utilidad
y funcionamiento de la técnica de división de ACKs.
1.7.
Estructura del Documento
Este documento se estructura de la siguiente forma:
Capı́tulo 1. Introducción. Describe los conceptos manejados en el proyecto.
Se definen los antecedentes que son la base para solucionar el problema, ası́ como
también, el planteamiento del problema, la justificación y los objetivos, el alcance del
proyecto y la metodologı́a para su desarrollo.
Capı́tulo 2. Marco teórico. Contiene los fundamentos teóricos necesarios para el
entendimiento y comprensión del proyecto.
Capı́tulo 3. Desarrollo de la técnica. Este capı́tulo se refiere al desarrollo del
algoritmo que implementa la técnica de divacks, las variables a ser tomadas en cuenta
y la descripción de su funcionamiento.
1.7 Estructura del Documento
8
Capı́tulo 4. Implementación de la técnica. Comprende la implementación del
algoritmo en lenguaje C en un kernel Linux, se mostrarán los archivos utilizados y
modificados, y se describirá paso a paso cómo se implementará la técnica de divacks
en el kernel.
Capı́tulo 5. Pruebas. Se refiere a la fase de las pruebas de la técnica de divacks,
aquı́ se describirán los escenarios utilizados, las especificaciones de las pruebas y los
resultados obtenidos en cada una.
Capı́tulo 6. Conclusiones y recomendaciones. Se describen las conclusiones
generales basadas en el análisis de los resultados obtenidos en la experimentación,
y se plantean algunas recomendaciones para trabajos futuros.
Capı́tulo 2
Marco Teórico
Para entender cabalmente las propuestas y los experimentos planteados en este
proyecto, es necesario tener conocimiento de algunos conceptos básicos en redes e
Internet. En este capı́tulo se mostrarán estos conceptos con el propósito de aclarar las
ideas expuestas y facilitar la comprensión del proyecto.
2.1.
Protocolo de Control de Transmisión
Abreviado TCP, es uno de las protocolos de capa transporte más utilizado hoy en
dı́a en la Internet, de hecho más del 90 % de los datos en la Internet son transportados
haciendo uso de TCP (Arcia, 2009, p. 21). TCP fue diseñado para proporcionar una
transmisión confiable, garantizando el ritmo de transmisión, el control de la congestión
y el tratamiento de la corrupción, duplicación y reordenamiento de los paquetes.
Como cualquier protocolo de la capa transporte, TCP comunica las aplicaciones de
host distintos, pero también posee ciertas caracterı́sticas que lo diferencia de otros
protocolos:
Es orientado a conexión, eso quiere decir que antes de comenzar la transmisión
de datos los hosts involucrados deben establecer un acuerdo, en el cual intercambian
y establecen los parámetros para asegurar la transferencia de datos. Esta conexión
se realiza mediante un proceso conocido como acuerdo de tres fases (three-way
2.1 Protocolo de Control de Transmisión
10
Figura 2.1: Vida de una conexión TCP
handshake): En la primera fase, el host cliente (receptor) envı́a un segmento especial
que no contiene datos (segmento SYN ) al host servidor (emisor) para hacer la petición
de inicio de la conexión. En la segunda fase, el emisor responde con un segmento
reconociendo la llegada del SYN del receptor (SYN+ACK ). Finalmente, en la última
fase, el receptor envı́a un ACK al emisor y de esta manera queda establecida la
conexión entre ambos. En este punto se han acordado sus los números de secuencia
(identificación de los paquetes) iniciales y se ha reservado espacio para los buffers y
para las variables de la conexión. Luego de esto cualquiera de los dos hosts puede
terminar su conexión mediante el envı́o de un segmento FIN y la recepción del
reconocimiento mediante un ACK, una vez que ambos hosts hacen esto, todos los
recursos son liberados. En la Figura 2.1 se muestra, utilizando diagramas de flechas,
el procedimiento para abrir y cerrar una conexión TCP.
2.1 Protocolo de Control de Transmisión
11
La siguiente caracterı́stica de TCP es su confiabilidad, esto es, TCP garantiza
que los datos serán recibidos de la misma forma como fueron enviados. TCP debe
lidiar con segmentos dañados, perdidos, duplicados o entregados fuera de orden por
la capa IP. Para garantizar el envı́o y recepción correcta de los datos, TCP asigna un
número de secuencia a cada paquete transmitido, de esta manera, cuando al receptor
llega correctamente un paquete de datos, éste envı́a un reconocimiento positivo (ACK)
para notificárselo al emisor. Si el ACK no llega en el intervalo de tiempo de espera
(RTO por sus siglas en inglés: Retransmition Timeout), el emisor asume que el paquete
se perdió, ası́ que, retransmite los datos no reconocidos y duplica el valor del RTO.
Los números de secuencia también son utilizados por el receptor para ordenar los
segmentos recibidos (que pueden llegar de forma desordenada), ası́ como para eliminar
los segmentos repetidos. Cuando el receptor detecta que un paquete ha llegado de forma
desordenada, envı́a ACKs duplicados para avisar al emisor que falta algún segmento,
de esta manera el emisor retransmite el segmento faltante y reduce la ventana de
congestión (cwnd ) para disminuir el ritmo de envı́o de datos.
Cuando hay alguna pérdida, el receptor envı́a 3 (tres) ACKs duplicados. El
emisor TCP toma estos tres ACKs como señal de que la pérdida de un paquete ha
ocurrido y utiliza el algoritmo de retransmisión rápida (fast retransmit) para enviar
el segmento perdido sin esperar a que el RTO expire. Luego que el algoritmo de
retransmisión rápida envı́a el segmento perdido, el emisor aumenta el tamaño de la
cwnd y continua enviado nuevos segmentos en una fase llamada recuperación rápida
(fast recovery) hasta la llegada de un ACK no duplicado que reconoce un nuevo
segmento (Allman et al., 2009).
Otra de las caracterı́sticas importantes de TCP es el control de flujo (flow
control ), éste es un método para lograr que un receptor “lento” pueda tratar con
un emisor “rápido” sin saturarse. El receptor TCP controla la cantidad de datos
que el emisor puede enviar mediante el envı́o de una ventana (receiver window o
rwnd ) en cada ACK, indicando el espacio disponible en el buffer de recepción, esto
permite al emisor saber cuantos segmentos puede enviar sin esperar por un nuevo
reconocimiento (ACK), éste es el mecanismo de ventana deslizante (sliding window ).
2.2 Control de la congestión: Slow Start y Congestion Avoidance
12
El receptor también puede anunciar una rwnd de tamaño 0 (cero), deteniendo la
transmisión cuando se encuentra saturado, en este momento el emisor entra en modo
de persistencia. A partir de aquı́ el emisor enviará regularmente paquetes pequeños
hasta recibir un ACK con el nuevo tamaño de la rwnd, Postel (1981) recomienda que
el envı́o de estos paquetes sea cada dos minutos.(p. 42)
El control de la congestión permite hacer un uso eficiente de la red, es
decir, realizar grandes envı́os de paquetes cuando hay ancho de banda disponible y
decrementar el ritmo de envı́o cuando se detecta congestión en la red. Para el control
de congestión, TCP también utiliza un mecanismo basado en ventana (ventana de
congestión, en inglés congestion window o cwnd ). El emisor TCP incrementará el
ritmo de envı́o de segmentos mediante el aumento del tamaño de la cwnd, cuando se
detecta congestión en la red (generalmente cuando ocurren pérdidas de paquetes), se
reduce el tamaño de la cwnd.
2.2.
Control de la congestión: Slow Start
y
Congestion Avoidance
TCP controla la cantidad de datos que entran en la red con la intención de
evitar la congestión. Para esto juegan un papel importante la ventana de congestión
(cwnd ) y la ventana anunciada (rwnd ) pues la menor entre las dos será la que regirá la
transmisión de datos.
El control de congestión es llevado a cabo por una serie de algoritmos corriendo
en el emisor, en implementaciones modernas de TCP son 4 (cuatro) estos algoritmos:
slow start, congestion avoidance, fast retransmit y fast recovery. Para este proyecto es
de fundamental importancia conocer el funcionamiento de los dos primeros. Entonces
debemos definir una nueva variable, el umbral de slow start (en inglés slow start
threshold o ssthresh), éste determina cual algoritmo utilizar en cualquier momento de
la trasmisión (slow start o congestion avoidance).
2.2 Control de la congestión: Slow Start y Congestion Avoidance
13
Figura 2.2: Comportamiento de la cwnd en slow start
2.2.1.
Algoritmo Slow Start
El algortimo slow start es utilizado cuando cwnd es menor a ssthresh,
generalmente al inicio de una transmisión o luego de recuperar una pérdida detectada
por el temporizador de retransmisión (RTO). La función de slow start consiste en
comenzar enviando un volumen de datos pequeño, que se irá aumentando hasta que
la red se sature, en cuyo caso se reducirá la tasa de envı́o para reducir la saturación.
Todo esto con el fin de medir la capacidad de la red y ası́ fijar el ssthresh.
Durante slow start la cwnd se incrementa de forma exponencial, en a lo sumo
SMSS
1
bytes por cada ACK recibido que reconoce nuevos datos. Slow start finaliza
cuando cwnd supera al ssthresh (o cuando lo alcanza) o cuando se detecta congestión
por la pérdida de algún segmento (Allman et al., 2009). En la Figura 2.2 se muestra
el crecimiento exponencial de la cwnd durante la fase de slow start.
1
Sender Maximum Segment Size, es el tamaño máximo que un segmento puede tener durante la
vida de una conexión, generalmente 1500 bytes.
2.3 Envı́o de ACKs: Delayed-ACK y divacks
14
Figura 2.3: Comportamiento de la cwnd en congestion avoidance
2.2.2.
Algoritmo Congestion Avoidance
Una vez que cwnd alcanza o supera al ssthresh, se pone en funcionamiento
congestion avoidance, el cual sigue probando la disponibilidad de la red pero de una
manera mucho más cautelosa que en slow start.
Congestion avoidance incrementa la cwnd aproximadamente en un SMSS por
RTT. Esto significa que este algoritmo prueba cautelosamente el buffer del receptor
aumentando en cada RTT un paquete más hasta detectar congestión, entonces se
actualiza el valor de la cwnd a la mitad. Si el motivo de la congestión es debido a que
el RTO expiró, se pondrá el valor de cwnd a un SMSS. En la Figura 2.3 se muestra el
crecimiento lineal de la cwnd durante la fase de congestion avoidance.
2.3.
Envı́o de ACKs: Delayed-ACK y divacks
Como se ha mostrado antes los ACKs tienen varias funciones en TCP, pero su
principal objetivo es el de informar al emisor que un segmento ha llegado al receptor
2.3 Envı́o de ACKs: Delayed-ACK y divacks
15
Cliente
Servidor
Data
1:144
A CK
1
Data
8
1449
896
449:2
A CK
2897
Figura 2.4: Envı́o de un ACK por paquete
de forma correcta y ası́ poder descartarlo de la cola de retransmisión. Según esto, por
cada paquete correctamente recibido, el receptor deberı́a enviar un ACK para informar
este evento. La Figura 2.4 es un diagrama de flechas que ejemplifica esta situación,
ası́ ante la llegada del segmento DATA 1:1448 (que contiene los bytes del 1 al 1448) el
receptor responde con el ACK 1449 para indicar que todos los bytes por debajo de este
número han sido correctamente recibidos y 1449 es el siguiente byte que espera recibir.
Cuando el emisor recibe el ACK 1449 sabe que puede eliminar todos los segmentos que
contengan los bytes menores a 1449 de la cola de retransmisión y que debe responder
con el segmento DATA 1449:2896.
2.3.1.
Delayed-ACK
Como ya se ha dicho, los ACKs son acumulativos, de esta manera cuando el
receptor envı́a un ACK significa que ha recibido todos los datos precedentes al número
de secuencia reconocido, siendo ası́, el receptor podrı́a reducir el envı́o de ACKs para
ası́ descongestionar el canal de subida de datos. El envı́o de menos de un ACK por
segmento de datos recibido se conoce como delayed-ACK (ACK retardado).
Según Branden (1989) el receptor TCP puede implementar esta técnica, pero un
2.3 Envı́o de ACKs: Delayed-ACK y divacks
16
Cliente
Servidor
:1448
Data 1
896
449:2
Data 1
ACK 2
897
344
897:4
Data 2
792
345:5
Data 4
ACK 5
793
Figura 2.5: Delayed-ACK, un ACK por cada dos paquetes
ACK no debe retrasarse demasiado (cuando mucho 0.5 segundos) y deberı́a enviarse
un ACK por al menos cada dos segmentos recibidos. (p. 96)
En la Figura 2.5 se muestra con un diagrama de flechas la interacción clienteservidor haciendo uso de delayed-ACK, en este caso un ACK cada dos paquetes
recibidos.
2.3.2.
División de reconocimientos (divacks)
Los algoritmos de control de congestión de TCP están definidos en términos de
segmentos: Durante slow start, TCP incrementa la cwnd en SMSS bytes (1 segmento)
por cada ACK recibido que reconoce un nuevo dato, y durante congestion avoidance,
la cwnd se incrementa en SMSS bytes (1 segmento) por cada RTT. Se puede sacar
provecho de esta caracterı́stica de la siguiente manera:
En lugar de enviar un único ACK por cada paquete de datos recibido, el
receptor puede enviar varios ACKs al emisor, de tal manera que cada uno de estos
ACKs reconozca una parte del paquete de datos recibido.
2.3 Envı́o de ACKs: Delayed-ACK y divacks
17
Cliente
Servidor
Data 1
:1448
ACK 4
83
RTT
ACK 9
65
ACK 1
Data 1
4 49
896
449:2
344
897:4
Data 2
7 92
345:5
Data 4
2 40
793:7
Data 5
Figura 2.6: Técnica de división de ACKs: 3 ACKs por cada paquete de datos.
Esta técnica, conocida como división de ACKs, fue estudiada por primera vez
por Savage et al. (1999). Consiste en dividir cada ACK en varios ACKs, como se
muestra en la Figura 2.6, donde cada uno reconoce una porción del paquete de datos
recibido. Cada ACK es válido ya que reconoce datos que han sido enviados y no han
sido reconocidos aún, por lo tanto, cada uno hace crecer la cwnd según el algoritmo de
control de congestión utilizado (slow start o congestion avoidance).
De ahora en adelante, en este proyecto, llamaremos divack a cada una de la
partes en las que un ACK es dividido (Arcia, 2009). Por lo tanto, a la división de
ACKs la llamaremos la técnica de divacks.
La principal consecuencia de la aplicación de la técnica de divacks es que permite
al emisor incrementar la cwnd a un ritmo mucho mayor que el usual. El número máximo
de divacks en que se podrı́a dividir un ACK serı́a en el cual cada uno reconocerı́a un
único byte del paquete de datos. Esto harı́a crecer la cwnd a un valor exageradamente
grande en pocos RTTs, sin embargo, las velocidades de transmisión están delimitadas
por otros factores como el tamaño de la rwnd, el ancho de banda disponible, entre
2.4 Aclaratoria
18
otros.
Aunque se está aumentando el número de ACKs que están circulando en el
camino hacia el emisor (el tráfico de subida), lo que podrı́a ocasionar sus pérdidas, esto
no es de mayor consideración debido a que los ACKs son acumulativos y si se pierde
alguno, al llegar el siguiente, se considerará el segmento que reconocı́a el ACK perdido,
como reconocido.
2.4.
Aclaratoria
Debido a que las transmisiones de datos tratadas en este proyecto son en una sola
dirección, esto es, un host sólo envı́a datos y el otro por tanto sólo recibe. Se utilizarán
indistintamente los términos emisor o servidor para referirse al host que envı́a datos,
y receptor o cliente para referirse al host que los recibe.
2.5.
Kernel Linux
El kernel Linux es un sistema operativo libre tipo Unix. Es usualmente utilizado
junto a las herramientas GNU como interfaz entre los dispositivos de hardware y los
programas usados por el usuario para manejar un computador. A la unión de ambas
tecnologı́as, más la inclusión de algunas otras (como entornos de escritorio e interfaces
gráficas) se le conoce como distribución GNU/Linux. Fue lanzado bajo la licencia
pública general de GNU y es desarrollado gracias a contribuciones provenientes de
colaboradores de todo el mundo, por lo que es uno de los ejemplos más notables de
software libre. La versión del kernel con la que se trabajará este proyecto es la 2.6.35.7
2.5.1.
Implementación de TCP en el kernel Linux v2.6.35.7
Todos los detalles de implementación de TCP en Linux están visibles y
explicados en su código fuente. La parte relacionada con TCP en IPv4 está en el
directorio net/ipv4/. Los archivos que son de interés para el estudio son tcp input.c
y tcp output.c.
2.5 Kernel Linux
19
tcp input.c:
Es la porción de código que maneja la recepción de los paquetes TCP
provenientes de la red. Según el estado de la conexión TCP se tratan los paquetes
entrantes. Si la conexión ya está establecida, es decir, el estado de la conexión es
TCP ESTABLISHED, el paquete es tratado por la función tcp rcv established() la
cual distingue 2 tipos de tratamiento:
Camino rápido:
• Se recibe un ACK puro en reconocimiento de los datos recientemente
enviados (no un ACK duplicado).
• Se recibe un segmento con los datos que se esperan a continuación (segmento
en orden).
Camino lento:
• Se recibe un segmento con las banderas de SYN, URG, FIN o RST activadas.
• Llega un segmento fuera de orden o un segmento retransmitido.
• Llega un mensaje indicando ventana cero (el receptor no puede recibir mas).
• Se reciben segmentos con opciones inesperadas.
Si se está en el camino rápido, la longitud del segmento se compara con la longitud de
la cabecera de un paquete TCP con el fin de distinguir si se trata de un ACK puro
(su longitud es igual a la de la cabecera) o un paquete de datos (su longitud es mayor
que la de la cabecera). Los segmentos cuya longitud es menor que la longitud de la
cabecera de un paquete TCP, se desechan.
Si es un ACK puro, es procesado por la función tcp ack() y la función
tcp data snd check() realiza la trasmisión de los datos que estaban esperando para
ser enviados cuando llegara el ACK.
Si es un paquete de datos, estos son esperados (pues estamos en el camino
rápido), entonces, si se puede, se remueve la cabecera TCP, se copia directamente
los datos en la memoria de recepción del proceso, las estadı́sticas de la conexión
son actualizadas y el número de secuencia esperado es actualizado. Si no se puede
2.5 Kernel Linux
20
copiar directamente, se almacena en el buffer hasta que pueda hacerlo. Todo esto
es completado por las funciones tcp event data rcv() y tcp data queue(). Luego
se chequea que tipo de reconocimiento es requerido para el paquete mediante
la función
tcp ack snd check(). Dicha función efectúa el llamado a la función
tcp send delayed ack() si se requiere un ACK retrasado o directamente a la función
tcp send ack() si se requiere un ACK sin retraso; estas dos últimas funciones se
especifican en tcp output.c.
Si se está en el camino lento con la función tcp sequence() se comprueba si el
paquete llegó fuera de orden, en cuyo caso afirmativo se activa el modo de QuickACK
para enviar reconocimientos lo más rápido posible. Si la bandera de RST está activa
se llama a la función tcp reset() que reinicia la conexión (cambia el estado de la
conexión a CLOSED, desactiva los temporizadores y libera el buffer del socket). Si la
bandera de SYN está activa indica un error pues se esta en el estado ESTABLISHED,
entonces se reinicia la conexión con la llamada a la función tcp reset(). Si la bandera
de URG está activa se procesa con la función tcp urg().
tcp output.c:
Es la porción de código que maneja el envı́o de los paquetes TCP a la
red. Para el estudio, la función de interés es tcp send ack() pues es la encargada
de construir y enviar los reconocimientos. Para ello, solicita un socket buffer y
asigna los valores correspondientes a este buffer. Posteriormente, se utiliza la función
tcp transmit skb() para terminar de llenar la cabecera del segmento TCP y
transmitirlo a la capa de red.
Cuando se trata del envı́o de ACKs retrasados, la función encargada de
manejarlos es tcp send delayed ack() la cual chequea y ajusta los tiempos de
transmisión y al momento de transmitir el ACK llama a la función tcp send ack()
antes mencionada. La función encargada de solicitar la conexión es tcp connect() la
cual envı́a el segmento con el bit SYN activo para solicitar establecer la conexión.
2.5 Kernel Linux
21
tcp.h:
Ubicado en la carpeta /include/linux/ contiene las estructuras de datos
necesarias para manejar el protocolo TCP en el kernel. La estructura de interés para
el estudio fue tcp sock pues es la que contiene los datos del flujo TCP.
2.5.2.
Parámetros TCP
En un sistema en ejecución, varios parámetros de TCP se pueden ver y modificar
mediante los archivos del directorio /proc, por ejemplo /proc/sys/net/ipv4/. Linux
implementa muchos algoritmos de control de congestión: BIC, CUBIC, Westwood,
Reno, H-TCP, y varios más. Desde la versión 2.6.19 se usa por omisión CUBIC con
Reno como segunda opción, por su simplicidad, para el desarrollo de este proyecto se
utilizará Reno como algoritmo de control de la congestión.
TCP Reno
Este algoritmo de control de congestión implementa una fase llamada fast
recovery (recuperación rápida). Esta implementación previene reiniciar la ventana de
congestión después de una retransmisión, por lo que evita entrar en slow start luego
de haber sufrido la pérdida de un solo paquete. En Reno se utiliza el envı́o de ACKs
duplicados para indicar que un paquete que se ha perdido. Una vez que el emisor recibe
tres ACKs duplicados, se entra en fast recovery. En esta fase, el emisor retransmite el
paquete perdido y reduce su ventana de congestión a la mitad (cwnd ), en lugar de
reiniciarla a un SMSS y entrar en slow start como lo hace Tahoe.
Durante fast recovery por cada ACK duplicado recibido, se aumenta la ventana
de congestión y se envı́a un paquete de la ventana de transmisión2 . Cuando se recibe
un ACK que reconoce datos nuevos, el emisor sale de la fase de fast recovery. Reno
representa una mejora con respecto a su antecesor Tahoe cuando se trata con la pérdida
de un solo paquete, ya que evita entrar en slow start. Sin embargo, ya que Reno puede
retransmitir sólo un paquete perdido por RTT, puede presentar problemas cuando trata
2
Ventana que contiene los segmentos a ser enviados, cuyo tamaño es siempre el mı́nimo entre la
cwnd y la rwnd.
2.6 Herramientas de medición y procesamiento de tráfico de red
22
con pérdidas de múltiples paquetes.
2.6.
Herramientas de medición y procesamiento de
tráfico de red
2.6.1.
Wireshark/Tshark
Wireshark es un analizador de protocolos de red, es decir, una herramienta
utilizada para estudiar y desarrollar protocolos y aplicaciones de red (Wikipedia, 2011).
Permite capturar en tiempo real los paquetes que transitan en una red.
Wireshark brinda múltiples opciones de filtrado y organización de la información
capturada. Permite observar, en cada paquete capturado, información de cada capa. Se
puede monitorear el estado de la red en tiempo real o analizar los datos de una traza
almacenada en disco. Wireshark es software libre, y se ejecuta sobre la mayorı́a de
sistemas operativos Unix y compatibles, incluyendo Linux, Solaris, FreeBSD, NetBSD,
OpenBSD, y Mac OS X, ası́ como en Microsoft Windows.
2.6.2.
Tcpprobe
tcp probe es un módulo que permite guardar el estado de una conexión TCP
durante la llegada de nuevos paquetes. Trabaja dentro del proceso de recepción del
kernel (tcp recv) y utiliza kprobe para ver la información TCP de los paquetes (Linux
Fundation, 2009).
Cada vez que un ACK entrante modifica la ventana de congestión (cwnd ), el
módulo tcp probe imprime una lı́nea en el archivo /proc/net/tcpprobe. Cada linea
contiene la siguiente información:
1. Tiempo de recepción del ACK, en segundos.
2. IP del servidor y puerto.
3. IP del cliente y puerto.
4. Cantidad de bytes en el paquete (longitud).
2.6 Herramientas de medición y procesamiento de tráfico de red
5. Número de secuencia del siguiente paquete a ser enviado (snd nxt).
6. Número de secuencia del último paquete no reconocido (snd una).
7. Ventana de congestión (cwnd ).
8. Umbral de slow start (ssthresh).
9. Ventana anunciada (rwnd ).
10. RTT promedio (srtt).
El siguiente es un ejemplo de un archivo generado por tcp probe:
1
3.214453400 192.168.1.104:80 1 9 2 .1 6 8 .1 . 1 0 2: 4 4 39 3 32 0 x6c4f1537
0 x6c4f043f 3 2147483647 262144 62
2
3.214744264 192.168.1.104:80 1 9 2 .1 6 8 .1 . 1 0 2: 4 4 39 3 32 0 x6c4f2087
0 x6c4f09e7 4 2147483647 260736 62
3
3.215095761 192.168.1.104:80 1 9 2 .1 6 8 .1 . 1 0 2: 4 4 39 3 32 0 x6c4f2bd7
0 x6c4f0f8f 5 2147483647 259328 62
4
3.466880456 192.168.1.104:80 1 9 2 .1 6 8 .1 . 1 0 2: 4 4 39 3 32 0 x6c4f3727
0 x6c4f1537 6 2147483647 257920 62
5
3.467196414 192.168.1.104:80 1 9 2 .1 6 8 .1 . 1 0 2: 4 4 39 3 32 0 x6c4f4277
0 x6c4f1adf 7 2147483647 260032 62
6
3.467548234 192.168.1.104:80 1 9 2 .1 6 8 .1 . 1 0 2: 4 4 39 3 32 0 x6c4f4dc7
0 x6c4f2087 8 2147483647 260032 62
7
3.469590960 192.168.1.104:80 1 9 2 .1 6 8 .1 . 1 0 2: 4 4 39 3 32 0 x6c4f5917
0 x6c4f262f 9 2147483647 260032 62
8
...
Cuadro 2.1: Archivo generado por tcp probe.
23
2.7 Conclusión
2.7.
24
Conclusión
En este capı́tulo se mostraron las caracterı́sticas relevantes de TCP y los
algoritmos principales que utiliza, como para el tratamiento de la congestión (slow
start y congestion avoidance), el inicio y fin de las conexiones (acuerdo de tres fases),
el manejo de las pérdidas de datos (fast recovery), entre otros.
Finalmente se discutió, en términos generales, sobre el kernel Linux, sobre
los archivos y funciones que serán modificadas, utilizadas y agregadas para lograr
implementar la técnica de divacks, ası́ como los parámetros TCP con los que se
trabajará y las herramientas que serán utilizadas a lo largo de este estudio.
Capı́tulo 3
Desarrollo de la técnica
A través del uso de divacks podemos aumentar el ritmo de envió de datos hacia
el receptor TCP, tan solo haciendo algunos cambios en los extremos de la conexión. En
este capı́tulo se describirá detalladamente la técnica de divacks, y se mostrará de manera
general el algoritmo que será implementado en el kernel Linux v2.6.35.7, explicando
y señalando las variables a ser tomadas en cuenta y los casos en los cuales el uso de
divacks es apropiado.
3.1.
División de ACKs
Cada segmento TCP es descrito por un campo para el número de secuencia (en
el caso de los datos) y un campo para el número de reconocimiento (en el caso de los
ACKs). El número de secuencia marca el primer byte del flujo de bytes que el emisor
está enviando al receptor en ese segmento, por lo tanto también indica la cantidad de
bytes que ya se han enviado en una conexión TCP (el número de secuencia es igual al
número de bytes que ya se han transmitido + 1). El número de reconocimiento se utiliza
para que el receptor pueda indicar al emisor cuáles bytes ha recibido correctamente,
ası́ si al receptor llega un segmento con el número de secuencia s, que contiene n bytes,
éste enviará un ACK con número de reconocimiento s+n+1 indicando que ha recibido
correctamente s+n bytes y que espera por el s+n+1. De esta manera TCP garantiza
la confiabilidad de los datos. Por otro lado, los algoritmos de control de congestión de
3.1 División de ACKs
26
TCP están definidos en términos de segmentos en lugar de bytes. El comportamiento
del control de congestión de TCP, definido en (Allman et al., 2009, p. 5), establece:
Durante slow start, TCP incrementa la cwnd a lo sumo en SMSS bytes por
cada ACK recibido que reconoce nuevos datos.
...
Durante congestion avoidance, la cwnd es incrementada aproximadamente
SMSS bytes por round-trip time (RTT).
Esta caracterı́stica de la implementación de TCP permite aumentar la velocidad
con la que crece la cwnd de la siguiente manera:
Cuando recibe un paquete de datos, el receptor TCP puede, en lugar de enviar
un ACK que lo reconozca por completo, enviar varios ACKs (divacks) al emisor, donde
cada uno reconozca una parte del paquete de datos recibido. Cada divack es válido ya
que cubre datos que fueron enviados y no han sido previamente reconocidos, por lo
tanto cada divack provoca la actualización de la cwnd.
En la Figura 3.1 se muestra un ejemplo de la técnica de divacks, donde el
receptor envı́a tres divacks por cada paquete de datos recibido. Al recibir el paquete
con número de secuencia 1 que contiene 1448 bytes, el receptor envı́a un divack
reconociendo los primeros 1446 bytes y los siguientes dos divacks señalando la llegada
de un nuevo byte cada uno. Al final, mediante el envı́o de los tres divacks se han
reconocido los 1448 bytes del paquete recibido, pero se ha actualizado el valor de la
cnwd tres veces.
El uso de la técnica de divacks ocasiona en el emisor TCP un aumento del
tamaño de la cwnd a un ritmo mucho más acelerado que el normal. El receptor puede
controlar este ritmo de crecimiento mediante la división arbitraria de los ACKs, hasta
un máximo de un divack por byte recibido. En este limite, teóricamente se harı́a crecer
la cwnd a un valor exageradamente grande en pocos RTTs, sin embargo, las velocidades
de transmisión son delimitadas también por otros factores como el tamaño de la rwnd,
el ancho de banda disponible en la red, el tamaño del buffer de transmisión, entre otros.
3.2 Descripción del Algoritmo
27
Cliente
Servidor
Data 1
:1448
ACK 1
4 47
ACK 1
4 48
ACK 1
4 49
Data 1
RTT
896
449:2
344
897:4
Data 2
7 92
345:5
Data 4
2 40
793:7
Data 5
Figura 3.1: Ejemplo de la técnica de divacks.
3.2.
Descripción del Algoritmo
Como ya se ha explicado, el objetivo esta técnica es dividir los ACKs salientes
del receptor, en los llamados divacks, de tal manera que cada uno reconozca una parte
del paquete recibido. Una manera de hacer esto es realizando un bucle en la zona del
código donde TCP forma el ACK y lo envı́a, de tal manera que en el momento de
enviar un ACK, nuestro receptor modificado envı́e tantos como se hayan especificado.
Para poder llevar a cabo este proceso se debe verificar que no se
esté interrumpiendo o alterando ningún otro mecanismo de TCP y que los divacks
enviados serán recibidos y aceptados como válidos por el emisor. Por eso existen ciertas
variables y comportamientos que deben ser tomados en cuenta.
3.2 Descripción del Algoritmo
3.2.1.
28
Variables implicadas en la formación de los divacks
Entre estas variables, la primera en ser mencionada debe ser rcv nxt, la cual
almacena el primer byte del próximo paquete de datos que se espera recibir. Cuando
se envı́a un ACK, éste tiene como número de secuencia a rcv nxt, de esta manera se
informa al emisor que todos los bytes anteriores a este número de secuencia han sido
correctamente recibidos y se desea recibir datos nuevos a partir de este byte. Por lo
tanto esta es la variable que debemos manipular para informar el reconocimiento de
cada parte del paquete recibido.
También es importante mencionar a snd nxt y snd una, que representan
respectivamente el primer byte del próximo paquete que será enviado y el primer
byte de aquellos que no han sido reconocidos aún. Estas variables se utilizan para
la validación de los ACKs, de esta manera, el número de secuencia del divack no puede
ser mayor que snd nxt porque ese paquete aún no ha sido enviado, y no puede ser
menor que snd una porque esos datos ya han sido reconocidos.
En la Figura 3.2, los números superiores e inferiores indican el byte inicial y
final de cada paquete, respectivamente. Utilizando este ejemplo, el valor de rcv nxt en
el receptor, cuando llega el último paquete enviado, deberı́a ser el mismo que snd nxt.
snd_una
1449
2897
2896
snd_nxt
4345
4344
5793
5792
7240
Segmento enviado
no reconocido
Segmento no enviado
Figura 3.2: Valores de snd nxt y snd una en el emisor.
Una última variable a tomar en cuenta es sysctl tcp divack, la cual es
implementada en este proyecto con el fin de poder controlar la cantidad de divacks
que se debe enviar en cualquier momento. Es a través de sysctl tcp divack que
se maneja el aumento o reducción del ritmo de envió de divacks, e incluso el poder
desactivarlos.
3.2 Descripción del Algoritmo
3.2.2.
29
Mecanismos afectados por los divacks
Como se ha explicado en capı́tulos anteriores, a pesar de que la función principal
de los ACKs es reconocer la correcta llegada de los datos al receptor, TCP los utiliza
también con otros objetivos. Es en estos casos donde se debe evaluar si es efectivo
enviar divacks, o si por el contrario interrumpen el proceso.
TCP es orientado a conexiones. En la segunda etapa de el acuerdo de tres
fases (three-way handshake), para el inicio de una conexión, el receptor debe enviar
un reconocimiento a un segmento SYN+ACK para establecer la conexión. Al terminar
la transmisión de datos es necesario finalizar la conexión, en esta última fase, luego
de recibir un segmento FIN, es necesario responder con un ACK para que los recursos
de la conexión puedan ser liberados. En ambos casos el ACK reconoce una petición
para cambiar el estado de la conexión, estos ACKs son llamados ACKs de control y no
reconocen datos, por este motivo no se deben enviar divacks.
En el momento de detectar algún error en la llegada de los paquetes, el receptor
utiliza los llamados dup-ACKs (ACKs duplicados) para avisarle al emisor de este error.
Cuando el emisor recibe 3 (tres) ACKs duplicados, debe reenviar el paquete solicitado
sin esperar a que el RTO expire (Allman et al., 2009). Ası́, el envió de divacks en esta
situación solo entorpecerı́a el mecanismo.
De lo descrito anteriormente concluimos que los divacks deben estar limitados a
ser enviados únicamente como respuesta a la llegada de paquetes que contienen nuevos
datos, por esta razón es importante desactivarlos en los casos donde esto no ocurra.
3.2.3.
Presentación del algoritmo
Una vez descrito el funcionamiento de los divacks, ası́ como las variables y los
mecanismos importantes, podemos finalmente mostrar de manera general el algoritmo
de formación y envı́o de los divacks.
El algoritmo mostrado en el Cuadro 3.1 toma el número de secuencia del ACK
y lo almacena en una variable (seq original) para usarlo como referencia para la
asignación del número de secuencia de cada divack. En un bucle que se repetirá tantas
3.2 Descripción del Algoritmo
30
veces como divacks se enviarán (n), se forma y envı́a cada divack. El primer divack
tendrá como número de secuencia:
seq original - n
los siguientes n-1 divacks les será asignado el número de secuencia del divack anterior
+ 1, es decir, reconocerán un nuevo byte cada vez. Finalmente, al salir del bucle, se
envı́a el full-ACK 1 que reconoce el último byte recibido y señala el siguiente byte que
se espera recibir, con el número de secuencia seq original, es decir, el número de
secuencia del ACK original.
Cabe destacar que, en el caso de que la técnica de divacks esté desactivada
(sysctl tcp divack=0), el número de secuencia del ACK no será modificado y no se
entrará en el bucle, por lo que solo se enviará el ACK que reconoce todo el paquete.
Ası́ garantizamos que al desactivar la técnica de divacks, se utiliza el envı́o normal de
un ACK por paquete de datos sin alteración.
1
Full-ACK, es un ACK o el divack que reconoce por completo el paquete recibido.
3.2 Descripción del Algoritmo
1
/* Validamos que el ACK es en respuesta a la llegada de un
paquete de datos */
2
S i ( Segmento contiene datos && Segmento no tiene errores )
entonces
3
4
/* Si es necesario enviar un ack */
5
seq_original = paquete . rcv_nxt
6
7
/* Cambiamos el numero de secuencia del ACK de tal manera
que este entre snd_nxt y snd_una */
8
paquete . rcv_nxt -= sy sctl_t cp_div ack
9
10
Repita mientras ( paquete . rcv_nxt < seq_original )
/* Formamos y enviamos el divack con el nuevo numero de
11
secuencia */
12
envio_ack ( paquete )
13
paquete . rcv_nxt ++
14
/* En este caso cada divack reconoce un byte mas que el
anterior */
15
Fin Repita mientras
16
17
/* Envio del full - ACK */
envio_ack ( paquete )
18
19
Fin S i
Cuadro 3.1: Algoritmo de divacks en el receptor TCP.
31
3.3 Conclusión
3.3.
32
Conclusión
En este capı́tulo se describió el funcionamiento detallado de la técnica de divacks
y como ésta aprovecha una vulnerabilidad que presenta TCP para aumentar el ritmo
de envı́o de datos hacia el receptor. Se mostró de manera general el algoritmo que
será implementado en el kernel Linux, haciendo énfasis en las variables TCP que se
deben tomar en cuenta para la correcta aplicación de la técnica. Igualmente se describe
porqué los divacks solo deben ser usados cuando se ha recibido un paquete de datos
correctamente y que existen mecanismos como el acuerdo de tres fases y los dupACKs, en los que el uso de divacks es perjudicial.
Capı́tulo 4
Implementación de la Técnica
En este capı́tulo se mostrará detalladamente la implementación del algoritmo en
lenguaje C en un kernel Linux v2.6.35.7, en la distribución Ubuntu 9.10. Se explicarán
los algoritmos realizados, describiendo los archivos utilizados y las modificaciones
hechas.
Además se explicarán algunas caracterı́sticas del kernel Linux que nos permitirán
realizar cambios en tiempo de ejecución para evitar compilaciones recurrentes del
kernel. Ası́ como ciertos comportamientos de la implementación de TCP que previenen
el uso de la técnica de divacks.
4.1.
Técnica de control de envı́o de divacks
Cuando se experimenta con el kernel Linux es muy común tener que modificarlo
constantemente de acuerdo a necesidades especı́ficas, y muchas veces esto implica
tener que recompilar el kernel y reiniciar el sistema. En estos casos la mejor idea es
implementar parámetros variables en lugar de constantes. Es posible en Linux modificar
parámetros del kernel en tiempo de ejecución, y una manera de hacerlo es a través
del uso de la interfaz sysctl. Muchas opciones de TCP pueden ser observadas y
modificadas dinámicamente a través de sysctl, como el algoritmo de control de la
congestión (RENO, Cubic, entre otros), el tamaño máximo de la ventana de recepción
(rwnd ), el uso del mecanismo de Conteo Apropiado de Bytes (ABC por sus siglas
4.1 Técnica de control de envı́o de divacks
34
en inglés: Appropriate Byte Counting) y muchos más. Como parte de este proyecto se
propuso crear un parámetro del kernel que permita controlar la cantidad de divacks por
paquete de datos a enviar (ası́ como desactivar el mecanismo en el caso de necesitarlo).
El nombre elegido para este parámetro es tcp divack.
tcp divack entonces permitirá controlar el envı́o de divacks recibiendo como
valor números enteros, donde:
0: Desactiva el mecanismo de envı́o de divacks, es decir, se envı́a un ACK por
paquete de datos.
1: Divide el ACK saliente en dos partes, es decir, se envı́a un divack y el full-ACK.
2: Divide el ACK saliente en tres partes, es decir, se envı́an dos divacks y el
full-ACK.
Y ası́ en adelante hasta SMSS - 1, donde que cada divack y el full-ACK
reconocerı́an un solo byte del paquete de datos.
Los accesos bajo el directorio /proc/sys describen a los parámetros de
configuración del kernel, es decir, /proc/sys es la raı́z del árbol de control del sistema.
Especı́ficamente los parámetros de la implementación de IPv4 están localizados en el
directorio (subárbol) /proc/sys/net/ipv4. Para añadir el nuevo parámetro, es necesario
modificar varios archivos del kernel.
Como cualquier variable, tcp divack debe ser declarada antes de poder ser
usada. Es en el archivo net/ipv4/tcp input.c donde tcp divack será usada, ası́ que
es en ese archivo donde debe declararse (Cuadro 4.1). Se utiliza el prefijo sysctl para
indicar que es un parámetro de control del sistema.
98
i n t sys ctl_tc p_diva ck __read_mostly ;
Cuadro 4.1: Declaración de tcp divack (net/ipv4/tcp intput.c)
El siguiente paso es modificar la estructura de control ctl table ipv4 table[]
definida en el archivo net/ipv4/sysctl net ipv4.c. En esta tabla se especifican el
‘procname’(nombre de la variable en el árbol de control del sistema), la dirección
4.1 Técnica de control de envı́o de divacks
35
de la variable que contiene el dato (‘data’), el tamaño de la variable (‘maxlen’), los
permisos que posee (‘mode’) y la función que la maneja (‘proc handler’). En este caso
(Cuadro 4.2) el ‘procname’(nombre de la variable en el directorio /proc/sys/net/ipv4)
es, como ya se habı́a expuesto, tcp divack, la variable que contiene el dato es la
ya declarada sysctl tcp divack, tiene el tamaño de un entero, para los permisos se
especı́fica que el dueño del archivo es root y que tiene permisos de lectura y escritura,
mientras que el grupo y otros solo tienen permisos de lectura (0644), y por último el
‘proc handler’se asigna a proc dointvec el cual lee y escribe valores enteros desde y
hacia el buffer de usuario.
{
493
. procname = " tcp_divack " ,
494
. data
= & sysctl_tcp_divack ,
495
. maxlen
= sizeof ( int ),
496
. mode
= 0644 ,
497
. proc_handler = proc_dointvec ,
}
498
Cuadro 4.2: ipv4 table[ ] (net/ipv4/sysctl net ipv4.c)
En el archivo include/linux/sysctl.h se definen las interfaces de control del
sistema de Linux, aquı́ se definirá el nombre sysctl a través de un enum (Cuadro 4.3).
428
NET_TCP_divack = 126;
Cuadro 4.3: Definición de nombres sysctl (include/linux/sysctl.h)
Ahora agregamos la variable en la estructura bin net ipv4 table[] del archivo
kernel/sysctl binary.c, en la cual se debe especificar la función de modificación1
(CTL INT para enteros), el nombre sysctl que acabamos de definir y el procname
(Cuadro 4.4).
1
Las funciones de modificación son las encargadas de actualizar el valor de los parámetros de
configuración del kernel.
4.2 Modificaciones en el Servidor
392
36
{ CTL_INT , NET_TCP_divack , " tcp_divack " }
Cuadro 4.4: bin net ipv4 table[ ] (kernel/sysctl binary.c)
Finalmente se agrega sysctl tcp divack (como externa) junto al resto de las
variables sysctl para TCP en el archivo include/net/tcp.h (Cuadro 4.5).
241
extern i n t sys ctl_tc p_diva ck ;
Cuadro 4.5: sysctl tcp divack (include/net/tcp.h)
4.2.
Modificaciones en el Servidor
Nuestro interés para este proyecto en el servidor es conocer el “camino del ACK”,
es decir, lo que sucede desde la llegada de un ACK (y divacks en nuestro caso), hasta
el envı́o de un nuevo paquete de datos en respuesta al ACK recibido.
En la Sección 2.5.1 se explica cómo TCP (en su implementación en Linux)
maneja la llegada de paquetes provenientes de la red una vez que una conexión entre
cliente y servidor es establecida. En la Figura 4.1 se puede observar un diagrama de
flujo con las funciones más relevantes en el proceso de envı́o de un paquete de datos.
Como ya se ha explicado, tcp ack() es la función encargada de lidiar con los
ACKs entrantes. Una vez que el ACK llega al emisor, y se validan sus campos (para
descartar ACKs viejos o inválidos), hay una última validación que determina si este
ACK hace crecer la cwnd, esto es, si el ACK reconoce datos nuevos. Esto se comprueba
en la función tcp clean rtx queue() la cual saca los paquetes reconocidos de la cola
de retransmisión y enciende una bandera (FLAG DATA ACKED) si se reconocieron datos
nuevos. En términos generales ası́ es como trabaja la función tcp clean rtx queue():
1- Toma un paquete de la cola de retransmisión y lo guarda en una estructura skb.
2- Verifica si skb→end seq > tp→snd una (para este momento tp→snd una ya ha
sido actualizado al valor de ack seq), si no es mayor quiere decir que el ACK lo
está reconociendo ası́ que se elimina de la cola de retransmisión, se enciende la
4.2 Modificaciones en el Servidor
37
1.- tcp rcv established()
1.1.- tcp ack()
1.1.1.- tcp clean rtx queue()
tcp skb pcount()
tcp tso acked()
1.1.2.- tcp cong avoid()
1.2.- tcp data snd check()
tcp push pending frames()
tcp push pending frames()
tcp write xmit()
Figura 4.1: Proceso de envı́o de datos ante la llegada de un ACK.
4.2 Modificaciones en el Servidor
38
bandera FLAG DATA ACKED y se regresa a 1 para ver si el ACK recibido reconoce
más de un paquete de datos (como en el caso de los ACKs retrasados).
2.1- Si es cierto (skb→end seq > tp→snd una), es el caso de que un paquete
TSO (TCP Segmentation Offload) no ha sido reconocido por completo
o el ACK no está reconociendo por completo este paquete (el caso
de los divacks) o nada del paquete. Para saber cual de los casos es
verifica si tcp skb pcount(skb) == 1 (entonces no es un paquete TSO)
o si tp→snd una < scb→seq (el ACK no reconoce ningún byte de este
paquete). Si alguna de las estas dos condiciones se cumple, entonces
la función termina. Si era la primera vez en entrar aquı́, la bandera
FLAG DATA ACKED no se encendió y por lo tanto la cwnd no crecerá.
2.2- Si ninguna se cumple, quiere decir que si es un paquete TSO y que el ACK
reconoce una parte. Entonces se llama a la función tcp tso acked() para
saber cuántos paquetes se reconocen.
2.2.1- tcp tso acked() haciendo uso de otras funciones va descartando las
partes del paquete TSO que son reconocidas y comparando con el MSS
(usando tcp current mss()) determina si se ha reconocido un paquete
completo de los que componen al paquete TSO.
2.2.1- En caso de que tcp tso acked() devuelva algún número mayor que
0 (cero) se enciende la bandera FLAG DATA ACKED y se regresa a 1, de lo
contrario se sale.
En la Figura 4.2 se observa como la función tcp clean rtx queue() elimina
paquetes de la cola de retransmisión cuando estos son reconocidos completamente.
Ya explicado el comportamiento de tcp clean rtx queue(), es evidente que los
divacks nunca van a encender la bandera FLAG DATA ACKED, ya que solo reconocen una
parte del paquete de datos y por lo tanto la cwnd no crecerá. Solo cuando llegue el fullACK, que reconoce el paquete de datos completo, dicho paquete será eliminado de la
cola de retransmisión, la bandera FLAG DATA ACKED será encendida y se podrá aumentar
el tamaño de la cwnd. Este mecanismo podrı́a verse como una defensa propia del kernel
Linux contra los divacks.
4.2 Modificaciones en el Servidor
39
Cliente
Cola de Retransmisión
1
1448
1449 2896
2896
4344
snd_una (ack_seq)
cwnd
1449
4
4344
5792
2897
2897 4344
5792
5
Servidor
Data
Data
1:144
1
2
Data
897:4
7240
4345
6
4
Data
5
Data
7
Data
8
Data
8
89 6
449:2
344
345:5
792
240
793:7
241:8
689:1
ACK 1
4
49
ACK 2
8
97
ACK 4
3
45
68 8
01 36
Figura 4.2: Comportamiento de la función tcp clean rtx queue().
Es por esta razón que es necesario realizar algunas modificaciones en el servidor
para eliminar dicha defensa. Una manera sencilla de hacerlo es eliminando la validación
de la bandera FLAG DATA ACKED en la función tcp ack(), de este modo cualquier ACK
(o divack ) válido, es decir, que reconozca todo o parte de un paquete de datos por
el cual se esperaba reconocimiento, activará el llamado al mecanismo de crecimiento
de la cwnd. En el Cuadro 4.6 se encuentra la modificación realizada en el servidor. El
mecanismo encargado del crecimiento de la cwnd es llamado a través de la función
tcp cong avoid(), que depende del algoritmo de control utilizado. En nuestro caso el
algoritmo de control utilizado es TCP RENO, ası́ tcp cong avoid() llama a la función
tcp reno cong avoid() (/net/ipv4/tcp cong.c) la cual, si es posible aumentar la cwnd,
entra en el algoritmo slow-start o congention avoidance (dependiendo del valor de la
cwnd).
4.3 Modificaciones en el Cliente
40
3701
...
3702
i f ( tc p_ ac k_ is _d ub io us ( sk , flag ) ) {
3703
/* Advance CWND , if state allows this . */
3704
/* Eliminamos la validacion de la bandera FLAG_DATA_ACKED
if (( flag & FLAG_DATA_ACKED ) && ! frto_cwnd && */
3705
3706
i f (! frto_cwnd && tcp _m ay _r ai se _c wn d ( sk , flag ) )
3707
tcp_cong_avoid ( sk , ack , prior_in_flight ) ;
tc p _ f a s t r e t r a n s _ a l e r t ( sk , prior_packets - tp - > packets_out ,
3708
flag ) ;
3709
3710
} else {
/* Eliminamos la validacion de la bandera FLAG_DATA_ACKED
3711
if (( flag & FLAG_DATA_ACKED ) && ! frto_cwnd ) */
3712
i f (! frto_cwnd )
3713
tcp_cong_avoid ( sk , ack , prior_in_flight ) ;
3714
3715
}
3716
...
Cuadro 4.6: Modificación
en
el
servidor
de
la
función
tcp ack()
(net/ipv4/tcp input.c).
4.3.
Modificaciones en el Cliente
Finalmente llegamos a la implementación de la técnica de divacks en el kernel
linux. El mecanismo de envı́o de ACKs se activa ante la llegada de un paquete de datos
esperado (en orden), en la Figura 4.3 se puede observar un diagrama de flujo de las
funciones más relevantes en el proceso de envı́o de un ACK.
Como se explica en la Sección 2.5.1, la función tcp rcv established()
distingue dos tipos de tratamiento: Cámino rápido (fast path) o cámino lento (slow
path). Para resumir, se está en fast path cuando se recibe un ACK puro que reconoce
un paquete de datos o un paquete de datos en orden, sino, se estará en slow path.
Esta distinción es muy importante porque como se explica la Subsección 3.2.2, solo nos
interesa activar el uso de divacks para responder la llegada de paquetes que contienen
4.3 Modificaciones en el Cliente
41
1.- tcp rcv established()
1.1.- tcp data queue()
1.2.- tcp ack snd check()
tcp ack snd check()
tcp send ack()
Figura 4.3: Mecanismo de envı́o de ACKs ante la llegada de un paquete de datos.
nuevos datos, es decir, cuando se esté en fast path. Gracias a esto podemos estar seguros
que el uso de divacks no afectará mecanismos como el envı́o de dup-ACKs o los de inicio
y final de una conexión.
Solo cuando se recibe un paquete datos en orden se llama a la función
tcp ack snd check(), que valida si se puede enviar un ACK y finalmente se llama a la
función
tcp ack snd ack(), la cual decide si enviar un ACK o esperar al envı́o de un
ACK retrasado. Esta es la función que nos interesa y donde implementaremos la técnica
de divacks, en Cuadro 4.7 podemos ver los cambios realizados para incluir el envı́o de
divacks. Lo que se hace es guardar el número de secuencia del ACK (rcv nxt original)
y en lugar de enviarlo, se le resta sysctl tcp divack y se entra en un lazo donde, si
el número de secuencia del ACK es menor a rcv nxt original, se envı́a y aumenta en
uno este número de secuencia. Al salir del lazo se habrán enviado tantos divacks como
lo indica sysctl tcp divack, donde el primer divack reconoce:
tamaño del paquete - sysctl tcp divack
bytes, luego cada divack reconoce solo un nuevo byte del paquete, hasta que finalmente
se envı́a el full-ACK para reconocer por completo el último byte recibido. Cuando la
variable sysctl tcp divack sea cero (0), no se modificará el número de secuencia del
ACK, no se entrará en el lazo y se enviará únicamente el full-ACK que reconocerá todo
el paquete de datos recibido.
4.3 Modificaciones en el Cliente
4916
42
s t a t i c void _ _ tc p _ ac k _ sn d _ ch e c k ( s t r u c t sock * sk , i n t
ofo_possible )
4917
{
4918
s t r u c t tcp_sock * tp = tcp_sk ( sk ) ;
4919
u32 rcv_nxt_original = tp - > rcv_nxt ; // Proyecto divacks
4920
4921
/* More than one full frame received ... */
4922
i f ((( tp - > rcv_nxt - tp - > rcv_wup ) > inet_csk ( sk ) -> icsk_ack .
rcv_mss &&
4923
/* ... and right edge of window advances far enough .
4924
* ( tcp_recvmsg () will send ACK otherwise ) . Or ...
4925
*/
4926
_ _ tc p _ se l e ct _ w in d o w ( sk ) >= tp - > rcv_wnd ) ||
4927
/* We ACK each frame or ... */
4928
t c p _ i n _ q u i c k a c k _ m o d e ( sk ) ||
4929
/* We have out of order data . */
4930
( ofo_possible && skb_peek (& tp - > ou t_ of _o rd er _q ue ue ) ) ) {
4931
tp - > rcv_nxt -= sysctl _tcp_ divack ;
4932
/* Proyecto divacks : Envio de divacks */
4933
while ( tp - > rcv_nxt < rcv_nxt_original ) {
4934
tcp_send_ack ( sk ) ;
4935
tp - > rcv_nxt ++;
4936
}
4937
/* Envio del full - ACK */
4938
tcp_send_ack ( sk ) ;
} else {
4939
/* Else , send delayed ack . */
4940
t c p _ s e n d _ d e l a y e d _ a c k ( sk ) ;
4941
}
4942
4943
// Proyecto divacks
}
Cuadro 4.7: Implementación de la técnica de divacks en el receptor TCP
(net/ipv4/tcp input.c)
4.4 Limitación de los divacks
4.4.
43
Limitación de los divacks
Luego de algunas pruebas realizadas, se pudo notar algunos problemas con la
implementación de la técnica de divacks. Uno de estos problemas era que no todos los
divacks que llegaban al emisor estaban haciendo efecto, esto es, no hacian crecer la
cwnd y no provocaban el envı́o de nuevos datos.
Para estudiar porqué no todos los divacks estaban haciendo efecto en el emisor
TCP, se realizaron algunas modificaciones al kernel Linux del lado del servidor, las
cuales permiten ver qué ocurre desde la llegada de un ACK (o divack ), hasta el envı́o
de un paquete de datos en respuesta a éste, a través del buffer circular del kernel.
Estas modificaciones realizadas en el kernel del emisor, ofrecen la siguiente
información:
Número de secuencia del ACK recibido.
Valor de la cwnd y del slow-start thresshold.
Si no se pudo aumentar el tamaño de la cwnd, imprime el motivo.
El espacio libre en la cwnd para enviar paquetes.
Si se pudo enviar un paquete, imprime el mensaje: “Envio exitoso”.
Si no se pudo enviar un paquete, imprime el motivo.
En el Cuadro 4.8 se muestra parte de la salida generada por una transferencia
TCP utilizando sysctl tcp divack=9. Gracias a esta información se puede ver que
existen principalmente dos eventos que interrumpen el comportamiento esperado de
los divacks. El primero ocurre, cuando habiendo espacio disponible en la cwnd para
enviar nuevos datos, no se envı́a ningún paquete, y aparece el mensaje “Salida
por tcp snd wnd test”. El segundo es observado con la aparición del mensaje
“tcp is cwnd limited”, que ocurre cuando la cwnd no crece con la llegada del ACK.
4.4 Limitación de los divacks
1
[1300.533052] Espacio libre en cwnd: 3
2
[1300.533056] S a l i d a por tcp_nagle_test
3
[1300.533071] Espacio libre en cwnd: 3
4
[1300.533085] Envio e x i t o s o
5
[1300.533087] S a l i d a por push_one
6
[1300.533091] Espacio libre en cwnd: 2
7
[1300.533099] Envio e x i t o s o
8
[1300.533101] S a l i d a por push_one
9
[1300.533105] Espacio libre en cwnd: 1
44
10
[1300.533111] Envio e x i t o s o
11
[1300.785075] DIVACK: 4223935476 cwnd: 4 thresshold : 2147483647
( normal )
12
[1300.785079] Espacio libre en cwnd: 1
13
[1300.785088] Envio e x i t o s o
14
[1300.786385] DIVACK: 4223935477 cwnd: 5 thresshold : 2147483647
( normal )
15
[1300.786388] Espacio libre en cwnd: 1
16
[1300.786395] Envio e x i t o s o
17
[1300.786856] DIVACK: 4223935478 cwnd: 6 thresshold : 2147483647
( normal )
18
[1300.786859] Espacio libre en cwnd: 1
19
[1300.786866] Envio e x i t o s o
20
[1300.787097] DIVACK: 4223935479 cwnd: 7 thresshold : 2147483647
( normal )
21
[1300.787100] Espacio libre en cwnd: 1
22
[1300.787106] Envio e x i t o s o
23
[1300.787238] DIVACK: 4223935480 cwnd: 8 thresshold : 2147483647
( normal )
24
[1300.787241] Espacio libre en cwnd: 1
25
[1300.787244] S a l i d a por tcp_snd_wnd_test
26
[1300.787402] DIVACK: 4223935481 cwnd: 9 thresshold : 2147483647
( normal )
4.4 Limitación de los divacks
27
[1300.787405] Espacio libre en cwnd: 2
28
[1300.787407] S a l i d a por tcp_snd_wnd_test
29
[1300.787520] DIVACK: 4223935482 cwnd: 10 thresshold :
2147483647 ( normal )
30
[1300.787523] Espacio libre en cwnd: 3
31
[1300.787525] S a l i d a por tcp_snd_wnd_test
32
[1300.787693] DIVACK: 4223935483 cwnd: 11 thresshold :
2147483647 ( normal )
33
[1300.787696] Espacio libre en cwnd: 4
34
[1300.787698] S a l i d a por tcp_snd_wnd_test
35
[1300.787926] DIVACK: 4223935484 cwnd: 12 thresshold :
2147483647 ( normal )
36
[1300.787929] Espacio libre en cwnd: 5
37
[1300.787931] S a l i d a por tcp_snd_wnd_test
38
[1300.788131] DIVACK: 4223935485 cwnd: 13 thresshold :
2147483647 ( normal )
39
[1300.788135] Espacio libre en cwnd: 7
40
[1300.788137] S a l i d a por tcp_snd_wnd_test
41
[1301.038140] DIVACK: 4223936924 cwnd: 13 thresshold :
2147483647 ( normal )
42
[1301.038144] t c p _i s _ cw n d _l i m it e d max_burst : 3
sysc tl_reo rderin g : 3
43
[1301.041806] DIVACK: 4223936925 cwnd: 13 thresshold :
2147483647 ( normal )
44
[1301.038447] t c p _i s _ cw n d _l i m it e d max_burst : 3
sysc tl_reo rderin g : 3
45
[1301.038451] DIVACK: 4223936926 cwnd: 13 thresshold :
2147483647 ( normal )
46
[1301.038788] t c p _i s _ cw n d _l i m it e d max_burst : 3
sysc tl_reo rderin g : 3
47
[1301.038792] DIVACK: 4223936927 cwnd: 13 thresshold :
2147483647 ( normal )
45
4.4 Limitación de los divacks
48
46
[1301.039604] t c p _i s _ cw n d _l i m it e d max_burst : 3
sysc tl_reo rderin g : 3
49
[1301.039607] DIVACK: 4223936928 cwnd: 13 thresshold :
2147483647 ( normal )
50
[1301.042007] t c p _i s _ cw n d _l i m it e d max_burst : 3
sysc tl_reo rderin g : 3
51
[1301.042008] DIVACK: 4223936929 cwnd: 14 thresshold :
2147483647 ( normal )
52
[1301.042043] Espacio libre en cwnd: 8
53
[1301.042044] Envio e x i t o s o
54
[1301.042047] Espacio libre en cwnd: 7
55
[1301.042052] Envio e x i t o s o
56
[1301.042055] S a l i d a por push_one
57
[1301.042059] Espacio libre en cwnd: 6
58
[1301.042063] S a l i d a por tcp_snd_wnd_test
59
...
Cuadro 4.8: Mensajes de depuración del kernel.
El mensaje “Salida por” se muestra cuando estamos en la función que
escribe los paquetes en la red (tcp write xmit()), pero salimos de dicha función
antes de enviar alguno. En este caso, el motivo de la salida es que falla la prueba
tcp snd wnd test(). Esta función verifica si hay espacio suficiente en la rwnd para
recibir al menos el siguiente paquete de datos.
Según Postel (1981), anunciar una rwnd muy grande puede alentar transmisiones
tan grandes que podrı́a superarse la cantidad de datos que pueden ser aceptados por el
receptor y muchos datos serı́an descartados. Por el contrario, anunciar una rwnd muy
pequeña puede restringir la transmisión de datos haciéndola muy lenta. Tratando de
evitar cualquiera de estos problemas, en la implementación de TCP de Linux, con la
llegada de nuevos paquetes de datos continuamente se aumenta el tamaño anunciado
de la rwnd hasta alcanzar el tamaño de real del buffer de recepción.
Adicionalmente Postel (1981) sugiere que ante la llegada de paquetes de datos
pequeños, se debe enviar un ACK sin actualizar la información de la rwnd. Cuando se
4.4 Limitación de los divacks
47
utiliza la técnica de divacks, únicamente el primero de una ráfaga de divacks enviada
reconoce varios bytes de datos, los demás sólo reconocen un byte nuevo cada vez, es
como si reconocieran un segmento pequeño de un byte de longitud. Por lo tanto sólo
el primer divack enviado, de los n que reconocen el paquete recibido, lleva al emisor
información actualizada de la rwnd. Esto ocasiona que el emisor crea que el receptor
no tiene la capacidad de recibir nuevos datos y restringe la transmisión de nuevos
paquetes.
Sabiendo que se van a recibir muchos datos, se puede anunciar todo el espacio
disponible en el buffer de recepción desde el inicio de la trasferencia. Para esto sólo es
necesario eliminar la restricción de la rwnd del receptor. La modificación de código se
muestra en el Cuadro 4.9.
1909
...
/* Eliminando esta validacion el receptor anuncia todo el
1910
espacio disponible en el buffer de recepcion cada vez */
/* if ( free_space > tp - > rcv_ssthresh )
1911
free_space = tp - > rcv_ssthresh ; */
1912
1913
...
Cuadro 4.9: Modificación en el cliente de la función
tcp select window()
(net/ipv4/tcp output.c)
Como
ya
se
comentó,
el
segundo
evento
que
interrumpe
el
comportamiento esperado de los divacks, se observa con la aparición del
mensaje “tcp is cwnd limited”. Este mensaje se muestra cuando la función
tcp is cwnd limited() devuelve 1 dentro de tcp reno cong avoid(), que es la
la función que implementa el algoritmo de control de congestión Reno en Linux.
tcp is cwnd limited() verifica si la transferencia de datos está limitada por la
aplicación, o por limitada por la red según el RFC 2861. Se dice que el envı́o de datos
está limitado por la red, cuando la aplicación tiene muchos datos que mandar y por
lo tanto usa, en teorı́a, toda la cwnd. Por otro lado el envı́o de datos está limitado
por la aplicación cuando, habiendo suficiente espacio en la cwnd, ésta no se utiliza por
completo debido a que hay pocos datos a enviar, este es el caso de aplicaciones como
4.4 Limitación de los divacks
48
telnet (Handley et al., 2000).
En el caso de transferencias limitadas por la aplicación no tiene sentido aumentar
el tamaño de la cwnd y de detectar esto se encarga tcp is cwnd limited(). Cuando
se utiliza la técnica de divacks, la relación entre paquetes de datos enviados y ACKs
recibidos es bastante desproporcionada, siendo la cantidad de ACKs mucho mayor. Más
aun, debido a que solo el primer divack posee información actualizada de la rwnd, lo
que evita que se puedan enviar más paquetes de datos (como ya se explicó), se tiene una
cwnd mucho mayor a la utilizada. Debido a esto, la función tcp is cwnd limited()
detecta (erróneamente) que la transferencia está limitada por la aplicación y no permite
que la cwnd crezca más.
Como se sabe que se van a transmitir muchos datos, y que definitivamente la
transferencia está limitada por la red y no por la aplicación, se puede eliminar la
validación realizada por la función tcp is cwnd limited() en el emisor, quedando el
código como se muestra en el Cuadro 4.10.
360
361
void t c p_ r e no _ c on g _ av o i d ( s t r u c t sock * sk , u32 ack , u32
in_flight )
362
{
s t r u c t tcp_sock * tp = tcp_sk ( sk ) ;
363
364
/* Eliminamos la validacion , sabemos que necesitamos enviar
365
muchos datos */
/* if (! t cp _ i s_ c w nd _ l im i t ed ( sk , in_flight ) )
366
return ; */
367
368
...
Cuadro 4.10: Modificación en el servidor de la función tcp reno cong avoid()
(net/ipv4/tcp input.c)
4.5 Compilación del kernel
4.5.
49
Compilación del kernel
Todas las pruebas realizadas en este proyecto se hicieron usando el kernel Linux
v.2.6.35.7 sobre Ubuntu 9.10, por lo tanto es necesario descargar las fuentes de dicho
kernel (http://www.kernel.org) y compilarlo en nuestros host de prueba. Una vez
realizados todos los cambios anteriormente explicados en los archivos del kernel nuevo
debemos configurarlo y compilarlo.
Por lo general algunos paquetes necesarios para la compilación del kernel no
están instalados, para asegurarse se realiza:
# Resolucion de dependiencias :
~ $ sudo aptitude install build - essential libncurses5 - dev
Se copian y descomprimen las fuentes del kernel en el directorio /usr/src y se
crea un enlace simbólico a él:
~ $ sudo cp ~/ Descargas / linux -2.6.35.7. tar . bz2 / usr / src /
~ $ cd / usr / src
/ usr / src$ sudo tar - xvf linux -2.6.35.7. tar . bz2
/ usr / src$ sudo ln -s linux linux -2.6.35.7/
Para la configuración del kernel nuevo podemos usar la configuración del kernel
actual como base.
# Buscar la configuracion del kernel actual y copiarla :
/ usr / src$ uname -r
/ usr / src$ sudo cp / boot / config - ‘ Kernel - actual ’ linux /. config
Ahora ejecutamos uno de los menú de configuración gráfica del kernel:
/ usr / src$ cd linux
/ usr / src / linux$ sudo make menuconfig
En esta interfaz activar TCP RENO como algoritmo de control de congestión
por omisión, en la Figura 4.4 se muestra la ruta en la interfaz gráfica donde se modifica
4.5 Compilación del kernel
50
Networking support
Networking options
TCP: advanced congestion control
Default TCP congestion control
Figura 4.4: Ruta para activar algoritmo de control de congestión por omisión.
Figura 4.5: Captura de pantalla menuconfig: Selección del algoritmo de control de
congestión.
este campo. En la Figura 4.5 se muestra una captura de pantalla del menú de elección
del algoritmo de congestión por omisión. Esta modificación debe hacerse en el host
servidor.
4.5 Compilación del kernel
51
Finalmente se muestran los pasos para la compilación del kernel:
# Compilacion del kernel ( - jn para usar varios procesadores ,
donde n : numero de precesadores + 1) :
/ usr / src$ sudo make - j3
# Instalacion de los modulos :
/ usr / src$ sudo make modules_install - j3
# Agregamos la imagen generada por la compilacion en el
directorio / boot
/ usr / src$ sudo make install
# Generacion de archivos de arranque
/ usr / src$ sudo update - initramfs -c -k 2.6.35.7
# Los modulos quedaran instalados en / lib / modules /2.6.35.7 , el
kernel y el archivo initrd en / boot / vmlinuz2 .6.35.7 y / boot /
initrd . img -2.6.35.7 respectivamente .
# Actualizacion del grub :
/ usr / src$ sudo update - grub
# $ Reiniciar el equipo
~ $ sudo reboot
Cuadro 4.11: Compilación del kernel.
4.6 Conclusión
4.6.
52
Conclusión
En este capı́tulo se mostraron detalladamente las modificaciones necesarias para
implementar la técnica de divacks en el kernel Linux v.2.6.35.7, en la distribución
Ubuntu 9.10. Desde la descarga de las fuentes del kernel, las modificaciones realizadas
y la configuración y compilación de dicho kernel.
Se explicó el uso de una variable de configuración del kernel para controlar el
envı́o de divacks y se mostró, paso a paso, como agregarla dentro del kernel.
Se demostró la protección que Linux posee contra los divacks y la manera
de desactivarla para la correcta utilización de la técnica de divacks. Finalmente, se
mostró el código que implementa la técnica de divacks y la importancia de su ubicación
en fast path para no interrumpir otros mecanismos que utilizan el envı́o de ACKs y
que el uso de divacks puede afectar.
Capı́tulo 5
Pruebas
Con el objetivo de observar el efecto del uso de divacks en el rendimiento de
TCP, se realizaron diversas pruebas sobre distintas configuraciones y caracterı́sticas de
red. Buscando estudiar el comportamiento de la ventana de congestión (cwnd ) ante
el uso de diferentes cantidades de divacks por paquete de datos y el impacto de este
comportamiento sobre el rendimiento de las transferencias. Finalmente, se buscaba con
estas pruebas comprobar si realmente se pueden obtener mejores tiempos de descarga
a través del uso de la técnica de divacks y bajo qué condiciones la esta técnica expone
los mejores resultados.
En este capı́tulo se mostrarán las pruebas más importantes realizadas,
describiendo de forma detallada su montaje y los resultados obtenidos.
5.1.
Configuración de las pruebas
Antes de empezar cualquier prueba es necesario configurar el cliente y el servidor
de la siguiente manera:
Asegurar que en el servidor está definido Reno como algoritmo de control de
congestión por omisión. Sino definirlo de la siguiente manera:
~ $ sudo sysctl -w net . ipv4 . t c p _ c o n g e s t i o n _ c o n t r o l = reno
5.2 Pruebas sobre red cableada
54
Definir en ‘1’ el parámetro tcp no metrics save. TCP en Linux generalmente
almacena el valor del último umbral Slow Start (ssthresh) medido. Con el
parámetro tcp no metrics save se evita que se guarden valores de conexiones
TCP anteriores, de tal manera que cada prueba se realice bajo las mismas
condiciones y sean independientes unas de otras.
~ $ sudo sysctl -w net . ipv4 . t c p _n o _ me t r ic s _ sa v e =1
En el cliente dependiendo de la prueba, se cambia el valor del parámetro
tcp divack (que por omisión es ‘0’). Llamaremos n al número de divacks
utilizados, esto es, n divacks + full-ACK. De esta manera n podrı́a tener valores
desde 0 (sin divacks), es decir, el envı́o normal de un ACK por paquete de datos.
Hasta SMSS - 1, es decir, que cada divack y el full-ACK reconocerı́an solo un
byte del paquete de datos.
~ $ sudo sysctl -w net . ipv4 . tcp_divack = n
5.2.
Pruebas sobre red cableada
Las primeras pruebas realizadas tienen como objetivo comprobar si realmente
se están enviando n divacks por cada paquete de datos recibido. También determinar
cuándo se envı́a cada divacks para descartar los casos en los que se interrumpe algún
mecanismo que dependa del envı́o normal de ACKs, este es el caso del acuerdo de
tres fases (three-way handshake) para el inicio de la conexión, el envı́o de ACKs
duplicados (dupacks) para alertar pérdidas de paquetes de datos o en el caso de cierre
de la conexión.
Cliente
Servidor
DATA
ACKs
Figura 5.1: Topologı́a simple Cliente-Servidor.
5.2 Pruebas sobre red cableada
55
Se utilizó la topologı́a mostrada en la Figura 5.1, la cual corresponde a
una topologı́a LAN (Local Area Network ) Cliente-Servidor de manera que pudiese
comprobarse el comportamiento deseado de los divacks.
La Figura 5.2 es la captura de pantalla realizada a la traza de una transferencia
TCP en el programa Wireshark. En ella podemos observar proceso de inicio de la
conexión (three-way handshake): El cliente (192.168.1.100) hace la petición de inicio
de conexión enviando un segmento SYN al servidor (192.168.1.103), éste responde
aceptando la conexión enviando un segmento SYN+ACK, finalmente el cliente envı́a
un ACK para completar el inicio de la conexión. También es posible observar el
comportamiento normal de TCP, en este caso n=0 por lo tanto se utiliza el mecanismo
normal de envı́o de un ACK en reconocimiento de cada paquete de datos.
Three-way
Handshake
Primer
paquete
de datos
ACK
Figura 5.2: Captura de pantalla de una traza en Wireshark, sin divacks.
5.2 Pruebas sobre red cableada
56
En el Cuadro 5.1 se muestra una parte del diagrama de flechas generado con
Wireshark, donde se puede ver la parte inicial de la transferencia y el fin de la conexión.
| Time
|
|
|
|
|0 ,000
|
SYN
|
|(46909)
−−−−−−−−−−−−−−−−−−>
192.168.1.100
|
192.168.1.103
|
|
| Seq = 0 Ack = 3 0 6 7 6 0 5 8 6 6
|0 ,000
|
SYN, ACK
|
|(46909)
<−−−−−−−−−−−−−−−−−−
(80)
|
(80)
|
(80)
|
|
| Seq = 0 Ack = 1
|0 ,000
|
ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 1 Ack = 1
|0 ,000
|
PSH , ACK − Len :
|
|(46909)
−−−−−−−−−−−−−−−−−−>
|0 ,000
|
ACK
|
|(46909)
<−−−−−−−−−−−−−−−−−−
| Seq = 1 Ack = 1
110
(80)
|
(80)
|
|
| Seq = 1 Ack = 111
|0 ,001
|
ACK − Len :
|
|(46909)
<−−−−−−−−−−−−−−−−−−
| Seq = 1 Ack = 111
|0 ,001
|
ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
1448
(80)
|
(80)
|
|
| Seq = 111 Ack = 1449
|0 ,001
|
ACK − Len :
|
|(46909)
<−−−−−−−−−−−−−−−−−−
| Seq = 1449 Ack = 111
|0 ,001
|
ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
1448
(80)
|
(80)
|
|
| Seq = 111 Ack = 2897
|0 ,001
|
PSH , ACK − Len :
|
|(46909)
<−−−−−−−−−−−−−−−−−−
|0 ,001
|
ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
| Seq = 2897 Ack = 111
1448
(80)
|
(80)
|
|
| Seq = 111 Ack = 4345
|0 ,001
|
ACK − Len :
|
|(46909)
<−−−−−−−−−−−−−−−−−−
| Seq = 4345 Ack = 111
|0 ,002
|
ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
1448
(80)
|
(80)
|
|
| Seq = 111 Ack = 5793
|0 ,002
|
ACK − Len :
|
|(46909)
<−−−−−−−−−−−−−−−−−−
| Seq = 5793 Ack = 111
|0 ,002
|
ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
1448
(80)
|
(80)
|
|
| Seq = 111 Ack = 7241
|0 ,002
|
ACK − Len :
|
|(46909)
<−−−−−−−−−−−−−−−−−−
| Seq = 7241 Ack = 111
|0 ,002
|
ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
1448
(80)
|
(80)
|
|
| Seq = 111 Ack = 8689
|0 ,002
|
ACK − Len :
|
|(46909)
<−−−−−−−−−−−−−−−−−−
| Seq = 8689 Ack = 111
1448
(80)
|
(80)
|
...
|0 ,010
|
ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 111 Ack = 1 0 1 3 6 1
|0 ,010
|
PSH , ACK − Len :
|
|(46909)
<−−−−−−−−−−−−−−−−−−
|0 ,010
|
ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
| Seq = 1 0 1 3 6 1 Ack = 111
298
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
|
|0 ,010
|
FIN , ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
| Seq = 111 Ack = 1 0 1 6 5 9
|
|0 ,011
|
FIN , ACK
|
|(46909)
<−−−−−−−−−−−−−−−−−−
| Seq = 111 Ack = 1 0 1 6 5 9
|
|0 ,011
|
ACK
|
|(46909)
−−−−−−−−−−−−−−−−−−>
| Seq = 1 0 1 6 5 9 Ack = 112
|
| Seq = 112 Ack = 1 0 1 6 6 0
Cuadro 5.1: Diagrama de flechas de una transmisión TCP, sin divacks.
5.2 Pruebas sobre red cableada
57
Por otro lado, en la Figura 5.3 se muestra la captura de pantalla realizada a
la traza en el programa Wireshark de una transferencia TCP usando la técnica de
divacks. Es de hacer notar que el proceso de inicio de la conexión no ha sido afectado,
aun cuando los ACKs se están dividiendo en 10 partes (n=9), el cliente realiza sin
cambios el three-way handshake y completa el inicio de la conexión con un solo ACK.
Three-way
Handshake
Primer
paquete
de datos
Divacks
Fullack
Figura 5.3: Captura de pantalla de una traza en Wireshark.
Luego de la llegada del primer paquete de datos al cliente es posible observar el
comportamiento de TCP cuando se usa la técnica de divacks, en este caso con n=9 el
primer divack reconoce hasta el byte 1439 (longitud del paquete - n), los siguientes 8
divacks reconocen un nuevo byte cada vez, hasta que finalmente se envı́a el full-ACK
que reconoce el último byte recibido y señala el primer siguiente byte que se espera
recibir. Puede observarse que el número del full-ACK se corresponde con el número de
5.2 Pruebas sobre red cableada
58
Divacks
Fullack
Fin de la
conexión
Figura 5.4: Captura de pantalla de una traza en Wireshark (Fin de la conexión).
secuencia del siguiente paquete de datos recibido, es decir, el número que un ACK (sin
usar la técnica de divacks) deberı́a tener.
El fin de la conexión tampoco se ve afectado por el uso de los divacks. Como
se puede apreciar en la Figura 5.4, al llegar el último paquete de datos con número de
secuencia 100835, el cliente envı́a la última ráfaga de divacks. Luego se realiza la fase
de cierre de conexión (sin cambios), mediante el intercambio de paquetes FIN y ACK.
El diagrama de flechas de la transferencia TCP con el uso de divacks se muestra
en el Cuadro 5.2. En este tipo diagrama se facilita observar la división que se hace a los
ACKs salientes desde el cliente por cada paquete de datos recibido, también se puede
apreciar como los mecanismos de inicio y fin de la conexión no son alterados.
5.2 Pruebas sobre red cableada
59
| Time
|
|
|
|
|0 ,000
|
SYN
|
|(47674)
−−−−−−−−−−−−−−−−−−>
192.168.1.100
|
192.168.1.103
|
|
| Seq = 0 Ack = 1 2 8 6 4 0 6 5 0 4
|0 ,000
|
SYN, ACK
|
|(47674)
<−−−−−−−−−−−−−−−−−−
(80)
|
(80)
|
(80)
|
|
| Seq = 0 Ack = 1
|0 ,000
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 1 Ack = 1
|0 ,000
|
PSH , ACK − Len :
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|0 ,000
|
ACK
|
|(47674)
<−−−−−−−−−−−−−−−−−−
| Seq = 1 Ack = 1
110
(80)
|
(80)
|
|
| Seq = 1 Ack = 111
|0 ,001
|
ACK − Len :
|
|(47674)
<−−−−−−−−−−−−−−−−−−
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
| Seq = 1 Ack = 111
1448
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
|
| Seq = 111 Ack = 1440
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 111 Ack = 1441
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 111 Ack = 1442
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 111 Ack = 1443
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 111 Ack = 1444
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 111 Ack = 1445
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 111 Ack = 1446
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 111 Ack = 1447
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 111 Ack = 1448
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
| Seq = 111 Ack = 1449
|0 ,001
|
ACK − Len :
|
|(47674)
<−−−−−−−−−−−−−−−−−−
|0 ,001
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
| Seq = 1449 Ack = 111
1448
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
(80)
|
|
| Seq = 111 Ack = 2888
...
|0 ,010
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
|
|0 ,010
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
| Seq = 111 Ack = 1 0 1 6 5 7
|
|0 ,010
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
| Seq = 111 Ack = 1 0 1 6 5 8
|
|0 ,011
|
FIN , ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
| Seq = 111 Ack = 1 0 1 6 5 9
|
|0 ,011
|
FIN , ACK
|
|(47674)
<−−−−−−−−−−−−−−−−−−
| Seq = 111 Ack = 1 0 1 6 5 9
|
|0 ,011
|
ACK
|
|(47674)
−−−−−−−−−−−−−−−−−−>
| Seq = 1 0 1 6 5 9 Ack = 112
|
| Seq = 112 Ack = 1 0 1 6 6 0
Cuadro 5.2: Diagrama de flechas
5.2 Pruebas sobre red cableada
60
Haciendo uso del módulo tcp probe es posible capturar los cambios en la
ventana de congestión (cwnd ) en el servidor, y ası́ ver su comportamiento ante la
llegada de los divacks. En la Figura 5.5 se muestra la comparación del crecimiento de
la cwnd cuando se activa la técnica de divacks (en este caso con n=9) con el envı́o
normal de un ACK por paquete de datos, a lo que llamamos de control (cuando n=0).
En la Figura 5.5a se muestra el comportamiento de la cwnd utilizando n=9, mientras
que en la Figura 5.5b muestra la cwnd de control.
9divacks cwnd
9divacks ssthresh
Segmentos (cwnd, ssthresh)
50
40
30
20
10
0
0
0.001
0.002
0.003
0.004
0.005
0.004
0.005
Tiempo (segundos)
(a) con divacks
control cwnd
control ssthresh
Segmentos (cwnd, ssthresh)
50
40
30
20
10
0
0
0.001
0.002
0.003
Tiempo (segundos)
(b) sin divacks
Figura 5.5: Comparación del crecimiento de la cwnd con y sin divacks.
Gracias al envı́o de divacks se logra acelerar el crecimiento de la cwnd como
puede apreciarse en la Figura 5.5. Haciendo uso de n=9 se logró obtener una cwnd =48
5.2 Pruebas sobre red cableada
61
en 4.4 ms, mientras que la cwnd de control (n=0) necesitó 5.2 ms para alcanzar un
valor de 35 MSS. Es decir, mediante el uso de divacks se obtuvo un tamaño de cwnd
mayor en menos tiempo.
Aun con la mejora en el crecimiento de la cwnd obtenido con el uso de divacks, en
la Figura 5.6 podemos observar que la llegada de los datos al receptor, tanto al receptor
con divacks (Figura 5.6a) como al de control (Figura 5.6b), no difiere mayormente.
Ambas transmisiones finalizan la recepción de datos aproximadamente en 10 ms.
120000
DATA
ACKs
Segmentos (bytes)
100000
80000
60000
40000
20000
0
0
0.002
0.004
0.006
0.008
0.01
0.008
0.01
tiempo (segundos)
(a) con divacks
120000
DATA
ACKs
Segmentos (bytes)
100000
80000
60000
40000
20000
0
0
0.002
0.004
0.006
tiempo (segundos)
(b) sin divacks
Figura 5.6: Comparación del proceso de descarga de un archivo de 99 KB con y sin
divacks.
5.2 Pruebas sobre red cableada
10500
10000
62
DATA
ACKs
Segmentos (bytes)
9500
9000
8500
8000
7500
7000
6500
6000
5500
0.0016 0.00165 0.0017 0.00175 0.0018 0.00185 0.0019 0.00195
0.002
tiempo (segundos)
Figura 5.7: Descarga de archivo de 99 KB con divacks (acercamiento).
Debido a la escala de la Figura 5.6, no es posible apreciar el envı́o de los divacks,
lo cual es el objetivo de esta prueba. En la Figura 5.7 se hace un acercamiento a lo
que ocurre en el receptor con n=9. Siguiendo el algoritmo mostrado en el Cuadro 3.1,
se puede observar como el receptor responde la llegada de cada paquete de datos con
una pequeña ráfaga de divacks (9 divacks + full-ACK ).
Para poder entender el porqué, a pesar de obtener una mayor aceleración el
crecimiento de la cwnd con n=9, no se obtienen cambios en la llegada de paquetes al
receptor, se debe observar lo que ocurre en el emisor TCP. En la Figura 5.8 se muestra
como responde el emisor a los ACKs recibidos mediante el envı́o de datos. Nuevamente
en la Figura 5.8a se muestra el comportamiento del emisor ante la llegada de divacks,
mientras que en la Figura 5.8b se muestra el emisor TCP de la transferencia de control.
Podemos ver como la pendiente de la gráfica en la Figura 5.8a es ligeramente mayor
que la de la Figura 5.8b, terminando el envı́o de datos en 5.1 ms, mientras que sin
divacks fueron necesarios 5.9 ms, aproximadamente 15 % más lento.
Vemos que el uso de la técnica de divacks mejora la velocidad de crecimiento
de la cwnd, lo que provoca un aumento en la velocidad de envı́o de datos en el emisor.
Entonces, ¿Por qué no se puede apreciar una diferencia en la llegada de datos en
el receptor? La respuesta a esta pregunta es que, al trabajar sobre una LAN, las
velocidades de transferencia de datos son altas, lo suficiente como para superar la
5.2 Pruebas sobre red cableada
120000
63
DATA
ACKs
Segmentos (bytes)
100000
80000
60000
40000
20000
0
0
0.002
0.004
0.006
0.008
0.01
0.008
0.01
Tiempo (segundos)
(a) con divacks
120000
DATA
ACKs
Segmentos (bytes)
100000
80000
60000
40000
20000
0
0
0.002
0.004
0.006
Tiempo (segundos)
(b) sin divacks
Figura 5.8: Comparación del proceso de descarga de un archivo de 99 KB con y sin
divacks, sobre una red cableada (Traza del servidor).
5.3 Pruebas sobre red cableada simulando una WAN
64
velocidad con la que el router1 puede procesar la llegada de los paquetes y su envı́o a
través del siguiente enlace. En otras palabras, la velocidad obtenida en esta prueba es
la máxima velocidad a la que el router utilizado puede retransmitir los datos recibidos.
El RTT promedio medido fue de 0.12 ms, por lo tanto el retardo de extremo a extremo
es de 0.06 ms. El tipo de cable utilizado es par trenzado categorı́a 5, lo que brinda un
ancho de banda máximo de 100 Mbps, esto da un Producto Retardo-Ancho de banda o
BDP2 (por sus siglas en inglés: Bandwidth-Delay Product) de 786.43 bytes. Sin contar
el encapsulamiento de las demás capas, y el tamaño del encabezado TCP, un segmento
puede llevar 1448 bytes de datos. Esto quiere decir que cada segmento de datos enviado
pasa más tiempo siendo transmitido por cada nodo, que siendo transportado por cada
enlace, llegando al punto que, en algún momento, el segmento vive tanto en el emisor
como en el router o tanto en el router como en el receptor al mismo tiempo.
5.3.
Pruebas sobre red cableada simulando una
WAN
El objetivo de esta prueba es aumentar el BDP de la red incrementando el
tiempo de llegada entre las ráfagas de paquetes y ası́ poder observar el impacto de
los divacks sobre una transferencia TCP cuando la capacidad de la red aumenta. Para
lograr este incremento en el tiempo de llegada de paquetes se utilizó el programa netem
para emular diferentes tiempos de retardo en la red, esto es, el tiempo que tarda un
paquete en viajar desde el origen hasta el destino. Se utilizó la topologı́a mostrada en
la Figura 5.9, donde la nube representa un terminal ejecutando netem para emular los
diferentes tiempos de retardo.
1
Router Linksys Cisco, modelo WRT160N, puertos Ethernet 100 Mbps.
BDP es el cantidad máxima de datos que pueden vivir en la red en un momento determinado, se
refiere al ancho de banda del enlace de datos (bps) multiplicado por el retardo entre dos puntos(s).
2
5.3 Pruebas sobre red cableada simulando una WAN
DATA
Cliente
65
Servidor
ACKs
Figura 5.9: Topologı́a WAN emulada con netem.
5.3.1.
Tiempo de retardo de 10 ms
La primera prueba se realizó agregando un retardo pequeño en la red. Al
utilizar 10 ms de retardo en la red se debe obtener un RTT promedio de 20 ms, lo cual
se puede observar en el Cuadro 5.3, donde se muestra la prueba de ping realizada. En
las siguientes gráficas se muestran los resultados obtenidos de las pruebas realizadas,
comparando en cada una el comportamiento de las transferencias de control con las
transferencias usando la técnica de divacks con n=9.
1
PING 192.168.1.104 (192.168.1.104) 56(84) bytes of data .
2
64 bytes from 192.168.1.104: icmp_seq =1 ttl =64 time =20.6 ms
3
64 bytes from 192.168.1.104: icmp_seq =2 ttl =64 time =20.6 ms
4
64 bytes from 192.168.1.104: icmp_seq =3 ttl =64 time =20.6 ms
5
64 bytes from 192.168.1.104: icmp_seq =4 ttl =64 time =20.6 ms
6
64 bytes from 192.168.1.104: icmp_seq =5 ttl =64 time =20.6 ms
7
64 bytes from 192.168.1.104: icmp_seq =6 ttl =64 time =20.6 ms
8
64 bytes from 192.168.1.104: icmp_seq =7 ttl =64 time =20.6 ms
9
64 bytes from 192.168.1.104: icmp_seq =8 ttl =64 time =21.4 ms
10
64 bytes from 192.168.1.104: icmp_seq =9 ttl =64 time =20.6 ms
11
64 bytes from 192.168.1.104: icmp_seq =10 ttl =64 time =20.9 ms
12
13
--- 192.168.1.104 ping statistics ---
14
10 packets transmitted , 10 received , 0 % packet loss , time 9016 ms
15
rtt min / avg / max / mdev = 2 0 . 6 0 7 / 2 0 . 7 4 2 / 2 1 . 4 0 9 / 0 . 2 5 3 ms
Cuadro 5.3: Ping realizado entre el receptor y el emisor usando un retardo de 10 ms.
5.3 Pruebas sobre red cableada simulando una WAN
50
control cwnd
control ssthresh
9divacks cwnd
9divacks ssthresh
45
Segmentos (cwnd, ssthresh)
66
40
35
30
25
20
15
10
5
0
0
0.01
0.02
0.03
0.04
0.05
0.06
0.07
Tiempo (segundos)
Figura 5.10: Comparación del crecimiento de la cwnd de control, con n=9, 20 ms de
RTT y archivo de tamaño 99 kB, sobre una red cableada.
En la Figura 5.10 se muestra la dinámica de la cwnd. Está claramente
evidenciada la mejora en la velocidad de crecimiento de la cwnd con n=9, en cada
RTT se nota el efecto de los divacks haciendo crecer la cwnd a un tamaño mayor que
la de control. Sin embargo se puede observar que la cwnd no crece proporcionalmente
a n, es decir, no todos los divacks están haciendo efecto. La cwnd, si bien crece a un
ritmo mayor, no está creciendo por cada divack recibido.
120000
control
9divacks
Segmentos (bytes)
100000
80000
60000
40000
20000
0
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
tiempo (segundos)
Figura 5.11: Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 20 ms de RTT, sobre una red cableada (Traza del cliente).
En la Figura 5.11 se puede observar el efecto de este crecimiento aumentado de
la cwnd en el rendimiento de la descarga. En cada RTT el receptor cuando se utiliza
5.3 Pruebas sobre red cableada simulando una WAN
67
n=9 recibe una ráfaga mayor de paquetes de datos que en la descarga de control.
Para facilitar la visualización del efecto de los divacks, en el Cuadro 5.1 se muestra un
resumen de las llegadas de paquetes de datos al receptor de control y cuando se utiliza
n=9.
RTT
Control (pkts) divacks(n=3) (pkts)
1
0
0
2
3
3
3
6
10
4
12
24
5
24
34
6
26
––
Total
71
71
Cuadro 5.1: Paquetes de datos recibidos en cada RTT.
Durante el primer RTT en ambas pruebas se reciben los paquetes de control,
luego de los primeros 40 ms (segundo RTT) se reciben 3 paquetes de datos, a partir de
este punto la diferencia entre la cantidad de paquetes recibidos va aumentando hasta
que finalmente el receptor cuando se utiliza n=9 termina de recibir datos en el quinto
RTT, mientras que en la descarga de control el receptor necesita un RTT adicional
para finalizar.
A pesar de la mejora en el tiempo de descarga (un RTT menos de tiempo), existe
una diferencia apreciable entre el crecimiento de la cwnd mostrado en la Figura 5.10 y
las ráfagas de segmentos apreciadas en la Figura 5.11. En la Figura 5.12 se muestra el
envı́o de datos desde el emisor TCP, se puede notar como se corresponde el envı́o de
paquete de datos con la llegada de dichos paquetes al receptor, tanto en la descarga
de control como en la de n=9. Esto significa que ya no ocurre lo que se describió en la
Sección 5.2, donde la llegada de paquetes al receptor estaba limitada por la velocidad
de transmisión del router. Sino que, no todos los divacks enviados por el receptor están
provocando en el emisor el envı́o de datos nuevos. Esto se debe a que no solamente la
cwnd dirige el crecimiento abrupto de la tasa de emisión de datos, sino que el receptor
5.3 Pruebas sobre red cableada simulando una WAN
68
puede, a través de la función de control de flujo, frenar la emisión de ráfagas de gran
tamaño (como se explica en la Sección 4.4).
120000
control
9divacks
Segmentos (bytes)
100000
80000
60000
40000
20000
0
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
Tiempo (segundos)
Figura 5.12: Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 20 ms de RTT, sobre una red cableada (Traza del
servidor).
Las siguientes gráficas muestran los resultados obtenidos al realizar la misma
prueba con un archivo de 990 kB:
Segmentos (cwnd, ssthresh)
250
control cwnd
control ssthresh
9divacks cwnd
9divacks ssthresh
200
150
100
50
0
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
Tiempo (segundos)
Figura 5.13: Comparación del crecimiento de la cwnd de control, con n=9, 20 ms de
RTT y archivo de tamaño 990 kB, sobre una red cableada.
5.3 Pruebas sobre red cableada simulando una WAN
1.2e+06
69
control
9divacks
Segmentos (bytes)
1e+06
800000
600000
400000
200000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
tiempo (segundos)
Figura 5.14: Comparación del proceso de descarga de un archivo de 990 KB de
control, con n=9 y con 20 ms de RTT, sobre una red cableada (Traza
del cliente).
1.2e+06
control
9divacks
Segmentos (bytes)
1e+06
800000
600000
400000
200000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
Tiempo (segundos)
Figura 5.15: Comparación del proceso de descarga de un archivo de 990 KB de
control, con n=9 y con 20 ms de RTT, sobre una red cableada (Traza
del servidor).
5.3 Pruebas sobre red cableada simulando una WAN
70
Como se puede observar en las gráficas anteriores, los resultados se corresponden
con los ya descritos para el archivo de 99 kB. Existe un aumento en la tasa de
crecimiento de la cwnd usando n=9, lo que provoca en el emisor un envı́o mayor, aunque
limitado (Sección 4.4), de paquetes de datos, para finalmente terminar la transferencia
del archivo en un RTT menos de tiempo.
5.3.2.
Tiempos mayores de retardo
Con el objetivo de observar el efecto de la aplicación de la técnica de divacks
sobre redes con tiempos de retardo mayores, es decir, redes donde la capacidad de
datos es mayor debido a su mayor BDP. Se simularon (utilizando el programa netem)
tiempos de retardo de 25 ms y 40 ms, para realizar las transferencias de archivos de
tamaño 99 kB.
Tiempo de Retardo de 25 ms:
1
PING 192.168.1.104 (192.168.1.104) 56(84) bytes of data .
2
64 bytes from 192.168.1.104: icmp_seq =1 ttl =64 time =50.6 ms
3
64 bytes from 192.168.1.104: icmp_seq =2 ttl =64 time =50.6 ms
4
64 bytes from 192.168.1.104: icmp_seq =3 ttl =64 time =50.6 ms
5
64 bytes from 192.168.1.104: icmp_seq =4 ttl =64 time =50.6 ms
6
64 bytes from 192.168.1.104: icmp_seq =5 ttl =64 time =50.6 ms
7
64 bytes from 192.168.1.104: icmp_seq =6 ttl =64 time =50.6 ms
8
64 bytes from 192.168.1.104: icmp_seq =7 ttl =64 time =51.0 ms
9
64 bytes from 192.168.1.104: icmp_seq =8 ttl =64 time =51.3 ms
10
64 bytes from 192.168.1.104: icmp_seq =9 ttl =64 time =53.7 ms
11
64 bytes from 192.168.1.104: icmp_seq =10 ttl =64 time =51.1 ms
12
13
--- 192.168.1.104 ping statistics ---
14
10 packets transmitted , 10 received , 0 % packet loss , time 9015 ms
15
rtt min / avg / max / mdev = 5 0 . 6 4 7 / 5 1 . 1 3 2 / 5 3 . 7 8 5 / 0 . 9 1 9 ms
Cuadro 5.4: Ping realizado entre el receptor y el emisor usando un retardo de 25 ms.
5.3 Pruebas sobre red cableada simulando una WAN
50
control cwnd
control ssthresh
9divacks cwnd
9divacks ssthresh
45
Segmentos (cwnd, ssthresh)
71
40
35
30
25
20
15
10
5
0
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
Tiempo (segundos)
Figura 5.16: Comparación del crecimiento de la cwnd de control, con n=9, 50 ms de
RTT y archivo de tamaño 99 kB, sobre una red cableada.
120000
control
9divacks
Segmentos (bytes)
100000
80000
60000
40000
20000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
tiempo (segundos)
Figura 5.17: Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 50 ms de RTT, sobre una red cableada (Traza del cliente).
5.3 Pruebas sobre red cableada simulando una WAN
120000
72
control
9divacks
Segmentos (bytes)
100000
80000
60000
40000
20000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
Tiempo (segundos)
Figura 5.18: Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 50 ms de RTT, sobre una red cableada (Traza del
servidor).
Tiempo de Retardo de 40 ms:
1
PING 192.168.1.104 (192.168.1.104) 56(84) bytes of data .
2
64 bytes from 192.168.1.104: icmp_seq =1 ttl =64 time =83.0 ms
3
64 bytes from 192.168.1.104: icmp_seq =2 ttl =64 time =80.6 ms
4
64 bytes from 192.168.1.104: icmp_seq =3 ttl =64 time =80.6 ms
5
64 bytes from 192.168.1.104: icmp_seq =4 ttl =64 time =80.6 ms
6
64 bytes from 192.168.1.104: icmp_seq =5 ttl =64 time =80.6 ms
7
64 bytes from 192.168.1.104: icmp_seq =6 ttl =64 time =80.6 ms
8
64 bytes from 192.168.1.104: icmp_seq =7 ttl =64 time =80.6 ms
9
64 bytes from 192.168.1.104: icmp_seq =8 ttl =64 time =80.6 ms
10
64 bytes from 192.168.1.104: icmp_seq =9 ttl =64 time =80.6 ms
11
64 bytes from 192.168.1.104: icmp_seq =10 ttl =64 time =81.5 ms
12
13
--- 192.168.1.104 ping statistics ---
14
10 packets transmitted , 10 received , 0 % packet loss , time 9006 ms
15
rtt min / avg / max / mdev = 8 0 . 6 4 0 / 8 0 . 9 6 9 / 8 3 . 0 2 1 / 0 . 8 0 5 ms
Cuadro 5.5: Ping realizado entre el receptor y el emisor usando un retardo de 40 ms.
5.3 Pruebas sobre red cableada simulando una WAN
50
control cwnd
control ssthresh
9divacks cwnd
9divacks ssthresh
45
Segmentos (cwnd, ssthresh)
73
40
35
30
25
20
15
10
5
0
0
0.05
0.1
0.15
0.2
0.25
Tiempo (segundos)
Figura 5.19: Comparación del crecimiento de la cwnd de control, con n=9, 80 ms de
RTT y archivo de tamaño 99 kB, sobre una red cableada.
120000
control
9divacks
Segmentos (bytes)
100000
80000
60000
40000
20000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
tiempo (segundos)
Figura 5.20: Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 80 ms de RTT, sobre una red cableada (Traza del cliente).
5.3 Pruebas sobre red cableada simulando una WAN
120000
74
control
9divacks
Segmentos (bytes)
100000
80000
60000
40000
20000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
Tiempo (segundos)
Figura 5.21: Comparación del proceso de descarga de un archivo de 99 KB de control,
con n=9 y con 80 ms de RTT, sobre una red cableada (Traza del
servidor).
Resultados:
Los resultados de las pruebas utilizando tiempos de retardos mayores se
mantuvieron similares a los resultados obtenidos en la Subsección 5.3.1, utilizando la
técnica de divacks se produce un aumento en la tasa de crecimiento de la cwnd, debido a
esto, el emisor envı́a una mayor cantidad de paquetes de datos, lo que permite finalizar
la transferencia del archivo en un RTT menos de tiempo. Lo que significa que, a mayor
retardo en la red, mayor será el tiempo ahorrado utilizando divacks.
En las siguientes gráficas se muestran el rendimiento y el tiempo promedio de
descarga obtenido en las pruebas para los diferentes tiempos de retardo, comparando
las descargas de control y usando n=9. Debido a la magnitud del error, casi inapreciable
en las gráficas, éste fue omitido.
A medida que el retardo de la red es mayor, el tiempo de descargar también lo
es (por lo tanto el rendimiento disminuye) y la diferencia entre el tiempo de descarga
de control y de n=9 crece. Para todas las pruebas realizadas, se obtuvieron mejores
resultados utilizando la técnica de divacks. Obteniendo tiempos de descarga reducidos
(en promedio un RTT menos) con respecto a las descarga de control y por lo tanto
logrando un mejor rendimiento de las transferencias.
5.3 Pruebas sobre red cableada simulando una WAN
75
8000
9divacks
control
Rendimiento (KBytes/sec)
7000
6000
5000
4000
3000
2000
1000
0
10
15
20
25
30
35
40
Retardo (ms)
Figura 5.22: Comparación del rendimiento de descarga de un archivo de 99 kb, con
diferentes tiempos de retardo, en una red cableada.
0.5
0.45
9divacks
control
Tiempo de descarga (s)
0.4
0.35
0.3
0.25
0.2
0.15
0.1
0.05
0
10
25
40
Retardo (ms)
Figura 5.23: Comparación del tiempo de descarga de un archivo de 99 kb, con
diferentes tiempos de retardo, en una red cableada.
5.3 Pruebas sobre red cableada simulando una WAN
76
35000
9divacks
control
Rendimiento (KBytes/sec)
30000
25000
20000
15000
10000
5000
0
10
15
20
25
30
35
40
Retardo (ms)
Figura 5.24: Comparación del rendimiento de descarga de un archivo de 990 kb, con
diferentes tiempos de retardo, en una red cableada.
1
0.9
9divacks
control
Tiempo de descarga (s)
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
10
25
40
Retardo (ms)
Figura 5.25: Comparación del tiempo de descarga de un archivo de 990 kb, con
diferentes tiempos de retardo, en una red cableada.
5.4 Pruebas sobre red Inalámbrica
5.4.
77
Pruebas sobre red Inalámbrica
El objetivo de estas pruebas es observar finalmente el efecto de la técnica
de divacks sobre transmisiones TCP en una red inalámbrica, tomando en cuenta
los resultados de las pruebas mostradas en las secciones anteriores. Se aplicaron las
modificaciones descritas en Sección 4.4, para evitar limitaciones en el crecimiento de la
cwnd y anunciar una rwnd fija indicando todo el espacio libre en el buffer de recepción
desde el principio de la conexión. También se utilizó el programa netem para simular
diferentes retardos de red, con el objetivo de determinar en qué situación es conveniente
usar divacks.
DATA
Cliente
Servidor
ACKs
Figura 5.26: Maqueta de red de acceso inalámbrico.
Se utilizó la topologı́a mostrada en la Figura 5.26, donde la nube representa un
terminal ejecutando netem para emular los diferentes tiempos de retardo. Se utilizaron
archivos de tamaños 99 kB, 198 kB y 990 kB, para observar el comportamiento de los
divacks en transferencias largas y cortas. Finalmente, se probaron diferentes valores
de n para observar cómo afectan a la transmisión de paquetes y a la congestión de la red.
5.4.1.
Configuración de las pruebas
Además de las configuraciones descritas en la Sección 5.1, que son necesarias
para todas las pruebas, se realizaron las siguientes configuraciones en el receptor para
aumentar el tamaño del buffer de recepción.
Asegurar que la variable tcp window scaling sea igual a ‘1’. Debido a que el
campo de la ventana anunciada en la cabecera TCP es de solo 16 bits, solo
se puede utilizar ventana de tamaño menor a 64 kbytes. Está variable permite
5.4 Pruebas sobre red Inalámbrica
78
escalar la ventana según el RFC 1323 para utilizar ventanas mayores a 64 kbytes.
Por omisión el valor de tcp window scaling es ‘1’:
~ $ sudo sysctl -w net . ipv4 . t cp_ wi nd ow _s ca li ng =1
Aumentar el tamaño del buffer de recepción a través de la variable tcp rmem. Esta
variable recibe tres enteros que representan respectivamente el tamaño mı́nimo,
por omisión y máximo del buffer de recepción. Aumentaremos cuatro veces el
valor por omisión del buffer:
~ $ sudo sysctl -w net . ipv4 . tcp_rmem = " 4096 349520 3334144 "
5.4.2.
Pruebas y resultados
En esta sección se mostrarán los resultados obtenidos. Para las pruebas se
utilizaron retardos de red de 0 ms, 10 ms, 25 ms, 40 ms y 125 ms, mediante el programa
netem. Se utilizaron archivos de tamaños 99 kB, 198 kB y 990 kB, para observar
el comportamiento de los divacks en transferencias largas y cortas. Finalmente, se
probaron diferentes valores de n para observar cómo afectan a la transmisión de
paquetes y a la congestión de la red. Se debe recordar que cuando n=0 se habla de
“prueba de control”, porque en este caso no se está usando la técnica de divacks.
Sin retardo adicional:
La primera prueba se realizó sin agregar algún retardo adicional, para observar
el efecto de las llegadas rápidas al punto de acceso inalámbrico3 (AP por sus siglas en
inglés: Access Point) de los divacks y cómo éste es capaz de retransmitir estas grandes
ráfagas de paquetes.
En las siguientes gráficas se muestran los resultados obtenidos, comparando en
cada una el comportamiento de las transferencias con valores de n de 0 (control), 3, 9
y 15.
3
Router Linksys, CISCO, modelo WRT160N, norma 802.11g (54 Mbps).
5.4 Pruebas sobre red Inalámbrica
Segmentos (cwnd, ssthresh)
1200
79
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
1000
800
600
400
200
0
0
0.05
0.1
0.15
0.2
0.25
Tiempo (segundos)
Figura 5.27: Comparación del crecimiento de la cwnd utilizando diferentes valores de
n y tamaño de archivo de 99 kB, sobre una red inalámbrica.
En la Figura 5.27 podemos observar el crecimiento de la cwnd. Se observa que
el ritmo de crecimiento de la cwnd es igual para todos los valores de n, sin embargo a
medida que el número de divacks utilizado es mayor, el tiempo en el que la cwnd sigue
creciendo también lo es. En la Figura 5.28 y Figura 5.29 se puede notar que el envı́o y
recepción de paquetes de datos termina en menos de 50 ms, y aun ası́ la cwnd sigue
creciendo (en los casos en que n > 0) por más tiempo. Además el fin de la conexión
también tarda más a medida que el número de divacks usado es mayor. Esto significa
que la llegada de ACKs al AP, supera la velocidad con la que éste puede retransmitirlos
a su destino. Entre mayor es el valor de n, mayor es la cantidad de ACKs acumulados en
el AP. Por eso, aun cuando la transmisión de paquetes de datos ya ha terminado, el AP
sigue enviando los ACKs en cola, lo que ocasiona que la cwnd siga creciendo aunque ya
no sea necesario, y que se retrase la llegada del paquete que marca el fin de la conexión.
5.4 Pruebas sobre red Inalámbrica
80
120000
Segmentos (bytes)
100000
80000
60000
40000
control
3divacks
9divacks
15divacks
20000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
tiempo (segundos)
Figura 5.28: Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del cliente).
120000
Segmentos (bytes)
100000
80000
60000
40000
control
3divacks
9divacks
15divacks
20000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
Tiempo (segundos)
Figura 5.29: Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del servidor).
5.4 Pruebas sobre red Inalámbrica
81
En las siguientes gráficas se muestran los resultados obtenidos en la descarga de
archivos de mayor tamaño. Se puede notar que los resultados son bastante parecidos
a los obtenidos por la transferencia de un archivo pequeño, sin embargo, en la
Figura 5.34 se advierte que entre mayor es la cantidad de divacks utilizados es más
lenta la llegada de datos. Esto significa que la transmisión de la gran cantidad de
ACKs está entorpeciendo la transmisión de datos:
1400
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
Segmentos (cwnd, ssthresh)
1200
1000
800
600
400
200
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
Tiempo (segundos)
Figura 5.30: Comparación crecimiento de la cwnd utilizando diferentes valores de n
y tamaño de archivo de 198 kB, sobre una red inalámbrica.
250000
Segmentos (bytes)
200000
150000
100000
control
3divacks
9divacks
15divacks
50000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
tiempo (segundos)
Figura 5.31: Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del cliente).
5.4 Pruebas sobre red Inalámbrica
82
250000
Segmentos (bytes)
200000
150000
100000
control
3divacks
9divacks
15divacks
50000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
Tiempo (segundos)
Figura 5.32: Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del servidor).
2000
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
Segmentos (cwnd, ssthresh)
1800
1600
1400
1200
1000
800
600
400
200
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
Tiempo (segundos)
Figura 5.33: Comparación del crecimiento de la cwnd utilizando diferentes valores de
n y tamaño de archivo de 990 kB, sobre una red inalámbrica.
5.4 Pruebas sobre red Inalámbrica
83
1.2e+06
Segmentos (bytes)
1e+06
800000
600000
400000
control
3divacks
9divacks
15divacks
200000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
tiempo (segundos)
Figura 5.34: Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del cliente).
1.2e+06
Segmentos (bytes)
1e+06
800000
600000
400000
control
3divacks
9divacks
15divacks
200000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
Tiempo (segundos)
Figura 5.35: Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n, sobre una red inalámbrica (Traza del servidor).
5.4 Pruebas sobre red Inalámbrica
84
Tiempo de retardo de 10 ms:
Al utilizar 10 ms de retardo en la red se debe obtener un RTT promedio de
20 ms, el cual se puede apreciar en las gráficas como el intervalo de tiempo entre
las ráfagas de paquetes de datos recibidos (en las trazas del cliente) y enviados (en
las trazas del servidor). A continuación se muestran los resultados obtenidos de las
pruebas realizadas. Se mantienen los resultados obtenidos en las pruebas anteriores,
sin embargo, los 10 ms de retardo reducen el ritmo de llegada de paquetes al AP, y
aumentan los intervalos de tiempo entre las ráfagas de paquetes. Gracias a esto se
puede apreciar el efecto de los divacks en el crecimiento de las ráfagas de paquetes
de datos y se empieza a notar la mejora en los tiempos de descarga cuando se usa la
técnica de divacks.
Segmentos (cwnd, ssthresh)
1200
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
1000
800
600
400
200
0
0
0.05
0.1
0.15
0.2
0.25
Tiempo (segundos)
Figura 5.36: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 20 ms de RTT y tamaño de archivo de 99 kB, sobre una red
inalámbrica.
5.4 Pruebas sobre red Inalámbrica
85
120000
Segmentos (bytes)
100000
80000
60000
40000
control
3divacks
9divacks
15divacks
20000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
tiempo (segundos)
Figura 5.37: Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica
(Traza del cliente).
120000
Segmentos (bytes)
100000
80000
60000
40000
control
3divacks
9divacks
15divacks
20000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
Tiempo (segundos)
Figura 5.38: Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica
(Traza del servidor).
5.4 Pruebas sobre red Inalámbrica
1400
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
1200
Segmentos (cwnd, ssthresh)
86
1000
800
600
400
200
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
Tiempo (segundos)
Figura 5.39: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 20 ms de RTT y tamaño de archivo de 198 kB, sobre una red
inalámbrica.
250000
Segmentos (bytes)
200000
150000
100000
control
3divacks
9divacks
15divacks
50000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
tiempo (segundos)
Figura 5.40: Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica (Traza
del cliente).
5.4 Pruebas sobre red Inalámbrica
87
250000
Segmentos (bytes)
200000
150000
100000
control
3divacks
9divacks
15divacks
50000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
Tiempo (segundos)
Figura 5.41: Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica (Traza
del servidor).
2000
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
Segmentos (cwnd, ssthresh)
1800
1600
1400
1200
1000
800
600
400
200
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
Tiempo (segundos)
Figura 5.42: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 20 ms de RTT y tamaño de archivo de 990 kB, sobre una red
inalámbrica.
5.4 Pruebas sobre red Inalámbrica
88
1.2e+06
Segmentos (bytes)
1e+06
800000
600000
400000
control
3divacks
9divacks
15divacks
200000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
tiempo (segundos)
Figura 5.43: Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica (Traza
del cliente).
1.2e+06
Segmentos (bytes)
1e+06
800000
600000
400000
control
3divacks
9divacks
15divacks
200000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
Tiempo (segundos)
Figura 5.44: Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 20 ms de RTT, sobre una red inalámbrica (Traza
del servidor).
5.4 Pruebas sobre red Inalámbrica
89
Tiempo de retardo de 25 ms:
Al utilizar 25 ms de retardo en la red se debe obtener un RTT promedio de 50
ms, el cual se puede apreciar en las gráficas. A continuación se muestran los resultados
obtenidos de las pruebas realizadas. Se mantienen los resultados obtenidos en las
pruebas anteriores, pero gracias a los 25 ms de retardo se puede apreciar el efecto de
los divacks en el crecimiento de las ráfagas de paquetes de datos en cada RTT de la
transmisión.
Segmentos (cwnd, ssthresh)
1200
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
1000
800
600
400
200
0
0
0.05
0.1
0.15
0.2
0.25
0.3
Tiempo (segundos)
Figura 5.45: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 50 ms de RTT y tamaño de archivo de 99 kB, sobre una red
inalámbrica.
5.4 Pruebas sobre red Inalámbrica
90
120000
Segmentos (bytes)
100000
80000
60000
40000
control
3divacks
9divacks
15divacks
20000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
tiempo (segundos)
Figura 5.46: Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica
(Traza del cliente).
RTT (s)
Control (pkts) n=3 (pkts) n=9 (pkts)
n=15 (pkts)
1
0
0
0
0
2
3
3
3
3
3
6
15
33
51
4
12
55
37
19
5
24
––
––
––
6
28
––
––
––
Total
73
73
73
73
Cuadro 5.2: Paquetes de datos recibidos en cada RTT.
5.4 Pruebas sobre red Inalámbrica
91
120000
Segmentos (bytes)
100000
80000
60000
40000
control
3divacks
9divacks
15divacks
20000
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
Tiempo (segundos)
Figura 5.47: Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica
(Traza del servidor).
1600
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
Segmentos (cwnd, ssthresh)
1400
1200
1000
800
600
400
200
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
Tiempo (segundos)
Figura 5.48: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 50 ms de RTT y tamaño de archivo de 198 kB, sobre una red
inalámbrica.
5.4 Pruebas sobre red Inalámbrica
92
250000
Segmentos (bytes)
200000
150000
100000
control
3divacks
9divacks
15divacks
50000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
tiempo (segundos)
Figura 5.49: Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica (Traza
del cliente).
RTT (s)
Control (pkts) n=3 (pkts) n=9 (pkts)
n=15 (pkts)
1
0
0
0
0
2
3
3
3
3
3
6
15
33
51
4
12
123
105
87
5
24
––
––
––
6
48
––
––
––
7
48
––
––
––
Total
141
141
141
141
Cuadro 5.3: Paquetes de datos recibidos en cada RTT.
5.4 Pruebas sobre red Inalámbrica
93
250000
Segmentos (bytes)
200000
150000
100000
control
3divacks
9divacks
15divacks
50000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
Tiempo (segundos)
Figura 5.50: Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica (Traza
del servidor).
2000
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
Segmentos (cwnd, ssthresh)
1800
1600
1400
1200
1000
800
600
400
200
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
Tiempo (segundos)
Figura 5.51: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 50 ms de RTT y tamaño de archivo de 990 kB, sobre una red
inalámbrica.
5.4 Pruebas sobre red Inalámbrica
94
1.2e+06
Segmentos (bytes)
1e+06
800000
600000
400000
control
3divacks
9divacks
15divacks
200000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
tiempo (segundos)
Figura 5.52: Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica (Traza
del cliente).
1.2e+06
Segmentos (bytes)
1e+06
800000
600000
400000
control
3divacks
9divacks
15divacks
200000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
Tiempo (segundos)
Figura 5.53: Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 50 ms de RTT, sobre una red inalámbrica (Traza
del servidor).
5.4 Pruebas sobre red Inalámbrica
95
Tiempo de retardo de 40 ms:
Al utilizar 40 ms de retardo en la red se debe obtener un RTT promedio de 80
ms, el cual se puede apreciar en las gráficas. A continuación se muestran los resultados
obtenidos de las pruebas realizadas. Se mantienen los resultados obtenidos en las
pruebas anteriores.
Segmentos (cwnd, ssthresh)
1200
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
1000
800
600
400
200
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
Tiempo (segundos)
Figura 5.54: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 80 ms de RTT y tamaño de archivo de 99 kB, sobre una red
inalámbrica.
5.4 Pruebas sobre red Inalámbrica
96
120000
Segmentos (bytes)
100000
80000
60000
40000
control
3divacks
9divacks
15divacks
20000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
tiempo (segundos)
Figura 5.55: Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica
(Traza del cliente).
RTT (s)
Control (pkts) n=3 (pkts) n=9 (pkts)
n=15 (pkts)
1
0
0
0
0
2
3
3
3
3
3
6
15
33
51
4
12
55
37
19
5
24
––
––
––
6
28
––
––
––
Total
73
73
73
73
Cuadro 5.4: Paquetes de datos recibidos en cada RTT.
5.4 Pruebas sobre red Inalámbrica
97
120000
Segmentos (bytes)
100000
80000
60000
40000
control
3divacks
9divacks
15divacks
20000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
Tiempo (segundos)
Figura 5.56: Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica
(Traza del servidor).
1800
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
Segmentos (cwnd, ssthresh)
1600
1400
1200
1000
800
600
400
200
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
Tiempo (segundos)
Figura 5.57: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 80 ms de RTT y tamaño de archivo de 198 kB, sobre una red
inalámbrica.
5.4 Pruebas sobre red Inalámbrica
98
250000
Segmentos (bytes)
200000
150000
100000
control
3divacks
9divacks
15divacks
50000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
tiempo (segundos)
Figura 5.58: Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica (Traza
del cliente).
RTT (s)
Control (pkts) n=3 (pkts) n=9 (pkts)
n=15 (pkts)
1
0
0
0
0
2
3
3
3
3
3
6
15
33
51
4
12
75
105
87
5
24
48
––
––
6
48
––
––
––
7
48
––
––
––
Total
141
141
141
141
Cuadro 5.5: Paquetes de datos recibidos en cada RTT.
5.4 Pruebas sobre red Inalámbrica
99
250000
Segmentos (bytes)
200000
150000
100000
control
3divacks
9divacks
15divacks
50000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
Tiempo (segundos)
Figura 5.59: Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica (Traza
del servidor).
Segmentos (cwnd, ssthresh)
2500
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
2000
1500
1000
500
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
Tiempo (segundos)
Figura 5.60: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 80 ms de RTT y tamaño de archivo de 990 kB, sobre una red
inalámbrica.
5.4 Pruebas sobre red Inalámbrica
100
1.2e+06
Segmentos (bytes)
1e+06
800000
600000
400000
control
3divacks
9divacks
15divacks
200000
0
0
0.2
0.4
0.6
0.8
1
1.2
tiempo (segundos)
Figura 5.61: Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica (Traza
del cliente).
1.2e+06
Segmentos (bytes)
1e+06
800000
600000
400000
control
3divacks
9divacks
15divacks
200000
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Tiempo (segundos)
Figura 5.62: Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 80 ms de RTT, sobre una red inalámbrica (Traza
del servidor).
5.4 Pruebas sobre red Inalámbrica
101
Tiempo de retardo de 125 ms:
Al utilizar 125 ms de retardo en la red se debe obtener un RTT promedio
de 250 ms, el cual se puede apreciar en las gráficas. A continuación se muestran
los resultados obtenidos de las pruebas realizadas. Con este retardo se da suficiente
tiempo al AP para recibir y retransmitir cada ráfaga de paquetes antes de la siguiente
(en el próximo RTT), esto permite apreciar claramente el efecto de los divacks en
la transferencia TCP. Por esta razón estas pruebas serán utilizadas para describir
detalladamente los resultados obtenidos mediante la aplicación de la técnica de divacks.
En la Figura 5.63 se muestra la dinámica de la cwnd. Está claramente
evidenciada la mejora en la velocidad de crecimiento de la cwnd a medida que se
envı́an más divacks, esto es, cuando el valor de n es mayor. En cada RTT se nota el
efecto de los divacks haciendo crecer la cwnd a un tamaño mayor. Se observa como
todos los divacks están haciendo efecto en la cwnd, haciéndola crecer proporcionalmente
a la cantidad de divacks enviados.
Segmentos (cwnd, ssthresh)
1200
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
1000
800
600
400
200
0
0
0.2
0.4
0.6
0.8
1
1.2
Tiempo (segundos)
Figura 5.63: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 250 ms de RTT y tamaño de archivo de 99 kB, sobre una red
inalámbrica.
5.4 Pruebas sobre red Inalámbrica
102
120000
Segmentos (bytes)
100000
80000
60000
40000
control
3divacks
9divacks
15divacks
20000
0
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
tiempo (segundos)
Figura 5.64: Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del cliente).
En la Figura 5.64 se puede observar el efecto de este crecimiento aumentado de
la cwnd en el rendimiento de la descarga de un archivo de tamaño 99 kB. En cada RTT
las ráfagas de paquetes de datos recibidos son mayores cuando se utilizan valores más
grandes de n. Para facilitar la visualización del efecto de los divacks, en el Cuadro 5.6
se muestra un resumen de las llegadas de paquetes de datos al receptor.
RTT (s)
Control (pkts) n=3 (pkts) n=9 (pkts)
n=15 (pkts)
1
0
0
0
0
2
3
3
3
3
3
6
15
33
51
4
12
55
37
19
5
24
––
––
––
6
28
––
––
––
Total
73
73
73
73
Cuadro 5.6: Paquetes de datos recibidos en cada RTT.
Durante el primer RTT se reciben los paquetes de control. Luego de los primeros
0.5 segundos (segundo RTT), el receptor recibe 3 paquetes de datos en todas las
5.4 Pruebas sobre red Inalámbrica
103
120000
Segmentos (bytes)
100000
80000
60000
40000
control
3divacks
9divacks
15divacks
20000
0
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
Tiempo (segundos)
Figura 5.65: Comparación del proceso de descarga de un archivo de 99 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del servidor).
pruebas. A partir de este punto, la diferencia entre la cantidad de paquetes recibidos
por el receptor está bastante marcada, el receptor en la prueba de control recibe, en el
tercer RTT (0.75 segundos), 6 paquetes de datos, mientras que en las pruebas con n=3,
n=9 y n=15, recibe 15, 33 y 51 paquetes de datos respectivamente. En el cuarto RTT (1
segundo), el receptor en las pruebas con n=3, n=9 y n=15, recibe los paquetes de datos
restantes para finalizar las transmisión de datos, mientras que en la prueba de control
el receptor necesita dos RTT adicionales para finalizar la descarga. Obteniéndose ası́,
aproximadamente un 50 % de ahorro de tiempo de descarga para el archivo de 99 kB.
En la Figura 5.65 se muestra el envı́o de datos desde el emisor TCP. Su
comportamiento se corresponde con la llegada de paquetes de datos al receptor. Esto
significa que el AP no está siendo saturado con la llegada de paquetes, es decir, que
estamos viendo el comportamiento normal de una transmisión TCP con el uso de
divacks.
A continuación se muestran los resultados de la descarga de un archivo de
tamaño 198 kB, el doble de la prueba anterior, para observar el comportamiento de los
divacks a medida que la cantidad de datos a transmitir es mayor.
En la Figura 5.66 se muestra la dinámica de la cwnd. El resultado, al igual que
en el caso anterior, es que entre mayor es el valor de n, mayor es la tasa de crecimiento
5.4 Pruebas sobre red Inalámbrica
2000
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
1800
Segmentos (cwnd, ssthresh)
104
1600
1400
1200
1000
800
600
400
200
0
0
0.2
0.4
0.6
0.8
1
1.2
1.4
Tiempo (segundos)
Figura 5.66: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 250 ms de RTT y tamaño de archivo de 198 kB, sobre una red
inalámbrica.
de la cwnd.
En la Figura 5.67 se muestra la llegada de paquetes de datos al receptor. Se
observa el efecto del ritmo acelerado de crecimiento de la cwnd en el rendimiento de
la descarga del un archivo. En cada RTT las ráfagas de paquetes de datos recibidos
son mayores cuando se utilizan valores más grandes de n. Para facilitar la visualización
del efecto de los divacks, en el Cuadro 5.7 se muestra un resumen de las llegadas de
paquetes de datos al receptor.
5.4 Pruebas sobre red Inalámbrica
105
250000
Segmentos (bytes)
200000
150000
100000
control
3divacks
9divacks
15divacks
50000
0
0
0.5
1
1.5
2
2.5
tiempo (segundos)
Figura 5.67: Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del cliente).
Durante el primer RTT el receptor recibe los paquetes de control. Luego de
los primeros 0.5 segundos (segundo RTT), el receptor en todas las pruebas recibe 3
paquetes de datos. A partir de este punto, la diferencia entre la cantidad de paquetes
recibidos por cada prueba está bastante marcada, en el tercer RTT (0.75 segundos)
el receptor en la prueba de control recibe 6 paquetes de datos, mientras que en las
pruebas con n=3, n=9 y n=15, recibe 15, 33 y 51 paquetes de datos respectivamente.
En el cuarto RTT (1 segundo), el receptor en la prueba de control recibe 12 paquetes
de datos y en la prueba con n=3 recibe 75, mientras que en las pruebas con n=9 y
n=15, el receptor recibe los paquetes restantes para finalizar su transmisión de datos, en
una ráfaga de 105 y 87 paquetes respectivamente. En el quinto RTT (1,25 segundos)
el receptor en la prueba con n=3 recibe los 48 paquetes restantes para finalizar la
descarga, mientras que en la prueba de control se necesitan dos RTT adicionales para
finalizar.
Para la descarga de un archivo de tamaño 198 kB, se obtuvo un ahorro de 2
RTT usando n=3, y 3 RTT usando n=9 y n=15, con respecto a la descarga de control.
Esto supone una reducción de hasta un 57 % del tiempo de descarga utilizando divacks.
En la Figura 5.68 se muestra el envı́o de datos desde el emisor TCP. Al igual
que en el caso anterior, su comportamiento se corresponde con la llegada de paquetes
5.4 Pruebas sobre red Inalámbrica
RTT (s)
106
Control (pkts) n=3 (pkts) n=9 (pkts)
n=15 (pkts)
1
0
0
0
0
2
3
3
3
3
3
6
15
33
51
4
12
75
105
87
5
24
48
––
––
6
48
––
––
––
7
48
––
––
––
Total
141
141
141
141
Cuadro 5.7: Paquetes de datos recibidos en cada RTT.
250000
Segmentos (bytes)
200000
150000
100000
control
3divacks
9divacks
15divacks
50000
0
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
Tiempo (segundos)
Figura 5.68: Comparación del proceso de descarga de un archivo de 198 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del servidor).
5.4 Pruebas sobre red Inalámbrica
107
de datos al receptor. Por lo tanto el AP no está siendo saturado con la llegada de
paquetes.
Finalmente se muestran los resultados de la descarga de un archivo de tamaño
990 kB, para observar el comportamiento de los divacks en transferencias largas. En la
Figura 5.69 se muestra la dinámica de la cwnd. El resultado es el mismo, entre mayor es
el valor de n, mayor es la tasa de crecimiento de la cwnd. Sin embargo, se observa que
el tiempo de crecimiento de la cwnd utilizando n=9 se prolonga más que los demás.
Esto se debe, como vimos en las pruebas con retardos de red pequeños, a que el AP se
está demorando en reenviar los divacks recibidos.
4000
control cwnd
3divacks cwnd
9divacks cwnd
15divacks cwnd
control ssthresh
Segmentos (cwnd, ssthresh)
3500
3000
2500
2000
1500
1000
500
0
0
0.5
1
1.5
2
2.5
Tiempo (segundos)
Figura 5.69: Comparación del crecimiento de la cwnd utilizando diferentes valores
de n, 250 ms de RTT y tamaño de archivo de 990 kB, sobre una red
inalámbrica.
En la Figura 5.70 se muestra la llegada de paquetes de datos al receptor. Se
observa el efecto del ritmo acelerado de crecimiento de la cwnd en el rendimiento
de la descarga del un archivo. Sin embargo, en las gráficas de descarga con n=3
y n=9 no se puede demarcar las ráfagas de paquetes recibidas en cada RTT. Esto
quiere decir que el AP está recibiendo muchos más paquetes de datos de los que puede
reenviar, o recordando que estamos trabajando en una de red 802.11, donde el medio
es compartido, el flujo excesivo de divacks compite con los paquetes de datos en la
contención por el medio, lo que retrasa el envı́o de datos, como lo demuestra Arcia
(2009).
5.4 Pruebas sobre red Inalámbrica
1.2e+06
control
3divacks
9divacks
15divacks
1e+06
Segmentos (bytes)
108
800000
600000
400000
200000
0
0
0.5
1
1.5
2
2.5
3
tiempo (segundos)
Figura 5.70: Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del cliente).
Es posible, sin embargo, comparar la recepción de paquetes del receptor en la
descarga con n=15 y la de control. Luego haber recibido los paquetes de control y la
primera llegada de 3 paquetes de datos, el receptor en la prueba de control recibe 6
paquetes en el tercer RTT (0.75 segundos), mientras que el receptor en la prueba con
n=15 recibe 51 paquetes de datos. A partir del cuarto RTT (1 segundo), el receptor en
la prueba con n=15 empieza a recibir todos los datos restantes de forma continua, es
decir, que está utilizando todo el ancho de banda disponible, terminando la descarga
en 1.325 segundos. Mientras que el receptor en la prueba de control le toma todavı́a
6 RTT adicionales para finalizar la descarga en 2.663 segundos, más del doble que lo
que tomo la prueba con n=15.
5.4 Pruebas sobre red Inalámbrica
1.2e+06
control
3divacks
9divacks
15divacks
1e+06
Segmentos (bytes)
109
800000
600000
400000
200000
0
0
0.5
1
1.5
2
2.5
3
Tiempo (segundos)
Figura 5.71: Comparación del proceso de descarga de un archivo de 990 kB utilizando
diferentes valores de n y 250 ms de RTT, sobre una red inalámbrica
(Traza del servidor).
Gracias a la gráfica del envı́o de datos del emisor, en la Figura 5.71, se confirman
que el emisor está enviando sin problemas los paquetes de datos en respuesta de los
ACKs entrantes, entonces el retardo en la recepción de paquetes en el cliente se produce
en el enlace inalámbrico de nuestra red. En el Tabla 5.8, se resume el envı́o de paquetes
en el servidor por cada RTT, para facilitar la comparación con los distintos valores de
n.
Al empezar la conexión se envı́an los paquetes de control. Luego de los primeros
0.25 segundos (transcurso del segundo RTT), el emisor envı́a 3 paquetes de datos en
todas las pruebas. A partir de este punto, se observa la diferencia entre la cantidad
de paquetes enviados en cada prueba, en el transcurso del tercer RTT (0.5 segundos),
el emisor transmite 6 paquetes de datos en la prueba de control, 15 en la prueba con
n=3, 33 en la prueba con n=9 y 51 en la prueba con n=15. En el transcurso del cuarto
RTT (0.75 segundos), envı́a en la prueba de control 12 paquetes de datos, en la prueba
con n=3 y con n=9 envı́a 75 y 363 paquetes de datos respectivamente, mientras que
en la prueba con n=15 envı́a 673 paquetes, finalizando la transmisión de datos. En el
transcurso del quinto RTT (1,25 segundos) el emisor transmite 24, 364 y 328 paquetes
de datos en la prueba de control, la de n=3 y la de n=9 respectivamente, finalizando la
transmisión de datos para esta última. En el transcurso del sexto RTT (1.25 segundos),
5.4 Pruebas sobre red Inalámbrica
RTT (s)
110
Control (pkts) n=3 (pkts) n=9 (pkts)
n=15 (pkts)
1
0
0
0
0
2
3
3
3
3
3
6
15
33
51
4
12
75
363
673
5
24
364
328
––
6
48
270
––
––
7
96
––
––
––
4
147
––
––
––
5
238
––
––
––
6
152
––
––
––
Total
727
727
727
727
Cuadro 5.8: Paquetes de datos recibidos en cada RTT.
envı́a 48 paquetes en la prueba de control y los restantes 270 paquetes en la prueba
con n=3.
Para terminar de enviar los datos al receptor en la prueba de control, al emisor
TCP le toma 4 RTT adicionales.
Con esta prueba queda demostrado que el uso de divacks proporciona una gran
ventaja aun en transmisiones largas, sin embargo debe tenerse cuidado con la cantidad
de divacks que se utilizan. Debido al medio compartido que el enlace inalámbrico
representa, los paquetes de datos disputan el derecho a ser transmitidos con los divacks.
Por lo tanto el uso de una cantidad excesiva de divacks puede entorpecer la transmisión
de datos.
Resultados:
En las siguientes gráficas se resumen los resultados obtenidos en las pruebas
realizadas. Se muestra el rendimiento y el tiempo promedio obtenido en las pruebas
para los diferentes tiempos de retardo, con distintos valores de n y tres los tamaños de
archivo.
5.4 Pruebas sobre red Inalámbrica
111
En términos generales, en las pruebas de descarga para los tres tamaños de
archivos se obtuvieron mejores resultados con el uso de la técnica de divacks, que sin
ella. Se puede observar en las gráficas que a medida que el retardo de la red es más
grande, la mejora en el rendimiento de la transferencia es mucho mayor. Para el caso
de un retardo de 125 ms (el mayor con el que se hicieron pruebas), se obtuvieron
reducciones de los tiempos promedio de descarga de 49,3 % para archivos de tamaño
99 kB, 58,6 % para archivos de tamaño 198 kB y hasta 64,9 % para archivos de tamaño
990 kB.
Para redes con retardos muy pequeños, los divacks no proporcionan mucha
ventaja, llegando incluso hasta entorpecer la transferencia de datos. Sin embargo, el
rendimiento de la transferencia no se ve afectado muy notablemente. Como podemos ver
en las gráficas, mediante el uso de divacks los tiempos de descarga siempre estuvieron
por debajo de los tiempos de descarga de control, excepto cuando no se utilizó ningún
retardo adicional, pero incluso en esos casos el aumento en el tiempo de descarga es
muy pequeño.
Por último se puede notar que entre mayor es el número de divacks utilizado,
menor es el tiempo de descarga obtenido, y por lo tanto, más grande es el rendimiento
de la transferencia.
Rendimiento (KBytes/sec)
25000
control
3divacks
9divacks
15divacks
20000
15000
10000
5000
0
0
20
40
60
80
100
120
140
Retardo (ms)
Figura 5.72: Comparación del rendimiento de descarga de archivos de tamaño 99 kB
con diferentes tiempos de retardo.
5.4 Pruebas sobre red Inalámbrica
1.2
3divacks
9divacks
15divacks
control
1
Tiempo de descarga (s)
112
0.8
0.6
0.4
0.2
0
0
10
25
40
125
Retardo (ms)
Figura 5.73: Comparación del tiempo de descarga de archivos de tamaño 99 kB con
diferentes tiempos de retardo.
Rendimiento (KBytes/sec)
25000
control
3divacks
9divacks
15divacks
20000
15000
10000
5000
0
0
20
40
60
80
100
120
140
Retardo (ms)
Figura 5.74: Comparación del rendimiento de descarga de archivos de tamaño 198
kB con diferentes tiempos de retardo.
5.4 Pruebas sobre red Inalámbrica
1.4
3divacks
9divacks
15divacks
control
1.2
Tiempo de descarga (s)
113
1
0.8
0.6
0.4
0.2
0
0
10
25
40
125
Retardo (ms)
Figura 5.75: Comparación del tiempo de descarga de archivos de tamaño 198 kB con
diferentes tiempos de retardo.
Rendimiento (KBytes/sec)
25000
control
3divacks
9divacks
15divacks
20000
15000
10000
5000
0
0
20
40
60
80
100
120
140
Retardo (ms)
Figura 5.76: Comparación del rendimiento de descarga de archivos de tamaño 990
kB con diferentes tiempos de retardo.
5.5 Conclusión
114
2.5
Tiempo de descarga (s)
2
3divacks
9divacks
15divacks
control
1.5
1
0.5
0
0
10
25
40
125
Retardo (ms)
Figura 5.77: Comparación del tiempo de descarga de archivos de tamaño 990 kB con
diferentes tiempos de retardo.
5.5.
Conclusión
En esté capı́tulo se describió detalladamente las pruebas utilizadas para observar
y medir el comportamiento de los divacks sobre transferencias de datos TCP. Ası́ como
también comprobar que la técnica de divacks fue bien implementada en el kernel Linux
v2.6.35.7 en este proyecto.
Las pruebas realizadas lograron su objetivo, se demostró que la técnica de
divacks se implementó correctamente en el kernel Linux y que ésta no interrumpe
otros algoritmos que requieren del normal funcionamiento de los ACKs.
También se comprobó bajo qué condiciones los divacks presentan mejores
resultados, y cómo su uso mejora significativamente el rendimiento de las transmisiones
de datos aprovechando rápidamente el ancho de banda disponible en la red. A medida
que el retardo de la red es más grande, la mejora en el rendimiento de la transferencia
es mucho mayor con el uso de divacks, igualmente entre mayor es el número de divacks
utilizado, menor será el tiempo de descarga, y por lo tanto, mucho mayor el rendimiento
de la transferencia.
Capı́tulo 6
Conclusiones y Recomendaciones
A lo largo del desarrollo de este proyecto se ha discutido el funcionamiento
general de TCP y la implementación de la técnica de divacks en el sistema operativo
Linux. Ası́ como también, las pruebas realizadas para comprobar su comportamiento
en distintos escenarios.
Como es bien conocido, TCP no tiene una reacción estándar para el
aprovechamiento rápido de ancho de banda disponible. Tal es el caso que planteamos
donde se tiene un acceso a los datos del orden de los cientos de milisegundos con un
acceso 802.11. En las pruebas con este escenario de gran capacidad, la técnica de divacks
busca aprovechar rápidamente este ancho de banda desde el principio de la conexión.
En el Capı́tulo 2 se habla sobre las caracterı́sticas y algoritmos de TCP, ası́ como
una vista de su implementación en Linux enfocada en la recepción y envı́o de paquetes.
Se describen los algoritmos de control de congestión utilizados, en los que se basa
la técnica de divacks y los detalles de implementación de la técnica; por ejemplo, se
describen los cuidados al inicio y fin de una conexión, el procedimiento a seguir con los
algoritmos de control de congestión, el mecanismo de envı́o de ACKs, el manejo de las
pérdidas de paquetes y el control de flujo.
La técnica de divacks se aprovecha del doble tratamiento que TCP le da a la
información. Por un lado envı́a la data en segmentos, pero por otro la cuenta en bytes.
Esto se aprovecha para aumentar el ritmo de envı́o de datos hacia el receptor. Entonces
para enviar divacks, se reconocen paquetes de datos en varios divacks que reconocen sólo
6 Conclusiones y Recomendaciones
116
una porción de dicho paquete (sin perder la semántica de TCP), pudiendo entonces
enviarse varios ACKs por un solo paquete de datos, lo que provoca un crecimiento
acelerado de la cwnd en el emisor. En el Capı́tulo 3 se explican los fundamentos de la
técnica de divacks y se demuestra cómo es capaz de ocupar rápidamente el ancho de
banda disponible mediante el incremento del ritmo de crecimiento de la cwnd.
Para probar la efectividad de la técnica de divacks, se implementó en el kernel
Linux v2.6.35.7. En el Capı́tulo 4, se explican los detalles de la implementación, desde la
descarga de las fuentes del kernel, las modificaciones realizadas, hasta la configuración
y compilación de dicho kernel.
En el Capı́tulo 5 se muestran las pruebas realizadas para cuantificar el efecto de
la técnica de divacks en el rendimiento de TCP. Se pudo observar claramente que los
divacks incrementan la velocidad de crecimiento de la cwnd a un ritmo proporcional
al número de divacks utilizado, lo cual ha demostrado en otros trabajos ser útil para
compensar la cwnd luego de pérdidas aleatorias de paquetes, timeouts o handovers.
También, gracias a este crecimiento acelerado de la cwnd, es posible aprovechar el
ancho de banda disponible más rápidamente, traduciéndose básicamente al ahorro de
varios RTT durante la transferencia de datos. El efecto de los divacks puede ser mejor
apreciado en redes con retardos grandes; tal es el caso de las redes satelitales, que
tratan con retardos de 400 ms a 800 ms. Con los resultados obtenidos en este proyecto,
se puede prever que el tiempo de mejora estarı́a en el orden de los segundos.
Una propiedad importante encontrada durante la ejecución de las pruebas, es
que el uso de un mayor número de divacks mejora el rendimiento de la transferencia
TCP. La cwnd aumenta mucho más rápido, y aunque existen otros mecanismos que
limitan el envı́o de datos, como la ventana anunciada (rwnd ) en el receptor, o el tamaño
del buffer de envı́o en el emisor, si estos son adaptados, se pueden obtener ráfagas muy
grandes de paquetes de datos en pocos RTTs. Sin embargo, se debe tomar en cuenta
que al utilizar una gran cantidad de divacks, la transferencia puede verse entorpecida
en redes 802.11, donde el medio es compartido, ya que el flujo excesivo de divacks
compite con los paquetes de datos en la contención por el medio, lo que puede retrasar
el envı́o de datos.
6 Conclusiones y Recomendaciones
117
Recomendaciones para trabajos futuros:
Se ha demostrado que la técnica de divacks permite aprovechar rápidamente el
ancho de banda disponible en una red desde el inicio de la conexión, pero para que
el mecanismo de arranque rápido sea eficiente se propone implementar en un trabajo
futuro las siguientes propuestas:
Un mecanismo para obtener un estimado del ancho de banda disponible en la
red. Esto permitirı́a calcular la cantidad necesaria de divacks que deben enviarse
para alcanzar una cwnd suficiente para utilizarlo por completo.
Un control sobre el envı́o de divacks. La intención es que una vez alcanzada la
cwnd necesaria para ocupar el ancho de banda disponible (o por lo menos la
mitad de ésta, para no saturar la red), se detenga el envı́o de divacks.
Una interfaz sencilla que permita introducir la reducción esperada en el tiempo
de descarga de un archivo, y ésta utilice la cantidad de divacks necesaria para
lograr la reducción esperada.
Referencias
Allman, M., Paxson, V., and Blanton, E. (2009). TCP Congestion Control. Internet
Standards Track RFC 5681, IETF.
Arcia, A. (2009).
Modifications du mécanisme dácquittemen du protocole TCP :
évaluation et application aux réseaux filaires et sans fils. PhD thesis, École nationale
supérieure des télécomunications de Bretagne.
Linux
linea].
Fundation
(2009,
Recuperado
19
de
noviembre).
el
16
de
Tcpprobe,
septiembre
de
2011,
[en
de
http://www.linuxfoundation.org/collaborate/workgroups/networking/tcpprobe.
Branden, R. (1989). Requirements for internet hosts – communication layers. Internet
Standards Track RFC 1122, IETF.
Handley, M., Padhye, J., and Floyd, S. (2000). TCP congestion window validation.
Internet Standards Track RFC 2861, IETF.
Hasegawa, G., Nakata, M., and Nakano, H. (2007).
Receiver-based ACK
splitting mechanism for TCP over wired/wireless heterogeneous networks. IEICE
Transactions on Communications, E90-B(5):1132–1141.
Jacobson, V., Braden, R., and Borman, D. (1992).
TCP extensions for high
performance. Internet Standards Track RFC 1323, IETF.
Jin, K., Kim, K., and Lee, J. (1999). SPACK: Rapid recovery of the TCP performance
using split-ACK in mobile communication environments. In Proceedings of IEEE
TENCON, pages 761–764, Cheju,South Korea.
REFERENCIAS
119
Kurose, J. F. and Ross, K. W. (2004). Redes de Computadores, un enfoque descendiente
basado en Internet. PEARSON Addison-Wesley, Madrid, España, 2 edition.
Matsushita, Y., Matsuda, T., and Yamamoto, M. (2005). TCP congestion control with
ACK-pacing for vertical handover. In Proceedings of IEEE WCNC, page 1497–1502,
New Orleans.
Postel, J. (1981). Transmission Control Protocol. Internet Standards Track RFC 793,
IETF.
Savage, S., Cardwell, N., Wetherall, D., and Anderson, T. (1999). TCP congestion
control with a misbehaving receiver. ACM SIGCOMM Computer Communications
Review.
Seth, S. and Venkatesulu, M. A. (2008).
TCP-IP Architecture, Design, and
Implementation in Linux. JOHN WILEY & SONS, INC., New Jersey, USA.
Wikipedia (2010, 11 de noviembre). Linux kernel, [en linea]. Recuperado el 22 de
noviembre de 2010, de http://en.wikipedia.org/wiki/Linux kernel.
Wikipedia
[en
(2010,
linea].
21
de
agosto).
Recuperado
el
Transmission
26
de
noviembre
Control
de
Protocol,
2010,
de
http://en.wikipedia.org/wiki/Transmission Control Protocol.
Wikipedia (2011, 21 de junio). Wireshark, [en linea]. Recuperado el 16 de septiembre
de 2011, de http://es.wikipedia.org/wiki/Wireshark.
Apéndice A
Scripts utilizados para la realización
y procesamiento de las pruebas
A.1.
Script para la configuración de Netem
1
# !/ bin / bash
2
#
3
# # Calomel . org
4
# # https :// calomel . org / n e t w o r k _ l o s s _ e m u l a t i o n . html
5
#
6
# Usage : ./ netem . sh $argument
7
8
9
i f [ $ # - eq 0 ]
then
10
echo " "
11
echo "
12
echo " - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "
13
echo " off
= clear all netem profiles "
14
echo " show
= show active profiles "
15
echo " activar | retraso | = enable netem profile with retraso
Calomel . org
ms of delay "
16
echo " "
netem . sh "
A.1 Script para la configuración de Netem
exit
17
18
fi
19
20
i f [ $1 = " off " ]
then
21
22
echo " netem profile off "
23
tc qdisc del dev eth0 root
24
tc qdisc del dev eth1 root
exit
25
26
fi
27
28
i f [ $1 = " show " ]
then
29
30
echo " show netem profile "
31
tc qdisc show dev eth0
32
tc qdisc show dev eth1
exit
33
34
fi
35
36
i f [ $1 = " activar " ]
then
37
38
tc qdisc add dev eth0 root netem delay $2ms
39
tc qdisc add dev eth1 root netem delay $2ms
exit
40
41
fi
42
43
# ### EOF #####
Cuadro A.1: netem.sh
121
A.2 Script para las pruebas de descarga del cliente
A.2.
1
Script para las pruebas de descarga del cliente
# !/ bin / bash
2
3
# uso : ./ downlink . sh
4
# Ejemplo : ./ downlink . sh
prueba
15 divacks
5
6
mkdir $1
7
cd $1
8
mkdir 70 packets
9
cd 70 packets
10
f o r i in $ ( seq 20) ; do
tcpdump -i wlan0 -n port 80 - vvv -w traza$i 2 >&1 >>
11
throughput . txt &
12
#
tcpdump -i eth0 -n port 80 - vvv -w traza$i 2 >&1 >>
throughput . txt &
13
tdid = $ !
14
sleep 1
15
wget http : // 1 9 2. 1 6 8. 1 . 10 4 / 70 packets 2 >&1 -o wget . out
16
cat wget . out >> throughput . txt
17
sleep 1
18
rm 70 packets
19
k i l l $tdid
20
done
21
rm wget . out
22
cat / var / log / kern . log > dmesg - cli . txt
23
cd ..
24
mkdir 140 packets
25
cd 140 packets
26
f o r i in $ ( seq 20) ; do
27
122
tcpdump -i wlan0 -n port 80 - vvv -w traza$i 2 >&1 >>
throughput . txt &
A.2 Script para las pruebas de descarga del cliente
28
#
tcpdump -i eth0 -n port 80 - vvv -w traza$i 2 >&1 >>
throughput . txt &
29
tdid = $ !
30
sleep 1
31
wget http : / / 1 9 2 . 1 6 8 . 1 . 1 0 4 / 1 4 0 packets -o wget . out
32
cat wget . out >> throughput . txt
33
sleep 1
34
rm 140 packets
35
k i l l $tdid
36
done
37
rm wget . out
38
cat / var / log / kern . log > dmesg - cli . txt
39
cd ..
40
mkdir 700 packets
41
cd 700 packets
42
f o r i in $ ( seq 20) ; do
tcpdump -i wlan0 -n port 80 - vvv -w traza$i 2 >&1 >>
43
throughput . txt &
44
#
tcpdump -i eth0 -n port 80 - vvv -w traza$i 2 >&1 >>
throughput . txt &
45
tdid = $ !
46
sleep 1
47
wget http : / / 1 9 2 . 1 6 8 . 1 . 1 0 4 / 7 0 0 packets -o wget . out
48
cat wget . out >> throughput . txt
49
sleep 1
50
rm 700 packets
51
k i l l $tdid
52
done
53
rm wget . out
54
cat / var / log / kern . log > dmesg - cli . txt
Cuadro A.2: Script bash del cliente para realizar las pruebas de descarga
123
A.3 Script para pruebas de descarga del sevidor
A.3.
1
124
Script para pruebas de descarga del sevidor
# !/ bin / bash
2
3
# uso : ./ download - servidor . sh
prueba
4
# Ejemplo : ./ download - servidor . sh
15 divacks
5
6
mkdir $1
7
cd $1
8
9
modprobe tcp_probe port =80
10
chmod 777 / proc / net / tcpprobe
11
cat / proc / net / tcpprobe > cwnd . txt &
12
TCPCAP = $ !
13
tcpdump -i eth0 -n host 192.168.1.102 - vvv -w traza - servidor &
14
TCPDUMP = $ !
15
16
read
17
18
k i l l $TCPCAP
19
k i l l $TCPDUMP
20
21
cat / var / log / kern . log > dmesg - srv . txt
Cuadro A.3: Script bash del servidor para realizar las pruebas de descarga
A.4 Scripts para el cálculo del throughput
A.4.
1
125
Scripts para el cálculo del throughput
# !/ bin / bash
2
3
# USO : throughput . sh ip . client ip . servidor
4
# EJEMPLO : ./ throughput . sh 150.185.182.66 200.47.79.53
5
6
# para download wget
7
f o r j in $ ( ls -F | grep \/ $ ) ; do
8
echo $j
9
cd $j
10
11
mv calculo - throughput . txt calculo - throughput . old
12
13
f o r i in $ ( ls - tr traza *) ; do
14
echo $i
15
tshark -r $i -o column . format : " " Time " , " %t " ," Source " , " %s
" , " Destination " , " %d " , " tcp . seq " , " %Cus : tcp . seq " , " tcp
. len " , " %Cus : tcp . len " , " IP_Flags " , " %Cus : tcp . flags " " "
ip . addr == $2 " > prueba . txt
python ~/ tesis / throughput . py $1 $2 < prueba . txt >>
16
calculo - throughput . txt
17
done
18
19
python ~/ tesis / throughput - promedio . py < calculo - throughput .
txt >> calculo - throughput . txt
20
21
22
cd ..
done
Cuadro A.4: throughput.sh
A.4 Scripts para el cálculo del throughput
1
import sys
2
3
cli = sys . argv [1]
4
srv = sys . argv [2]
5
linea = raw_input ()
6
7
# Download wget
8
primero = True
9
while linea :
datos = linea . split ()
10
11
#
T0 = tiempo de la llegada del primer paquete con datos .
i f datos [5]!= " 0 " and datos [1]== srv and primero :
12
13
t0 = float ( datos [0])
14
primero = False
15
i f datos [6]== " 0 x11 " :
16
i f datos [1]== srv :
bytes = long ( datos [4])
17
18
19
20
#
Llegada de datos desde servidor
i f datos [5]!= " 0 " and datos [1]== srv :
t1 = float ( datos [0])
21
22
23
24
25
try :
linea = raw_input ()
except EOFError :
break
26
27
tiempo = t1 - t0
28
throughput =( bytes *8) /( tiempo *1024)
29
p r i n t cli , srv , bytes /1024 , " KB " , tiempo , " s " , throughput , "
kbps "
Cuadro A.5: throughput.py
126
A.4 Scripts para el cálculo del throughput
1
linea = raw_input ()
2
3
tiempo =0
4
promedio =0
5
count =0
6
7
8
while linea :
datos = linea . split ()
9
10
count = count +1
11
tiempo = tiempo + float ( datos [4])
12
promedio = promedio + float ( datos [6])
13
14
15
16
17
try :
linea = raw_input ()
except EOFError :
break
18
19
tiempo = tiempo / count
20
promedio = promedio / count
21
22
p r i n t " Promedio " ," \ t " , tiempo , " s " , " \ t " , promedio , " Kbps "
Cuadro A.6: throughput-promedio.py
127
A.5 Scripts para la creación de las gráficas
A.5.
1
Scripts para la creación de las gráficas
# !/ bin / bash
2
3
# Uso : ./ graficar - cwnd . sh tamano - archivo ( el de la descarga )
nombre - datos1 puerto - datos1 nombre - datos2 puerto - datos2
4
# ./ graficar - cwnd . sh 99 kb 5 divacks - no - metric 49654 5 divacks
44442
5
6
python ~/ tesis / cwnd . py $3 < $2 / cwnd . txt > cwnd - $1 - $2 . txt
7
python ~/ tesis / cwnd . py $5 < $4 / cwnd . txt > cwnd - $1 - $4 . txt
8
9
python ~/ tesis / cwnd . py $7 < $6 / cwnd . txt > cwnd - $1 - $6 . txt
10
python ~/ tesis / cwnd . py $9 < $8 / cwnd . txt > cwnd - $1 - $8 . txt
11
12
gnuplot - persist << EOF
13
s e t terminal pdf
14
s e t grid
15
s e t style data linespoints
16
show timestamp
17
# set title " $2 "
18
s e t xlabel " Tiempo ( seconds ) "
19
s e t ylabel " segmentos ( cwnd , ssthresh ) "
20
21
# Leyenda
22
s e t key box
23
# set key right bottom
24
s e t key left
25
26
# Las dos muestras en una grafica
27
# set output " cwnd - $1 . pdf "
28
# plot " cwnd - $1 - $2 . txt " using 1:7 title " $2 cwnd " , \\
128
A.5 Scripts para la creación de las gráficas
29
#
129
" cwnd - $1 - $2 . txt " using 1:(\ $8 >=2147483647 ? 0 : \ $8 ) title "
$2 ssthresh " , \\
30
#
" cwnd - $1 - $4 . txt " using 1:7 title " $4 cwnd " , \\
31
#
" cwnd - $1 - $4 . txt " using 1:(\ $8 >=2147483647 ? 0 : \ $8 ) title "
$4 ssthresh "
32
33
# Cada muestra en una grafica
34
# set output " cwnd - $1 - $2 . pdf "
35
# # set xrange [0:0.07]
36
# # set yrange [0:55]
37
# plot " cwnd - $1 - $2 . txt " using 1:7 title " $2 cwnd " , \\
38
#
" cwnd - $1 - $2 . txt " using 1:(\ $8 >=2147483647 ? 0 : \ $8 ) title "
$2 ssthresh "
39
#
40
# set output " cwnd - $1 - $4 . pdf "
41
42
# plot " cwnd - $1 - $4 . txt " using 1:7 title " $4 cwnd " , \\
43
#
" cwnd - $1 - $4 . txt " using 1:(\ $8 >=2147483647 ? 0 : \ $8 ) title "
$4 ssthresh "
44
45
46
# Comparacion varios archivos
47
s e t output " cwnd - $1 - comparacion . pdf "
48
plot " cwnd - $1 - $2 . txt " using 1:7 title " $2 cwnd " , \\
49
" cwnd - $1 - $4 . txt " using 1:7 title " $4 cwnd " , \\
50
" cwnd - $1 - $6 . txt " using 1:7 title " $6 cwnd " , \\
51
" cwnd - $1 - $8 . txt " using 1:7 title " $8 cwnd " , \\
52
" cwnd - $1 - $2 . txt " using 1:(\ $8 >=2147483647 ? 0 : \ $8 ) title "
$2 ssthresh "
53
EOF
Cuadro A.7: graficar-cwnd.sh
A.5 Scripts para la creación de las gráficas
130
1
# ############################################################
2
# Filtra el achivo de la cwnd de tcp_probe usando el puerto #
3
# del cliente para que solo aparezca la cwnd de la descarga #
4
# que nos interesa y establece el tiempo de inicio en 0.
5
# ############################################################
6
import sys
7
8
prt = sys . argv [1]
9
linea = raw_input ()
10
11
while linea :
12
datos = linea . split ()
13
dst = datos [2]. split ( " : " )
14
15
i f dst [1]== prt :
16
t0 = float ( datos [0])
17
p r i n t " 0.0 " , datos [1] , datos [2] , datos [3] , datos [4] ,
datos [5] , datos [6] , datos [7] , datos [8] , datos [9]
18
break
19
20
21
22
23
try :
linea = raw_input ()
except EOFError :
break
24
25
linea = raw_input ()
26
27
while linea :
28
datos = linea . split ()
29
dst = datos [2]. split ( " : " )
30
31
i f dst [1]== prt :
#
A.5 Scripts para la creación de las gráficas
32
131
p r i n t float ( datos [0]) -t0 , datos [1] , datos [2] , datos [3] ,
datos [4] , datos [5] , datos [6] , datos [7] , datos [8] , datos
[9]
33
34
35
36
37
try :
linea = raw_input ()
except EOFError :
break
Cuadro A.8: cwnd.py
1
# !/ bin / bash
2
3
# uso : ../../../ graficar - descarga . sh
tamano - archivo ( descarga )
traza - datos1 nombre - datos1 traza - datos2 nombre - datos2
4
# Ejemplo : ../../../ graficar - descarga . sh 99 kb 5 divacks /70 packets
/ traza3 5 divacks control /70 packets / traza3 control
5
6
tshark -r $2 -o column . format : " " Time " , " %t " ," tcp . seq " , " %Cus :
tcp . seq " ," tcp . port " , " %Cus : tcp . port " " " ip . dst ==192.168.1.102
&& ip . src ==192.168.1.104 " > data - cliente - $1 - $3 . txt
7
tshark -r $2 -o column . format : " " Time " , " %t " ," tcp . ack " , " %Cus :
tcp . ack " ," tcp . port " , " %Cus : tcp . port " " " ip . dst ==192.168.1.104
&& ip . src ==192.168.1.102 " > acks - cliente - $1 - $3 . txt
8
tshark -r $4 -o column . format : " " Time " , " %t " ," tcp . seq " , " %Cus :
tcp . seq " ," tcp . port " , " %Cus : tcp . port " " " ip . dst ==192.168.1.102
&& ip . src ==192.168.1.104 " > data - cliente - $1 - $5 . txt
9
tshark -r $4 -o column . format : " " Time " , " %t " ," tcp . ack " , " %Cus :
tcp . ack " ," tcp . port " , " %Cus : tcp . port " " " ip . dst ==192.168.1.104
&& ip . src ==192.168.1.102 " > acks - cliente - $1 - $5 . txt
10
A.5 Scripts para la creación de las gráficas
11
132
tshark -r $6 -o column . format : " " Time " , " %t " ," tcp . seq " , " %Cus :
tcp . seq " ," tcp . port " , " %Cus : tcp . port " " " ip . dst ==192.168.1.102
&& ip . src ==192.168.1.104 " > data - cliente - $1 - $7 . txt
12
tshark -r $6 -o column . format : " " Time " , " %t " ," tcp . ack " , " %Cus :
tcp . ack " ," tcp . port " , " %Cus : tcp . port " " " ip . dst ==192.168.1.104
&& ip . src ==192.168.1.102 " > acks - cliente - $1 - $7 . txt
13
tshark -r $8 -o column . format : " " Time " , " %t " ," tcp . seq " , " %Cus :
tcp . seq " ," tcp . port " , " %Cus : tcp . port " " " ip . dst ==192.168.1.102
&& ip . src ==192.168.1.104 " > data - cliente - $1 - $9 . txt
14
tshark -r $8 -o column . format : " " Time " , " %t " ," tcp . ack " , " %Cus :
tcp . ack " ," tcp . port " , " %Cus : tcp . port " " " ip . dst ==192.168.1.104
&& ip . src ==192.168.1.102 " > acks - cliente - $1 - $9 . txt
15
16
gnuplot - persist << EOF
17
s e t terminal pdf
18
s e t xrange [0.0:]
19
s e t style data linespoints
20
s e t grid
21
show timestamp
22
s e t xlabel " Tiempo ( segundos ) "
23
s e t ylabel " Segmentos ( bytes ) "
24
25
# Leyenda
26
s e t key box
27
# set key right bottom
28
s e t key left
29
30
# Las dos muestras en una grafica
31
# set output " descarga - cliente - $1 . pdf "
32
# plot " data - cliente - $1 - $3 . txt " using 1:2 title " $3 " , \
33
#
" data - cliente - $1 - $5 . txt " using 1:2 title " $5 "
34
35
# Varias graficas
A.5 Scripts para la creación de las gráficas
36
s e t output " descarga - cliente - $1 . pdf "
37
plot " data - cliente - $1 - $3 . txt " using 1:2 title " $3 " , \
38
" data - cliente - $1 - $5 . txt " using 1:2 title " $5 " ,\
39
" data - cliente - $1 - $7 . txt " using 1:2 title " $7 " ,\
40
" data - cliente - $1 - $9 . txt " using 1:2 title " $9 "
133
41
42
# Cada muestra en una grafica
43
# set output " descarga - $3 . pdf "
44
# # set xrange [0:0.16]
45
# # set yrange [0:0.006]
46
# # set xrange [0.001:0.002] # zoom entre ese rango
47
# plot " data - cliente - $1 - $3 . txt " using 1:2 title " DATA " , \
48
#
" acks - cliente - $1 - $3 . txt " using 1:2 title " ACKs "
49
50
# set output " descarga - $5 . pdf "
51
# plot " data - cliente - $1 - $5 . txt " using 1:2 title " DATA " , \
52
#
" acks - cliente - $1 - $5 . txt " using 1:2 title " ACKs "
53
54
# Usando ’ with ’ cambio el estilo de la grafica - estilos : http
:// t16web . lanl . gov / Kawano / gnuplot / intro / style - e . html
55
# plot " data - cliente - $1 - $3 . txt " using 1:2 with linespoints
pointtype 6 pointsize 0.5 title " DATA " , \
56
#
" acks - cliente - $1 - $3 . txt " using 1:2 with points pointtype 4
pointsize 0.5 title " ACKs "
57
#
58
EOF
Cuadro A.9: graficar-descarga.sh
A.5 Scripts para la creación de las gráficas
1
134
# !/ bin / bash
2
3
# Uso : ../../ graficar - descarga - srv . sh tamano - archivo nombre datos1 puerto - datos1 nombre - datos2 puerto - datos2
4
# Ejemplo : ../../ graficar - descarga - srv . sh 99 kb 9 divacks 47674
control 46909
5
6
tshark -r $2 / traza - servidor -o column . format : " " Time " , " %t " ," tcp
. seq " , " %Cus : tcp . seq " ," tcp . port " , " %Cus : tcp . port " " " ip . dst
==192.168.1.102 && tcp . port == $3 " > data - $1 - $2 - srv . txt
7
tshark -r $2 / traza - servidor -o column . format : " " Time " , " %t " ," tcp
. ack " , " %Cus : tcp . ack " ," tcp . port " , " %Cus : tcp . port " " " ip . dst
==192.168.1.104 && tcp . port == $3 " > acks - $1 - $2 - srv . txt
8
tshark -r $4 / traza - servidor -o column . format : " " Time " , " %t " ," tcp
. seq " , " %Cus : tcp . seq " ," tcp . port " , " %Cus : tcp . port " " " ip . dst
==192.168.1.102 && tcp . port == $5 " > data - $1 - $4 - srv . txt
9
tshark -r $4 / traza - servidor -o column . format : " " Time " , " %t " ," tcp
. ack " , " %Cus : tcp . ack " ," tcp . port " , " %Cus : tcp . port " " " ip . dst
==192.168.1.104 && tcp . port == $5 " > acks - $1 - $4 - srv . txt
10
11
tshark -r $6 / traza - servidor -o column . format : " " Time " , " %t " ," tcp
. seq " , " %Cus : tcp . seq " ," tcp . port " , " %Cus : tcp . port " " " ip . dst
==192.168.1.102 && tcp . port == $7 " > data - $1 - $6 - srv . txt
12
tshark -r $6 / traza - servidor -o column . format : " " Time " , " %t " ," tcp
. ack " , " %Cus : tcp . ack " ," tcp . port " , " %Cus : tcp . port " " " ip . dst
==192.168.1.104 && tcp . port == $7 " > acks - $1 - $6 - srv . txt
13
tshark -r $8 / traza - servidor -o column . format : " " Time " , " %t " ," tcp
. seq " , " %Cus : tcp . seq " ," tcp . port " , " %Cus : tcp . port " " " ip . dst
==192.168.1.102 && tcp . port == $9 " > data - $1 - $8 - srv . txt
14
tshark -r $8 / traza - servidor -o column . format : " " Time " , " %t " ," tcp
. ack " , " %Cus : tcp . ack " ," tcp . port " , " %Cus : tcp . port " " " ip . dst
==192.168.1.104 && tcp . port == $9 " > acks - $1 - $8 - srv . txt
A.5 Scripts para la creación de las gráficas
15
16
17
18
19
f o r T1 in $ ( cat data - $1 - $2 - srv . txt ) ; do
break
done
20
21
22
23
f o r T2 in $ ( cat data - $1 - $4 - srv . txt ) ; do
break
done
24
25
26
27
f o r T3 in $ ( cat data - $1 - $6 - srv . txt ) ; do
break
done
28
29
30
31
f o r T4 in $ ( cat data - $1 - $8 - srv . txt ) ; do
break
done
32
33
echo T1 : $T1 T2 : $T2 T3 : $T3 T4 : $T4
34
35
36
gnuplot - persist << EOF
37
s e t terminal pdf
38
s e t xrange [0.0:]
39
s e t style data linespoints
40
s e t grid
41
show timestamp
42
# set title " $2 "
43
s e t xlabel " Tiempo ( segundos ) "
44
s e t ylabel " Segmentos ( bytes ) "
45
46
# Leyenda
47
s e t key box
135
A.5 Scripts para la creación de las gráficas
48
s e t key left
49
# set key right bottom
136
50
51
# Varias muestras en una grafica
52
s e t output " descarga - servidor - $1 . pdf "
53
plot " data - $1 - $2 - srv . txt " using (\ $1 - $T1 ) :2 title " $2 " , \
54
" data - $1 - $4 - srv . txt " using (\ $1 - $T2 ) :2 title " $4 " , \
55
" data - $1 - $6 - srv . txt " using (\ $1 - $T3 ) :2 title " $6 " , \
56
" data - $1 - $8 - srv . txt " using (\ $1 - $T4 ) :2 title " $8 "
57
58
# Cada muestra en una grafica
59
# set output " descarga - $1 - $2 - srv . pdf "
60
# # set xrange [0.0:0.16]
61
# # set xrange [0.001:0.002] # zoom entre ese rango o para colocar
ambas graficas en la misma escala
62
# plot " data - $1 - $2 - srv . txt " using (\ $1 - $T1 ) :2 title " DATA " , \
63
#
" acks - $1 - $2 - srv . txt " using (\ $1 - $T1 ) :2 title " ACKs "
64
65
# set output " descarga - $1 - $4 - srv . pdf "
66
# # set xrange [0.001:0.002] # zoom entre ese rango
67
# plot " data - $1 - $4 - srv . txt " using (\ $1 - $T2 ) :2 title " DATA " , \
68
#
" acks - $1 - $4 - srv . txt " using (\ $1 - $T2 ) :2 title " ACKs "
69
70
EOF
Cuadro A.10: graficar-descarga-srv.sh
A.5 Scripts para la creación de las gráficas
1
137
# !/ bin / bash
2
3
# Uso :
./ graficar - throughput . sh archivo - datos ( sin extencion )
nombre - datos1 nombre - datos2 ...
4
# Ejemplo :
./ graficar - throughput . sh prueba2 -99 kb 9 divacks
control
5
6
gnuplot - persist << EOF
7
8
s e t terminal pdf
9
s e t output " $1 - tiempo . pdf "
10
# set output " $1 - Throughput . pdf "
11
s e t grid
12
13
# Leyenda
14
s e t key box
15
s e t key left
16
17
# Girar etiquetas en X
18
# set xtics rotate by 45 nomirror offset 0 , -1
19
20
# set title " Prueba de Rendimiento "
21
s e t ylabel " Tiempo de descarga ( s ) "
22
# set ylabel " Rendimiento ( KBytes / sec ) "
23
s e t xlabel " Retardo ( ms ) "
24
s e t yrange [0:]
25
s e t boxwidth 1.0 relative
26
s e t style data histograms
27
s e t style fill pattern 4 border lt -1 # Barras con patrones (
interior )
28
# set style fill solid 1.0 border # barras con color solido
29
# Para histograma sin graficar error
A.5 Scripts para la creación de las gráficas
30
138
s e t style histogram clustered gap 1
31
32
# Para comparar dos graficas
33
# Tempo de descarga :
34
plot f o r [ COL =2:2:1] ’ $1 . txt ’ using COL : xticlabels (1) title " $2
", \
f o r [ COL =4:4:1] ’ $1 . txt ’ using COL : xticlabels (1) title " $3 "
35
36
# Throughput graficas suavizadas
37
# plot " $1 . txt " using 1:3 with lines title " $2 " smooth sbezier ,
\
38
#
" $1 . txt " using 1:5 with lines title " $3 " smooth sbezier
39
# Varios divacks , control referencia , tiempo
40
plot f o r [ COL =4:4:1] ’ $1 . txt ’ using COL : xticlabels (1) title " $3
", \
f o r [ COL =6:6:1] ’ $1 . txt ’ using COL : xticlabels (1) title " $4 "
41
, \
f o r [ COL =8:8:1] ’ $1 . txt ’ using COL : xticlabels (1) title " $5 "
42
, \
’ $1 . txt ’ using 2: xticlabels (1) with histeps lc -1 title " $2
43
"
44
# Varios divacks throughput graficas suavizadas
45
# plot " $1 . txt " using 1:3 with lines title " $2 " lc -1 smooth
sbezier , \
46
#
" $1 . txt " using 1:5 with lines title " $3 "
lc 1 smooth
sbezier , \
47
#
" $1 . txt " using 1:7 with lines title " $4 "
lc 2 smooth
sbezier , \
48
#
" $1 . txt " using 1:9 with lines title " $5 "
lc 3 smooth
sbezier
49
50
EOF
Cuadro A.11: graficar-throughput.sh