Bufferbloat es una causa de alta latencia y fluctuación en redes de conmutación de paquetes causadas por un exceso de almacenamiento en búfer de paquetes . El bufferbloat también puede causar variación en el retraso de los paquetes (también conocido como jitter), así como reducir el rendimiento general de la red . Cuando un enrutador o conmutador está configurado para utilizar buffers excesivamente grandes, incluso las redes de muy alta velocidad pueden volverse prácticamente inutilizables para muchas aplicaciones interactivas como voz sobre IP (VoIP), transmisión de audio , juegos en línea e incluso navegación web normal .
Algunos fabricantes de equipos de comunicaciones diseñaron buffers innecesariamente grandes en algunos de sus productos de red . En dichos equipos, el bufferbloat ocurre cuando un enlace de red se congestiona , lo que hace que los paquetes queden en cola durante largos períodos en estos buffers de gran tamaño. En un sistema de colas de primero en entrar, primero en salir , los buffers demasiado grandes dan como resultado colas más largas y una mayor latencia, y no mejoran el rendimiento de la red. También puede ser inducido por conexiones específicas de baja velocidad que dificultan la entrega a tiempo de otros paquetes.
El fenómeno bufferbloat se describió ya en 1985. [1] Obtuvo una mayor atención a partir de 2009. [2]
Según algunas fuentes, la causa más frecuente de alta latencia ("lag") en los videojuegos en línea es el bufferbloat de la red doméstica local. La alta latencia puede hacer que los juegos en línea modernos sean imposibles. [3]
Una regla general establecida por los fabricantes de equipos de red era proporcionar buffers lo suficientemente grandes como para acomodar al menos 250 ms de buffer para un flujo de tráfico que pasa a través de un dispositivo. Por ejemplo, la interfaz Gigabit Ethernet de un enrutador requeriría un búfer relativamente grande de 32 MB . [4] Este tamaño de los buffers puede provocar un fallo del algoritmo de control de congestión de TCP . Luego, los buffers tardan un tiempo en vaciarse, antes de que el control de congestión se restablezca y la conexión TCP vuelva a acelerar y llene los buffers nuevamente. [5] Por lo tanto, el bufferbloat causa problemas tales como latencia alta y variable, y cuellos de botella de red para todos los demás flujos, ya que el buffer se llena con los paquetes de un flujo TCP y luego se descartan otros paquetes. [6]
Un búfer inflado tiene efecto sólo cuando este búfer se utiliza realmente. En otras palabras, los buffers sobredimensionados tienen un efecto dañino sólo cuando el enlace que amortiguan se convierte en un cuello de botella. El tamaño del búfer que sirve a un cuello de botella se puede medir utilizando la utilidad ping proporcionada por la mayoría de los sistemas operativos. Primero, se debe hacer ping al otro host continuamente; luego, se debe iniciar y detener varias veces una descarga de varios segundos de duración. Por diseño, el algoritmo para evitar la congestión de TCP llenará rápidamente el cuello de botella en la ruta. Si la descarga (y la carga, respectivamente) se correlaciona con un aumento directo e importante del tiempo de ida y vuelta informado por ping, entonces demuestra que el buffer del cuello de botella actual en la dirección de descarga (y carga, respectivamente) está inflado. Dado que el aumento del tiempo de ida y vuelta es causado por el buffer en el cuello de botella, el aumento máximo da una estimación aproximada de su tamaño en milisegundos. [ cita necesaria ]
En el ejemplo anterior, usar una herramienta de traceroute avanzada en lugar del simple ping (por ejemplo, MTR ) no solo demostrará la existencia de un búfer inflado en el cuello de botella, sino que también señalará su ubicación en la red. Traceroute logra esto mostrando la ruta (ruta) y midiendo los retrasos en el tránsito de los paquetes a través de la red. El historial de la ruta se registra como tiempos de ida y vuelta de los paquetes recibidos de cada host sucesivo (nodo remoto) en la ruta (ruta). [7]
La mayoría de los algoritmos de control de congestión de TCP se basan en medir la ocurrencia de caídas de paquetes para determinar el ancho de banda disponible entre dos extremos de una conexión. Los algoritmos aceleran la transferencia de datos hasta que los paquetes comienzan a caer y luego reducen la velocidad de transmisión. Idealmente, siguen ajustando la velocidad de transmisión hasta que alcanza una velocidad de equilibrio del enlace. Para que los algoritmos puedan seleccionar una velocidad de transferencia adecuada, la información sobre la caída de paquetes debe producirse de manera oportuna. Con un buffer grande lleno, los paquetes llegarán a su destino, pero con una latencia mayor. Los paquetes no se descartaron, por lo que TCP no se ralentiza una vez que el enlace ascendente se ha saturado, llenando aún más el búfer. Los paquetes recién llegados se descartan sólo cuando el búfer está completamente saturado. Una vez que esto sucede, TCP puede incluso decidir que la ruta de la conexión ha cambiado y nuevamente emprender una búsqueda más agresiva de un nuevo punto de operación. [8]
Los paquetes se ponen en cola dentro de un búfer de red antes de transmitirse; en situaciones problemáticas, los paquetes se descartan sólo si el búfer está lleno. En los enrutadores más antiguos, los buffers eran bastante pequeños, por lo que se llenaban rápidamente y, por lo tanto, los paquetes comenzaron a caer poco después de que el enlace se saturara, por lo que el protocolo TCP podía ajustarse y el problema no se hacía evidente. En los enrutadores más nuevos, los buffers se han vuelto lo suficientemente grandes como para contener varios segundos de datos almacenados en el buffer. Para TCP, un enlace congestionado puede parecer que funciona normalmente a medida que se llena el búfer. El algoritmo TCP no se da cuenta de que el enlace está congestionado y no comienza a tomar medidas correctivas hasta que el búfer finalmente se desborda y los paquetes se descartan.
Todos los paquetes que pasan a través de un búfer simple implementado como una cola única experimentarán un retraso similar, por lo que la latencia de cualquier conexión que pase a través de un búfer lleno se verá afectada. El ancho de banda de canal disponible también puede terminar sin utilizarse, ya que es posible que algunos destinos rápidos no se alcancen rápidamente debido a buffers obstruidos con datos en espera de entrega a destinos lentos. Estos efectos perjudican la interactividad de las aplicaciones que utilizan otros protocolos de red , incluido UDP utilizado en aplicaciones sensibles a la latencia como VoIP y juegos en línea. [9] [ fuente autoeditada ]
Independientemente de los requisitos de ancho de banda, cualquier tipo de servicio que requiera una latencia constantemente baja o una transmisión sin fluctuaciones puede verse afectado por el bufferbloat. Dichos servicios incluyen llamadas de voz digitales (VOIP), juegos en línea, video chat y otras aplicaciones interactivas como transmisión de radio , video a pedido e inicio de sesión remoto .
Cuando el fenómeno de bufferbloat está presente y la red está bajo carga, incluso las cargas normales de páginas web pueden tardar muchos segundos en completarse, o las consultas DNS simples pueden fallar debido a tiempos de espera. [10] En realidad, cualquier conexión TCP puede expirar y desconectarse, y los paquetes UDP pueden descartarse. Dado que la continuación de una secuencia de descarga TCP depende de los paquetes de reconocimiento (ACK) en la secuencia de carga, un problema de bufferbloat en la carga puede causar fallas en otras aplicaciones de descarga no relacionadas, porque los paquetes ACK del cliente no llegan a tiempo al servidor de Internet.
El DSL Reports Speedtest [11] es una prueba fácil de usar que incluye una puntuación de bufferbloat. El ICSI Netalyzr [12] era otra herramienta en línea que podía usarse para verificar la presencia de bufferbloat en las redes, además de verificar muchos otros problemas de configuración comunes. [13] El servicio se cerró en marzo de 2019. El sitio web bufferbloat.net enumera herramientas y procedimientos para determinar si una conexión tiene un exceso de almacenamiento en búfer que la ralentizará. [14] [15]
Existen varias soluciones técnicas que se pueden agrupar en dos categorías: soluciones dirigidas a la red y soluciones dirigidas a los puntos finales. Los dos tipos de soluciones suelen ser complementarios. A veces, el problema surge con una combinación de rutas de red rápidas y lentas.
Las soluciones de red generalmente toman la forma de algoritmos de gestión de colas. Este tipo de solución ha sido el foco del grupo de trabajo AQM del IETF . [16] Ejemplos notables incluyen:
Ejemplos notables de soluciones dirigidas a los puntos finales son:
El problema también se puede mitigar reduciendo el tamaño del búfer en el sistema operativo [10] y el hardware de red; sin embargo, esto a menudo no es configurable y el tamaño óptimo del búfer depende de la velocidad de línea, que puede diferir para diferentes destinos.
El uso de DiffServ (y el empleo de múltiples colas basadas en prioridades) ayuda a priorizar la transmisión de tráfico de baja latencia (como VoIP, videoconferencias, juegos), relegando la congestión y el buffering al tráfico no priorizado. [21]
Para que las conexiones TCP con retardo más largo sigan obteniendo su parte justa del ancho de banda, el tamaño del búfer debe ser al menos el producto del retardo del ancho de banda dividido por la raíz cuadrada del número de transmisiones simultáneas. [22] [4] Una regla general típica es 50 ms de datos de velocidad de línea, [23] pero algunos conmutadores populares de consumo solo tienen 1 ms, [24] lo que puede resultar en una pérdida adicional de ancho de banda en las conexiones con retardo más largo en caso de que de discordia local con otros.