Bufferbloat, Internet y cómo solucionarlo

Existe una temida enfermedad que ha afectado a los proveedores de servicios de Internet durante años. De acuerdo, probablemente hay varias enfermedades, pero hoy estamos hablando hinchar el búfer. Qué es, cómo probarlo y, en última instancia, qué puede hacer al respecto. Ah, y un gran saludo a todas las personas que trabajan en este problema. Muchos desarrolladores e ingenieros, como Vint Cerf, Dave Taht, Jim Gettys y muchos más, han roto esta nuez para nuestro beneficio colectivo.

Cuando su computadora envía un paquete TCP/IP a otro host en Internet, ese paquete viaja a través de su computadora, a través de la tarjeta de red, a través de un conmutador, a través de su enrutador, a través de un módem ISP, a través de varios enrutadores ISP y finalmente a través de varios enrutadores muy grandes en el camino hacia el centro de datos. O quizás a través de esa enrevesada cadena de dispositivos a la inversa, para llegar a otro escritorio. Es un milagro que todo funcione, de verdad. Cada uno de esos saltos representa otro lugar para que las cosas salgan mal. Y si algo realmente sale mal, lo sabes de inmediato. Las páginas de repente no se cargan. Sus llamadas de VoIP se interrumpen o tienen interrupciones. Es bastante fácil detectar una conexión rota, incluso si encontrarla y repararla no es tan trivial.

Ese es un problema obvio. ¿Qué pasa si tienes un problema no obvio? Los sitios web se cargan, pero un poco más lentos de lo que parece que solían hacerlo. Sabe cómo utilizar una línea de comandos, así que prueba una ping prueba Eh, 15,0 ms de distancia a Google.com. Deje que funcione durante cien paquetes y, básicamente, sin pérdida de paquetes. Pero algo simplemente no está bien. Cuando alguien más transmite una película o una máquina envía una copia de seguridad a un servidor remoto, todo se desmorona. Eso es bufferbloat, y en realidad es muy fácil hacer una prueba simple para detectarlo. Realice una prueba de velocidad y una prueba de ping mientras su conexión está saturada. Si su latencia bajo carga se dispara, probablemente tenga un búfer. Incluso hay algunos de los grandes sitios de prueba de velocidad que ahora ofrecen pruebas de bufferbloat. Pero antes, un poco de historia.

Historia del colapso

Internet en la década de 1980 era un lugar muy diferente. El sistema de nombres de dominio reemplazado hosts.txt como se hizo en 1982 la forma en que se hizo la resolución de nombre de host a IP. El 1 de enero de 1983, ARPANET adoptó TCP/IP, el nacimiento de Internet. En 1984 hubo un problema, y ​​en 1986 Internet sufrió un infarto en forma de colapso por congestión.

En aquellos días, las redes de área local de vanguardia operaban a 10 megabits por segundo, pero los enlaces de sitio a sitio solo transferían 56 kilobytes por segundo en el mejor de los casos. A finales de 1986, los enlaces sufrieron repentinamente ralentizaciones extremas, como el enlace de 400 yardas entre el Laboratorio Lawrence Berkeley y la Universidad de California en Berkeley. En lugar de 56 Kbps, este enlace se movió repentinamente a una velocidad eficiente de 40 bits por segundo. El problema era la congestión. Es un modelo muy similar a lo que sucede cuando hay demasiados autos en el mismo tramo de la autopista: el tráfico se vuelve lento.

La versión 4.3 de BSD tenía una implementación de TCP que hizo algunas cosas interesantes. Primero, inmediatamente comenzaría a enviar paquetes a toda velocidad. Y en segundo lugar, si un paquete se cayera en el camino, lo devolvería lo antes posible. En una Red de Área Local, donde hay una velocidad de red uniforme, esto funciona bien. En los inicios de Internet, especialmente en este enlace particular de Berkeley, la conexión LAN de 10 Mb/s se canalizaba hasta 32 kbps o 56 kbps.

Para manejar este desajuste, las puertas de enlace en ambos lados del enlace tienen un pequeño búfer, alrededor de 30 paquetes. En un escenario de congestión, más de 30 paquetes retroceden en la entrada y los paquetes adicionales acaban de caer. Cuando los paquetes se descartaban o la congestión empujaba el tiempo de ida y vuelta más allá del umbral de tiempo de espera, el remitente retransmitía inmediatamente, generando más tráfico. Varios hosts que intentan enviar demasiados datos a través de una conexión demasiado estrecha provocan un colapso de la congestión y el tráfico de retroalimentación. Los inicios de Internet involuntariamente DDoS en sí.

La solución fue una serie de algoritmos agregados a la implementación de TCP de BSD que ahora se han adoptado como parte del estándar. En pocas palabras, para enviar lo más rápido posible, el tráfico tenía que reducirse inteligentemente. La primera técnica introducida fue un comienzo lento. Puede ver que esto todavía está en uso cuando ejecuta una prueba de velocidad, y la conexión comienza a una velocidad muy lenta y luego aumenta rápidamente. Específicamente, solo se envía un paquete al comienzo de una transmisión. Por cada paquete recibido, se devuelve un paquete de acuse de recibo (ack). Después de recibir un acuse de recibo, se envían dos paquetes más por el cable. Esto da como resultado un aumento rápido al doble de la velocidad máxima del eslabón más lento en la cadena de conexión. El número de paquetes "fuera" a la vez se denomina tamaño de la ventana de congestión. Entonces, otra forma de verlo es que cada éxito de ida y vuelta aumenta la congestión en uno.

Una vez que el inicio lento ha hecho su trabajo y el primer paquete se descarta o se agota el tiempo de espera, el flujo TCP pasa a utilizar un algoritmo para evitar la congestión. Este hace hincapié en mantener una tasa de datos estable. Si se descarta un paquete, las ventanas se reducen a la mitad y cada vez que se recibe el valor de una ventana completa de paquetes, la ventana aumenta en uno. El resultado es un gráfico de diente de sierra que salta constantemente alrededor del rendimiento máximo de toda la ruta de datos. Esto es un poco una simplificación excesiva, y los algoritmos se han desarrollado aún más con el tiempo, pero el punto es que el desarrollo de esta extensión de TCP/IP salvó a Internet. En algunos casos, las actualizaciones se enviaban en cinta, a través del correo, una especie de restablecimiento completo de toda la red.

Avance rápido hasta 2009

Internet ha evolucionado bastante desde 1986. Una de las cosas que ha cambiado es que el precio del hardware ha bajado y las capacidades han aumentado drásticamente. Una puerta de enlace de 1986 mediría su búfer en kilobytes, y menos de 100. Hoy en día, es bastante trivial arrojar megabytes y gigabytes de memoria a los problemas, y los enrutadores no son una excepción. ¿Qué sucede cuando los algoritmos escritos para tamaños de búfer de 50 kB se encuentran con búferes de 50 MB en dispositivos modernos? Como era de esperar, las cosas salen mal.

Cuando un gran búfer First In First Out (FIFO) se encuentra en el cuello de botella, ese búfer debe llenar su capacidad antes de que se descarten los paquetes. El flujo de TCP está destinado a ralentizar hasta 2 veces el ancho de banda disponible, comenzar a descartar paquetes muy rápidamente y reducir su ancho de banda a la mitad. Bufferbloat es lo que sucede cuando ese flujo pasa demasiado tiempo tratando de enviar al doble de la velocidad disponible, esperando que se llene el búfer. Y una vez que la conexión salta a su modo de evitación de congestión estable, ese algoritmo se basa en paquetes perdidos o tiempos de espera, donde el umbral de tiempo de espera se deriva del tiempo de ida y vuelta observado. El resultado es que para cualquier conexión, la latencia de ida y vuelta aumenta con la cantidad de paquetes almacenados en el búfer en la ruta. Y para una conexión bajo carga, las técnicas para evitar la congestión de TCP están diseñadas para llenar esos búferes antes de reducir la ventana de congestión.

Entonces, ¿qué tan malo puede ser? En una red local, el tiempo de ida y vuelta se mide en microsegundos. Su tiempo de host de Internet debe medirse en milisegundos. Bufferbloat lleva eso a segundos, y decenas de segundos en algunos de los peores casos. Donde esto realmente causa problemas es cuando hace que el tráfico se agote en la capa de aplicación. Bufferbloat retrasa todo el tráfico, por lo que puede causar tiempos de espera de DNS, hacer que las llamadas VoIP sean un desastre y hacer que Internet sea una experiencia dolorosa.

La solución es la gestión inteligente de colas. Se ha trabajado mucho en este concepto desde 1986. La creación de colas justas fue una de las primeras soluciones, ya que hizo que los búfer intermedios fueran inteligentes y dividiera los flujos de tráfico individuales en colas individuales. Cuando el enlace estaba congestionado, cada cola liberaba un paquete a la vez, por lo que la descarga de un ISO a través de Bittorrent no ralentizaba por completo el tráfico de VoIP. Después de muchas iteraciones, el algoritmo CAKE se desarrolló y se implementó ampliamente. Todas estas soluciones esencialmente compensan un rendimiento máximo para garantizar una latencia significativamente reducida.

¿Eres FLENT en Bufferbloat?

Me gustaría decirle que bufferbloat es un problema resuelto y que definitivamente no tiene ningún problema con él en su red. Eso, por desgracia, no es tan así. Para saber si tiene un problema, use las pruebas de velocidad en dslreports, fast.com o speedtest.net. Cada uno de estos tres, y probablemente otros, brinda cierta latencia bajo medición de carga. Hay una prueba específica de Bufferbloat alojada por forma de onda, y parece ser la mejor para ejecutar en el navegador. Una red ideal aún mostrará baja latencia cuando haya congestión. Si su latencia aumenta significativamente durante la prueba, probablemente tenga un caso de bufferbloat.

Para los geeks entre nosotros, existe una herramienta de línea de comandos, flent, que hace una prueba profunda de bufferbloat. Usé el comando, flent rrul -p all_scaled -H flent-fremont.bufferbloat.net para generar este gráfico, y verá que la latencia aumenta rápidamente más de 100 ms bajo carga. Esto ejecuta la respuesta en tiempo real bajo la prueba de carga e indica claramente que tengo un pequeño problema de almacenamiento en búfer en mi red. Problema identificado, ¿qué puedo hacer al respecto?

Puedes tener tu pastel

Dado que todos usamos enrutadores OpenWRT en nuestras redes... Está ejecutando un enrutador de código abierto, ¿verdad? Alternativamente, hay algunos enrutadores comerciales que tienen algún tipo de SQM incorporado, pero ciertamente no estamos satisfechos con eso aquí en la-tecnologia.com. La solución de FOSS aquí es CAKE, un sistema de gestión de colas, y ya está disponible en el repositorio de OpenWRT. El paquete que buscas es luci-app-sqm. La instalación le brinda una nueva página en la interfaz web, en Red -> SQM QoS.

En esa página, seleccione su interfaz WAN como Interface name. Luego, convierta los resultados de su prueba de velocidad en Kilobits/segundo, elimine alrededor del 5% y conéctelos a las velocidades de carga y descarga. Gire a la Queue Discipline pestaña donde idealmente queremos usar Cake y piece_of_cake.qos como las opciones. Esa última pestaña requiere algo de preparación para determinar el mejor valor, pero Ethernet with overhead y 22 parecen ser valores sensatos para empezar. Habilite la instancia de SQM y luego guarde y aplique.

Y ahora configuramos y probamos. En la primera instalación, el enrutador puede necesitar un reinicio para cargar el núcleo módulo. Pero debería ver una diferencia inmediata en una de las pruebas de bufferbloat. Si su búfer de carga o descarga sigue siendo excesivo, establezca la velocidad de esa dirección un poco más abajo en un pequeño porcentaje. Si su bufferbloat cae a 0, intente aumentar un poco la velocidad. Está buscando un impacto mínimo en la velocidad máxima y un impacto máximo en la sobrecarga del búfer. ¡Y eso es! ¡Has matado a la Bestia Bufferbloat!

Fernando Román
Fernando Román

Deja una respuesta

Tu dirección de correo electrónico no será publicada.