¿Por qué las segundas descargas comienzan lentas?

Quizás con las conexiones modernas no se note demasiado, pero con un modem de 56k si que se sigue notando. Me refiero a la siguiente curiosidad que muchos sabrán y otros no y que me apetece contar: No estás utilizando la red y empiezas a bajarte algo, y la conexión pronto llega, si el servidor tiene el ancho de banda suficiente y la ruta entre él y tu equipo es adecuada, a su "tope". Sin embargo, si según te estás bajando ese archivo comienzas a bajarte otro, este segundo archivo comienza bajándose a un ancho de banda bajísimo, ridículo, que aumenta progresiva y lentamente al mismo tiempo que el ritmo de descarga del primer archivo disminuye. A veces, si la primera descarga baja muy rapido y/o la luna está en cuarto creciente, la segunda descarga empieza tan lento que simplemente no llega a empezar: Salta algún timeout en algún lado y se cierra la conexión. ¿Por qué ocurre todo esto?

La respuesta está en un control de congestión que se implementa en todas las pilas TCP/IP. Pero como tantas otras cosas, tiene su historia.

En los albores de internet, no existía ningún tipo de control de congestión verdadero. Simplemente se mandaban los paquetes a la máxima velocidad que daba de si la interfaz de red. Si la interfaz del receptor era muy lenta y no podía recibir todos los paquetes a esa velocidad, simplemente se perdían los paquetes (la red no es como un embudo: si metes más informacion de la que cabe no se "acumula", se pierde lo sobrante). El rápido emisor reenviaba lo perdido, y continuaba mandando más, hasta el proximo embotellamiento.

En los albores de internet esto funcionó bien, pero cuando creció internet este problema se hizo muy grande. Sospecho (no lo he confirmado, pero mi sentido arácnido me dice que mis sospechas son ciertas) que los orígenes del problema vinieron de la propia expansión de internet: En un inicio había pocos ordenadores conectados a internet, las redes eran financiadas por caros proyectos de investigación y siempre estaban a la última y tenían velocidades parecidas. Los embotellamientos no eran un gran problema. Pero cuando internet creció, las diferencias de capacidad entre unas redes y otras se acrecentaron. Y hubo que crear mayores redes de interconexión entre las principales redes, que a veces tenían menor ancho de banda que los equipos: Por mucho que un emisor y un receptor tuvieran una conexión de X KB/s, si entre ellas había una red con X/2 KB/s, la conexión solo iba poder ir a X/2 KB/s.

Esto hizo que en el 86 y en adelante empezaran a detectarse auténticos colapsos de internet, pérdida masiva de paquetes. Era imposible enviar datos a ciertos sitios y era imposible descargarse emacs de una vez, había que bajarselo en trocitos. En aquellos tiempos las grandes interconexiones de backbones de Internet iban a 56 Kbps. Cundió la duda: ¿Era TCP incapaz de escalar a mayores velocidades? ¿Había que rehacer toda la tecnología? ¿Dónde estaba el fallo? La solución se dió en la reunión USENIX de 1989. Se presentó una charla titulada "Congestión Avoidance and Control", que presentaba una serie de algoritmos, que fueron implementados en forma de parche en los sistemas operativos que controlaban los grandes núcleos de internet - BSDs. Se hizo un RFC que ordenaba literalmente implementar este sistema de congestión de control. Una de las personas que había escrito ese documento se llamaba Van Jacobson. Ha trabajado toda la vida en TCP/IP, ha escrito importantes documentos y ha colaborado tambien en varios RFCs. Los que hayan utilizado alguna vez un modem, ¿han oido alguna vez manejando pppd de una compresión de cabeceras IP apodada "VJ compression"? Pues las iniciales VJ pertenecen, efectivamente, a Van Jacobson. Por cierto: Este tipo aun trabaja en asuntos de TCP/IP, utiliza mucho con Linux, dice que Linux tiene la pila TCP/IP más rápida y mejor del planeta -esto va por los que dicen que Linux es un SO de juguete-, e incluso presentó una charla sobre una proposición de diseño de la pila tcp/ip para aprovechar las capacidades del hardware del futuro.

Pero me desvio. ¿En que consistía el sistema de control de congestión? Es un sistema simple: La técnica se apodaba "slow-start". Se empezaba mandando un paquete. Si el paquete llegaba correctamente -según el protocolo TCP, el receptor debe confirmar con un ACK la llegada del paquete-, la próxima vez se enviaban dos paquetes: Uno por el paquete por el que llegó el ACK, y otro más que se añade. Si esos dos llegaban bien, la siguiente vez se mandaban cuatro: dos por los ACKs, y otros dos que se añaden, uno por ACK. Etc. Cada conexión guarda en una variable el número de paquetes enviados, para saber cuantos necesitaba enviar la próxima vez. Asi, se comienza la conexión progresivamente, hasta llegar al límite de la conexión entre los dos equipos. Cuando se llegaba al límite -dejaban de llegar paquetes correctamente al receptor-, entraba en juego el control de congestión: en vez de incrementarse tan rápido se incrementaba más lentamente. ¿Y como se detecta la congestión? Pues cuando ocurre un timeout (no llega un ACK para un paquete en un tiempo limitado), se anota en una variable ssthresh (independiente para cada conexión) la mitad de la otra variable, la que controla el numero de paquetes que se envian, y se resetea la cantidad de paquetes que puede enviar la conexión a uno, desde el principio. Mientras la cantidad de paquetes sea menor que sshtresh, se sigue haciendo "slow-start", cuando llega a sshtresh -la mitad del ancho de banda que nos hizo llegar a un timeout anteriormente- se comienza a incrementar lentamente: control de congestión.

Es decir, aunque matemáticamente sea algo más dificil de entender, hace lo obvio: Manda paquetes hasta que ve que la conexión no da mas -se detecta un timeoput- y entonces empieza a enviar menos y a dejar de aumentar rapidamente el ritmo. A día de hoy existen algoritmos mucho más complejos y muy diferentes, optimizados para diferentes situaciones -en redes wireless hay muchas pérdidas de paquetes por razones distintas al ancho de banda, y con el slow-start el rendimiento es subóptimo- pero todos tienen algo en común con éste: El control de congestión.

¿Como se refleja esto en nuestras descargas, que es lo que motivó esta entrada? Fácil: Cuando empezamos a descargar un solo archivo, la velocidad aumenta rápidamente. Pero si estamos descargando un archivo y empezamos a descargar otro, la situación es distinta: La conexión ya está aproximadamente en su máximo. Eso provoca que la segunda conexión empiece a perder paquetes al no caber más datos en la conexión. El servidor que envia el segundo archivo, al detectar los timeouts provocados por las pérdidas, baja la velocidad de la conexión para adaptarse, y la aumenta lentamente, para controlar lo que él cree que es "congestión". Al mismo tiempo la primera descarga, ante este pequeño incremento de ancho de banda por parte de la segunda descarga, empieza a perder paquetes, con lo cual el servidor del primer archivo baja un poco la velocidad de envio. Y así es como más o menos las dos descargas empiezan a equilibrarse. A veces no llegan a equilibrarse, todo depende de mil factores, pero el sistema básico es este.