El almacenamiento en búfer de red excesivo ( ing. Bufferbloat - hinchazón del búfer) es un fenómeno que ocurre en las redes de conmutación de paquetes, cuando el almacenamiento en búfer excesivo provoca un aumento en el tiempo de tránsito del paquete (latencia) y la propagación del retraso del paquete (inestabilidad) y, como resultado, una disminución en rendimiento. El proyecto www.bufferbloat.net burlonamente definió este término como "deterioro en el desempeño de Internet causado por intentos previos de mejorarlo" [1] .
El término Bufferbloat fue acuñado a finales de 2010 por Jim Gettys de Bell Labs , miembro del comité W3C y uno de los editores de la especificación HTTP/1.1 [2] .
El problema del overbuffering ocurre cuando hay un dispositivo con un buffer demasiado grande en la ruta desde el origen hasta el destino de los paquetes. Como regla general, los búferes están presentes en casi todos los nodos de la red: conmutadores, enrutadores, pilas de sistemas operativos, etc. Están diseñados para almacenar temporalmente paquetes "extra" para que no se pierdan cuando el remitente transmite datos al nodo más rápido que él. puede obtener el destinatario. Esto sucede cuando el ancho de banda del emisor es mayor que el del receptor. El almacenamiento en búfer retrasa la transmisión de un paquete unos pocos milisegundos. Si el búfer se llena, se descarta el siguiente paquete. Los protocolos de control de congestión detectan esto en el lado del remitente y reducen la tasa de transmisión. Los datos continúan transmitiéndose utilizando el máximo ancho de banda posible.
Pero si el búfer en algún nodo de la red es demasiado grande, continúa acumulando paquetes durante mucho tiempo. Debido a esta larga pausa, los algoritmos de control de congestión se extravían y no funcionan como deberían. Comienza a ocurrir el fenómeno del retraso de paquetes grandes y variables, los cuellos de botella de la red se "ahogan" debido a un exceso de paquetes de un flujo TCP y se descartan otros paquetes. Hay una congestión. Después de un tiempo, los búferes se liberan, luego la velocidad de transferencia aumenta hasta que los búferes se vuelven a llenar, hasta la próxima congestión.
Desde el punto de vista de los usuarios normales, los principales síntomas de un almacenamiento en búfer de red excesivo son cuando la red está bajo carga (se transfieren muchos datos), las páginas web normales tardan mucho en cargarse (varios segundos o incluso minutos) ; cualquier servicio que requiera un ancho de banda constante (ya sea alto o bajo), como VoIP, juegos en red, chat, aplicaciones interactivas como acceso remoto, se vuelven inutilizables. Los métodos de priorización (QoS), en los que se crea una cola de paquetes separada para un cierto tipo de tráfico, hacen poco para resolver el problema.
El problema del almacenamiento en búfer excesivo lo provocan principalmente los fabricantes de enrutadores, conmutadores y desarrolladores de sistemas operativos, quienes en los últimos años han comenzado a instalar búferes demasiado grandes (varios megas) en los dispositivos, lo que, a su vez, se debe a una fuerte reducción de la costo de la memoria.
El problema se puede resolver simplemente reduciendo el tamaño de los búferes en el equipo de red. Sin embargo, no está configurado en la mayoría de los enrutadores y conmutadores, especialmente si están ubicados fuera del alcance de los usuarios comunes.
El almacenamiento en búfer de red excesivo puede deberse a cualquier servicio o actividad en la red que envíe grandes cantidades de datos o paquetes a través de la red. Entre ellos:
El fenómeno puede ocurrir dondequiera que ocurra el almacenamiento en búfer. En primer lugar, se crea congestión en el nodo después del cual existe el ancho de banda más estrecho. Por ejemplo:
Muchos protocolos y servicios de red sufren congestión y tiempos de respuesta lentos. Por ejemplo:
Sin embargo, se necesitan grandes búferes de red para procesar correctamente los paquetes con una MTU grande , como las tramas gigantes .
El problema de la congestión de la red es un viejo problema de las redes que existe desde los primeros días de su existencia. La congestión de la red provoca la degradación del rendimiento, el aumento del tiempo de tránsito de los paquetes y la pérdida de paquetes. Como resultado de la congestión de la red, algunos servicios de red simplemente dejan de funcionar.
La primera manifestación de congestión de red a gran escala ocurrió en 1986 en NSFNet [3] . En respuesta a este evento, en 1988 se desarrolló el protocolo de control de congestión de Van Jacobson .
Internet siguió creciendo. En 1993, S. Floyd y W. Jacobson desarrollaron el algoritmo RED ( Random Early Detection - Arbitrary Early Detection) para controlar el desbordamiento de las colas de los enrutadores [ 4] .
En 1997 se publicó el RFC 2068 , que formulaba el “principio de las dos conexiones”: un cliente no debe utilizar más de dos conexiones al mismo tiempo con el mismo servidor [5] . Según el mismo RFC, esta recomendación se da “para reducir el tiempo de respuesta de HTTP y evitar una carga excesiva en Internet u otras redes”.
Un año después, sale a la luz el RFC 2309 , "Recomendaciones para la gestión de colas de Internet y la prevención de la congestión", que propone medidas para mejorar y preservar el rendimiento de Internet.
En 2001, se lanzó el RFC 3168 : "Agregar una notificación de congestión explícita (ECN) a IP", que proponía agregar un campo ECN en los paquetes IP y TCP, reservando 2 bits para esto.
En 2004-2007, Comcast, uno de los proveedores de servicios de Internet más grandes de EE. UU., está experimentando dificultades debido a la congestión de la red. Esto se evidencia por los repetidos cierres de Internet para los usuarios "intensos" [6] . Y en 2007, Comcast, según Jim Gettis, se "asfixió" con los bittorrents [7] . La empresa ha sido acusada de bloquear el tráfico de torrents [8] [9] e incluso está siendo demandada [10] .
Según Jim Gettis, la primera persona en descubrir el problema del almacenamiento en búfer de la red fue Dave Clark [7] . En 2004, observó este fenómeno en su DSLAM y lo usó para disuadir a su hijo de jugar largas horas de WOW [11] .
En 2007, el mismo Jim Gettis comienza a recibir quejas de su familia sobre la mala conexión a Internet y experimenta daños en el equipo por sobretensiones [7] .
En 2009, Dave Reed informó que el tiempo de ida y vuelta (RTT) de los paquetes era demasiado alto (hasta 30 segundos) con poca pérdida de paquetes en redes 3G mediante la publicación en la lista de correo de ciclo completo. El propio Jim Gettis grabó en redes 3G RTT hasta 6 segundos.
Gettys continúa recibiendo quejas de la familia sobre la lentitud de Internet. En abril de 2010, realizó una prueba de ancho de banda/latencia [12] . El resultado de la prueba mostró que el tiempo de espera (retraso) de los paquetes aumenta con una transferencia de datos larga. El 15 de julio de 2010, Gettys tuvo un almuerzo conjunto con representantes de Comcast [13] , donde se sugirió la causa del problema: buffers demasiado grandes. El motivo, a su vez, fue propuesto a la empresa por Dave Clark dos años antes, pero la empresa no pudo encontrar pruebas de ello. Otras razones para la sobrecarga del búfer: RED a menudo no se incluye en las redes porque requiere una configuración compleja; Los ECN están bloqueados en algunas redes porque bloquean los enrutadores domésticos.
Gettys continuó su investigación, tomando medidas en casa y en viajes de negocios. La medición del 20 de septiembre mostró un retraso de 8 s en un camino que normalmente se recorre en 10 ms [14] . Luego, Gettis reprodujo esto en otros enrutadores de diferentes fabricantes.
En noviembre, Gettys reprodujo el problema en varios sistemas operativos. Resultó que bajo Linux y Mac este problema es más fácil de reproducir que bajo Windows. Gettys concluyó: “hay algo en las pilas de red de los sistemas operativos” [15] .
3 de diciembre de 2010 Jim Gettis publica el artículo "The criminal mastermind: bufferbloat!" en su blog, donde le da el nombre a este fenómeno - bufferbloat . En este y posteriores artículos, Gettis habla de la esencia del fenómeno, lugares de ocurrencia, causas y consecuencias [16] .
Robert Kringley, un periodista que escribe para InfoWorld, en su artículo "Predicciones de 2011: una palabra - bufferbloat". ¿O son dos palabras? predice que el almacenamiento en búfer de red excesivo será el mayor problema de 2011 [17] . Refiriéndose a Gettys, da una descripción del problema. 3 días después, ars technica publicó un artículo de Ilyich van Beinum, en el que señalaba que algunos de los detalles descritos por Kringley eran incorrectos, pero al mismo tiempo confirmaba la existencia del problema de exceso de buffering en la red [18] .
Pronto se creó un proyecto www.bufferbloat.net Archivado el 4 de diciembre de 2012 en Wayback Machine para coordinar los esfuerzos de las personas interesadas en abordar el problema del almacenamiento en búfer de red excesivo. Las principales tareas del proyecto: