Inflamación del búfer

Es posible que algunas de las fuentes mencionadas en este artículo no sean confiables . Ayúdenos a mejorar este artículo buscando fuentes mejores y más confiables. Las citas no confiables pueden ser cuestionadas y eliminadas. ( Abril de 2020 ) ( Aprenda cómo y cuándo eliminar este mensaje )

El bufferbloat es una causa de alta latencia y fluctuación en redes de conmutación de paquetes causada por el almacenamiento en búfer excesivo de paquetes . El bufferbloat también puede causar variación de retardo de paquetes (también conocido como fluctuación), así como reducir el rendimiento general de la red . Cuando un enrutador o conmutador está configurado para usar búferes 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 común .

Algunos fabricantes de equipos de comunicaciones han diseñado búferes innecesariamente grandes en algunos de sus productos de red . En estos equipos, el búfer se hincha cuando un enlace de red se congestiona , lo que hace que los paquetes queden en cola durante largos períodos en estos búferes de gran tamaño. En un sistema de colas de tipo "primero en entrar, primero en salir" , los búferes demasiado grandes dan lugar a 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 del bufferbloat fue descrito ya en 1985. ^[1] Ganó mayor atención a partir de 2009. ^[2]

Según algunas fuentes, la causa más frecuente de latencia alta ("lag") en los videojuegos en línea es el exceso de capacidad del búfer de la red doméstica local. Una latencia alta puede hacer que los juegos en línea modernos sean imposibles. ^[3]

Una regla general establecida para los fabricantes de equipos de red era proporcionar buffers lo suficientemente grandes como para albergar al menos 250  ms de almacenamiento en búfer 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 búferes puede provocar un fallo del algoritmo de control de congestión TCP . Los búferes tardan un tiempo en vaciarse, antes de que el control de congestión se restablezca y la conexión TCP vuelva a alcanzar la velocidad necesaria y llene los búferes de nuevo. ^[5] Por lo tanto, el búfer inflado causa problemas como una latencia alta y variable, y cuellos de botella de la red que obstruyen a todos los demás flujos, ya que el búfer se llena con los paquetes de un flujo TCP y luego se descartan otros paquetes. ^[6]

Un buffer inflado tiene efecto solamente cuando este buffer se usa realmente. En otras palabras, los buffers sobredimensionados tienen un efecto dañino solamente cuando el enlace que almacenan se convierte en un cuello de botella. El tamaño del buffer que sirve a un cuello de botella se puede medir usando la utilidad ping provista por la mayoría de los sistemas operativos. Primero, se debe hacer ping al otro host continuamente; luego, se debe iniciar y detener una descarga de varios segundos desde él unas cuantas veces. Por diseño, el algoritmo de prevención de congestión 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 requerida ]}

En el ejemplo anterior, el uso de una herramienta de traceroute avanzada en lugar del simple ping (por ejemplo, MTR ) no solo demostrará la existencia de un buffer inflado en el cuello de botella, sino que también señalará su ubicación en la red. Traceroute logra esto mostrando la ruta (path) y midiendo los retrasos de 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 (path). ^[7]

La mayoría de los algoritmos de control de congestión TCP se basan en la medición de la ocurrencia de pérdidas 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 perderse, y luego reducen la velocidad de transmisión. Lo ideal es que sigan ajustando la velocidad de transmisión hasta que alcance una velocidad de equilibrio del enlace. Para que los algoritmos puedan seleccionar una velocidad de transferencia adecuada, la retroalimentación sobre las pérdidas de paquetes debe producirse de manera oportuna. Con un búfer grande que se ha llenado, los paquetes llegarán a su destino, pero con una latencia más alta. Los paquetes no se han perdido, por lo que TCP no reduce la velocidad una vez que se ha saturado el enlace ascendente, llenando aún más el búfer. Los paquetes recién llegados se descartan solo 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 volver a realizar 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 ser transmitidos; en situaciones problemáticas, los paquetes se descartan solo si el búfer está lleno. En los enrutadores más antiguos, los búferes eran bastante pequeños, por lo que se llenaban rápidamente y, por lo tanto, los paquetes comenzaron a descartarse poco después de que el enlace se saturara, de modo que el protocolo TCP pudiera ajustarse y el problema no se hiciera evidente. En los enrutadores más nuevos, los búferes se han vuelto lo suficientemente grandes como para contener varios segundos de datos almacenados en búfer. Para TCP, un enlace congestionado puede parecer que funciona normalmente mientras el búfer se llena. 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 se descartan los paquetes.

Todos los paquetes que pasan por 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 por un búfer lleno se verá afectada. El ancho de banda del canal disponible también puede terminar sin usarse, ya que es posible que no se llegue rápidamente a algunos destinos rápidos debido a que los búferes están obstruidos con datos que esperan ser entregados a destinos lentos. Estos efectos perjudican la interactividad de las aplicaciones que utilizan otros protocolos de red , incluido el UDP utilizado en aplicaciones sensibles a la latencia como VoIP y juegos en línea. ^{[9] [ fuente autopublicada ]}

Independientemente de los requisitos de ancho de banda, cualquier tipo de servicio que requiera una latencia baja constante o una transmisión sin fluctuaciones puede verse afectado por el bufferbloat. Dichos servicios incluyen llamadas de voz digitales (VOIP), juegos en línea, chat de video 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 un flujo de descarga TCP depende de los paquetes de reconocimiento (ACK) en el flujo de carga, un problema de bufferbloat en la carga puede provocar el fallo de 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 para el 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 buffering que la ralentizará. ^{[14] [15]}

Existen varias soluciones técnicas que pueden agruparse en dos categorías: soluciones que apuntan a la red y soluciones que apuntan a los puntos finales. Los dos tipos de soluciones suelen ser complementarios. El problema a veces surge con una combinación de rutas de red rápidas y lentas.

Las soluciones de red generalmente adoptan la forma de algoritmos de gestión de colas. Este tipo de solución ha sido el foco del grupo de trabajo AQM de la IETF . ^[16] Algunos ejemplos notables incluyen:

• Para limitar la longitud de la cola IP, consulte Ajuste de TCP
• Algoritmos AQM como CoDel y PIE. ^[17]
• Algoritmos híbridos de AQM y programación de paquetes como FQ-CoDel . ^[18]
• Modificaciones al estándar DOCSIS ^[19] para permitir un control de búfer más inteligente en módems de cable . ^[10]
• Integración de la gestión de colas ( FQ-CoDel ) en el subsistema Wi-Fi del sistema operativo Linux , ya que Linux se utiliza comúnmente en puntos de acceso inalámbricos . ^[20]

Algunos ejemplos notables de soluciones dirigidas a los puntos finales son:

• El algoritmo de control de congestión BBR para TCP.
• El protocolo de microtransporte empleado por muchos clientes de BitTorrent .
• Técnicas para utilizar menos conexiones, como la canalización HTTP o HTTP/2 en lugar del protocolo HTTP simple. ^[10]

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 de búfer óptimo depende de la velocidad de la 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 gestión de la congestión y el exceso de buffer al tráfico no priorizado. ^[21]

Para que las conexiones TCP con el retraso 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 ancho de banda por el retraso dividido por la raíz cuadrada del número de transmisiones simultáneas. ^{[22] [4]} Una regla general es 50 ms de datos de velocidad de línea, ^[23] pero algunos conmutadores populares de grado de consumidor solo tienen 1 ms, ^[24] lo que puede resultar en una pérdida de ancho de banda adicional en las conexiones con retraso más largo en caso de contención local con otros.

• Producto ancho de banda-retardo
• Ventana de congestión
• Notificación explícita de congestión
• Bloqueo de cabecera
• Pérdida de paquetes

• BufferBloat: ¿Qué le pasa a Internet? Una conversación con Vint Cerf , Van Jacobson , Nick Weaver y Jim Gettys
• Charla técnica de Google en YouTube , abril de 2011, por Jim Gettys, introducción de Vint Cerf
• Bufferbloat: Buffers oscuros en Internet: demostraciones solo en YouTube , abril de 2011, por Jim Gettys , introducción de Vint Cerf
• Bufferbloat: búferes oscuros en Internet: demostraciones y debates en YouTube Demostración y explicación de 21 minutos de un búfer de banda ancha típico
• LACNIC - BufferBloat en YouTube Mayo 2012, por Fred Baker (presidente de IETF) en español, diapositivas en inglés disponibles [1]
• Dimensionamiento del TSO y el programador FQ (Jonathan Corbet, LWN.net )