Bufferbloat es una causa de alta latencia en redes de conmutación de paquetes causada por un exceso de almacenamiento en búfer de paquetes . Bufferbloat también puede causar una variación de retardo de paquetes (también conocida como jitter), 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), juegos en línea e incluso navegación web normal.
Algunos fabricantes de equipos de comunicaciones diseñaron búferes innecesariamente grandes en algunos de sus productos de red . En dicho equipo, el bloqueo de búfer se produce cuando un enlace de red se congestiona , lo que hace que los paquetes se pongan en cola durante largos períodos en estos búferes de gran tamaño. En un sistema de colas de primero en entrar, primero en salir , los búferes demasiado grandes dan como resultado colas más largas y una mayor latencia, y no mejoran el rendimiento de la red.
El fenómeno bufferbloat se describió ya en 1985. [1] Ganó una atención más generalizada a partir de 2009. [2]
Buffering
Una regla general establecida para los fabricantes de equipos de red era proporcionar búferes lo suficientemente grandes para acomodar 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 de 32 MB relativamente grande . [3] Tal dimensionamiento de los búferes puede provocar fallas en el algoritmo de control de congestión de TCP . Luego, los búferes tardan un tiempo en drenarse, antes de que se restablezca el control de congestión y la conexión TCP vuelva a acelerar y llene los búferes nuevamente. [4] Bufferbloat causa problemas como latencia alta y variable, y obstruye los cuellos de botella de la red para todos los demás flujos a medida que el búfer se llena de paquetes de un flujo TCP y luego se eliminan otros paquetes. [5]
Un búfer inflado tiene efecto solo cuando este búfer se usa realmente. En otras palabras, los búferes de gran tamaño tienen un efecto dañino solo cuando el enlace que almacenan en búfer 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 de ping proporcionada por la mayoría de los sistemas operativos. Primero, se debe hacer ping al otro host de forma continua; luego, debe iniciarse y detenerse varias veces una descarga de varios segundos. Por diseño, el algoritmo de prevención de 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 búfer 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 búfer en el cuello de botella, el aumento máximo proporciona una estimación aproximada de su tamaño en milisegundos. [ cita requerida ]
En el ejemplo anterior, el uso de una herramienta avanzada de rastreo de ruta 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). [6]
Mecanismo
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, 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 retroalimentación sobre las caídas de paquetes debe ocurrir 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 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 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 emprender la búsqueda más agresiva de un nuevo punto operativo. [7]
Los paquetes se ponen en cola dentro de un búfer de red antes de transmitirse; 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 caer poco después de que el enlace se saturara, por lo que el protocolo TCP podría ajustarse y el problema no se haría evidente. En los enrutadores más nuevos, los búferes se han vuelto lo suficientemente grandes para contener varios segundos de datos almacenados en búfer. Para TCP, un enlace congestionado puede parecer que funciona normalmente a medida que se llena el búfer. El algoritmo TCP no sabe que el enlace está congestionado y no comienza a tomar medidas correctivas hasta que el búfer finalmente se desborda y los paquetes se eliminan.
Todos los paquetes que pasan por un búfer simple implementado como una sola cola 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 de canal disponible también puede terminar sin usarse, ya que algunos destinos rápidos pueden no ser alcanzados rápidamente debido a que los búferes están obstruidos con datos que esperan ser enviados 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. [8] [ fuente autoeditada ]
Impacto en las aplicaciones
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. Los ejemplos incluyen llamadas de voz, juegos en línea, chat de video y otras aplicaciones interactivas como mensajería instantánea , transmisión de radio , video a pedido e inicio de sesión remoto .
Cuando el fenómeno del bufferbloat está presente y la red está bajo carga, incluso las cargas normales de una página web pueden tardar varios segundos en completarse, o las consultas de DNS simples pueden fallar debido a los tiempos de espera. [9] En realidad, cualquier conexión TCP puede agotarse y desconectarse, y los paquetes UDP pueden perderse. Dado que la continuación de un flujo de descarga TCP depende de los paquetes ACK en el flujo de carga, un problema de bloqueo de búfer en la carga puede causar fallas en otras aplicaciones de descarga no relacionadas, porque los paquetes ACK no llegan a tiempo al servidor de Internet. Por ejemplo, puede limitar la velocidad de transmisión de una sincronización de OneDrive de carga para no molestar a otros usuarios de la red doméstica .
Herramientas diagnosticas
DSL Reports Speedtest [10] es una prueba fácil de usar que incluye una puntuación de bufferbloat. El ICSI Netalyzr [11] era otra herramienta en línea que podía usarse para verificar la presencia de bufferbloat en las redes, junto con la verificación de muchos otros problemas de configuración comunes. [12] 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á. [13] [ fuente autoeditada ]
Soluciones y mitigaciones
Existen varias soluciones técnicas que pueden agruparse en dos categorías: soluciones que se dirigen a la red y soluciones que se dirigen 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 adoptan la forma de algoritmos de gestión de colas. Este tipo de solución ha sido el foco del grupo de trabajo IETF AQM. [14] Ejemplos notables incluyen:
- Algoritmos AQM como CoDel y PIE. [15]
- AQM híbrido y algoritmos de programación de paquetes como FQ-CoDel. [dieciséis]
- Enmiendas al estándar DOCSIS [17] para permitir un control de búfer más inteligente en módems de cable . [9]
- Integración de la gestión de colas (FQ-CoDel) en el subsistema WiFi del sistema operativo Linux , ya que Linux se usa comúnmente en puntos de acceso inalámbricos . [18]
Ejemplos notables de soluciones dirigidas a los puntos finales son:
- El algoritmo de control de congestión BBR para TCP.
- El protocolo de micro transporte empleado por muchos clientes de BitTorrent .
- Técnicas para usar menos conexiones, como canalización HTTP o HTTP / 2 en lugar del protocolo HTTP simple. [9]
El problema también puede mitigarse reduciendo el tamaño del búfer en el sistema operativo [9] 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 la línea, que puede diferir para diferentes destinos.
DiffServ no resuelve ni puede evitar el problema del bufferbloat, ya que todos los paquetes se ven afectados una vez que ocurre el problema. [19]
Ver también
- Producto de retardo de ancho de banda
- Ventana de congestión
- Notificación de congestión explícita
- Bloqueo de cabecera
- Paquete perdido
Referencias
- ^ "En conmutadores de paquetes con almacenamiento infinito" . 31 de diciembre de 1985.
- ^ van Beijnum, Iljitsch (7 de enero de 2011). "Comprensión de Bufferbloat y la carrera armamentista de la red" . Ars Technica . Consultado el 12 de noviembre de 2011 .
- ^ Guido Appenzeller; Isaac Keslassy; Nick McKeown (2004). "Dimensionamiento de búferes de enrutador" (PDF) . ACM SIGCOMM . ACM . Consultado el 15 de octubre de 2013 .
- ^ Nichols, Kathleen ; Jacobson, Van (6 de mayo de 2012). "Controlar el retraso de la cola" . Cola de ACM . Publicaciones ACM . Consultado el 27 de septiembre de 2013 .
- ^ Gettys, Jim (mayo-junio de 2011). "Bufferbloat: Dark Buffers en Internet" . Computación por Internet IEEE. IEEE. págs. 95–96. doi : 10.1109 / MIC.2011.56 . Archivado desde el original el 12 de octubre de 2012 . Consultado el 20 de febrero de 2012 .
- ^ "traceroute (8) - página de manual de Linux" . die.net . Consultado el 27 de septiembre de 2013 .
- ^ Jacobson, Van; Karels, MJ (1988). "Evitación y control de la congestión" (PDF) . Revisión de comunicación informática ACM SIGCOMM . 18 (4). Archivado desde el original (PDF) el 22 de junio de 2004.
- ^ "Introducción técnica al Bufferbloat" . Bufferbloat.net . Consultado el 27 de septiembre de 2013 .
- ^ a b c d Gettys, Jim; Nichols, Kathleen (enero de 2012). "Bufferbloat: Dark Buffers en Internet" . Comunicaciones de la ACM. 55 (1). ACM: 57–65. doi : 10.1145 / 2063176.2063196 . Consultado el 28 de febrero de 2012 . Cite journal requiere
|journal=
( ayuda ) - ^ "Prueba de velocidad: ¿qué tan rápido es Internet?" . dslreports.com . Consultado el 26 de octubre de 2017 .
- ^ "ICSI Netalyzr" . berkeley.edu . Archivado desde el original el 7 de abril de 2019 . Consultado el 30 de enero de 2015 .
- ^ "Comprensión de los resultados de Netalyzr" . Consultado el 26 de octubre de 2017 .
- ^ "Pruebas de Bufferbloat" . bufferbloat.net . Consultado el 26 de octubre de 2017 .
- ^ "Grupo de trabajo IETF AQM" . ietf.org . Consultado el 26 de octubre de 2017 .
- ^ Pan, Rong; Natarajan, Preethi; Piglione, Chiara; Prabhu, Mythili; Subramanian, Vijay; Baker, Fred; VerSteeg, Bill (2013). PIE: un esquema de control ligero para abordar el problema del bloqueador de búfer . 2013 IEEE 14th International Conference on High Performance Switching and Routing (HPSR). IEEE. doi : 10.1109 / HPSR.2013.6602305 .
- ^ Høiland-Jørgensen, Toke; McKenney, Paul; Taht, Dave; Gettys, Jim; Dumazet, Eric (18 de marzo de 2016). "El programador de paquetes FlowQueue-CoDel y el algoritmo de gestión de cola activa" . Consultado el 28 de septiembre de 2017 .
- ^ "Función" de control de búfer ascendente "DOCSIS" . CableLabs. págs. 554–556 . Consultado el 9 de agosto de 2012 .
- ^ Høiland-Jørgensen, Toke; Kazior, Michał; Täht, Dave; Hurtig, Per; Brunstrom, Anna (2017). Poner fin a la anomalía: lograr baja latencia y equidad en el tiempo de uso en WiFi . 2017 Conferencia Técnica Anual de USENIX (USENIX ATC 17). USENIX - Asociación de sistemas informáticos avanzados. págs. 139-151. ISBN 978-1-931971-38-6. Consultado el 28 de septiembre de 2017 . código fuente .
- ^ Hein, Mathias. "Bufferbloat» ADMIN Magazine " . Revista ADMIN . Consultado el 11 de junio de 2020 .
enlaces externos
- BufferBloat: ¿Qué le pasa a Internet? Una discusión con Vint Cerf , Van Jacobson , Nick Weaver y Jim Gettys
- Google Tech Talk en YouTube , abril de 2011, por Jim Gettys, introducción de Vint Cerf
- Bufferbloat: Dark Buffers in the Internet - Demonstrations Only on YouTube April, 2011, by Jim Gettys , Introduction by Vint Cerf
- Bufferbloat: Dark Buffers en Internet - Demostraciones y debates en YouTube Demostración y explicación de 21 minutos del bufferbloat típico de banda ancha
- LACNIC - BufferBloat en YouTube, mayo de 2012, por Fred Baker (presidente del IETF) en español, diapositivas en inglés disponibles [1]
- Dimensionamiento TSO y programador FQ (Jonathan Corbet, LWN.net )