Llegamos a ustedes gracias a:



Reportajes y análisis

La causa oculta de una Internet lenta y cómo solucionarla

El culpable es un fenómeno relacionado con TCP conocido como bufferbloat.

[22/09/2016] En el 2010, Jim Gettys, un programador informático veterano que actualmente trabaja en Google, estaba en casa subiendo un archivo grande a su servidor de trabajo. Sus niños llegaron a su despacho y le dijeron: "Papá, el Internet está lento". Preguntándose si su actividad de subida podría estar afectando a las descargas de sus hijos, empezó a investigar.

Al experimentar con pings y varios niveles de carga en su conexión a Internet, descubrió que las latencias eran a menudo de cuatro a 10 veces más grandes de lo esperado. El fenómeno se denomina "bufferbloat". Su conclusión fue que los paquetes de datos críticos estaban atrapados en buffers que eran excesivamente grandes.

Desde el momento en que Gettys hizo su observación y comenzó a darla a conocer, los investigadores de compañías como Cisco y Google, grupos de estándares como el IETF y las principales universidades de investigación, han estado investigando, probando, y escribiendo sobre el bufferbloat. También llevamos a cabo nuestras propias pruebas sencillas. El bufferbloat es real. Lo que no se entiende por completo es el alcance de su impacto en el flujo normal del tráfico de Internet.

Entonces, ¿quién es el más afectado por este fenómeno?

Cualquier persona que está navegando activamente o utilizando motores de búsqueda. Además, cualquier persona que está utilizando aplicaciones en tiempo real como voz o video. Un ejemplo podrían ser los empleados que trabajan desde su casa, en los hoteles o en los puntos de acceso Wi-Fi. Nuestra investigación mostró que los hoteles y cafés Wi-Fi son propensos a problemas serios de bufferbloat.

¿Qué tipo de tráfico se ve afectado?

El tráfico que fluye en los enlaces que tienen una alta utilización de ancho de banda en la dirección opuesta se deteriorará. Las aplicaciones que utilizan pequeños paquetes, tales como VoIP, DNS y ARP también pueden sufrir. El impacto sobre la VoIP aumentará la latencia y oscilaciones. Las consultas DNS pueden ser devueltas en dos a ocho veces el tiempo de respuesta normal.

¿Cómo pudo mantenerse oculto tanto tiempo un problema que afecta al funcionamiento de Internet?

Hay tres razones principales. En primer lugar, la cuestión está estrechamente ligada a la forma en que opera el protocolo TCP y cómo se gestionan los buffers de red. Ninguno de estos se entiende en sentido amplio. En segundo lugar, existe la creencia generalizada de que dejar paquetes de Internet es siempre algo malo. La verdad es que dejar paquetes es absolutamente esencial para el correcto funcionamiento del TCP. En tercer lugar, hay una gran convicción de que la forma de eliminar casi cualquier deterioro en el rendimiento es agregar ancho de banda.

Así que, ¿qué es exactamente bufferbloat?

En un intento de reducir la pérdida de paquetes en Internet, los operadores de redes, desarrolladores e ingenieros han aumentado el tamaño de los buffers de red muchas veces. Esto aumenta la latencia, pero tiene poco efecto en el rendimiento. En consecuencia, los pequeños paquetes críticos como los de VoIP, DNS y TCP 'ACK' pueden quedar atrapados en los buffers detrás de paquetes de transferencia de archivos y otras transferencias a granel mucho más grandes, como el video de tasa de bits adaptativa.

Hay un problema de percepción relacionado con la gestión de memoria intermedia. Las pruebas, libros blancos e incluso instructores a menudo describen a los buffers como pequeños trozos de memoria. Más a menudo, los buffers pueden contener cientos, e incluso miles, de paquetes en cualquier instante.

Y, no están solo en los dispositivos de red. También se encuentran en la pila de protocolo de la estación final, el controlador de tarjeta de red y cada puerta de enlace en el camino entre las estaciones finales.

¿Cuál es el impacto de bufferbloat en la operación de TCP?

La gran mayoría de nuestro tráfico de red utiliza TCP como protocolo de transporte. La comprensión de cómo funciona TCP revela por qué bufferbloat es un problema. Cuando se establece una conexión TCP, hay un enlace de tres vías en las que las entidades TCP que envían y reciben negocian los parámetros para el intercambio, incluidos los números de secuencia inicial.

Digamos que a un servidor FTP se le ha pedido transferir un archivo grande. TCP típicamente comienza su transferencia mediante el envío de cuatro segmentos y espera el reconocimiento de su entrega. La política de reconocimiento habitual es enviar un 'acuse de recibo' después de cada segmento recibido.

Cuando se reciben los cuatro segmentos, el receptor aumenta la tasa de emisión mediante el envío de ocho segmentos, y espera acuses de recibo. Después de saber que se han recibido los segmentos, la tasa de envío aumenta a 16 y así sucesivamente.

Esta fase de entrega es conocida como inicio lento. La idea es saturar el enlace con los paquetes. Sin embargo, a un nivel llamado el umbral de inicio lento, el remitente aumenta la tasa más lentamente mediante la adición de un segmento a la vez en cada ronda, en lugar de duplicar la velocidad.

Sin embargo, habrá un punto crítico en el que se sobrecargará la conexión debido a que un buffer se llena en exceso. Uno o más paquetes serán dados de baja.

Cuando el remitente detecta que esto ha ocurrido, por lo general, reduce su tasa de envío a la mitad y reinicia el comienzo lento. Finalmente, la tasa de TCP se adaptará a la capacidad del circuito que se utiliza. Este conjunto combinado de pasos se conoce como el algoritmo de control de congestión TCP.

Entonces, ¿cómo interfiere bufferbloat?

Vamos a considerar una conexión entre un enlace de alta velocidad y un enlace de baja velocidad. Esta es una situación en la que los buffers se consideran críticos. Por ejemplo, supongamos que tenemos 1Gbps en un gateway residencial como un módem de cable o DSL. Además, supongamos que el módem está conectado a una conexión ISP que proporciona 10Mbps de bajada y 2Mbps de subida.

El servidor FTP llenará el buffer ingresando a la conexión rápida con mayor rapidez que la tasa de egreso en el enlace más lento. Es la velocidad a la que se devuelven las notificaciones de recibo las que en última instancia determinan la velocidad a la que el remitente puede transmitir.

Sin embargo, si ese búfer es grande, pueden ocurrir dos cosas. En primer lugar, si la memoria intermedia se llena, el último paquete en llegar se deja caer. Esto se conoce como caída de la cola. El acuse de recibo que informa al remitente de esta caída no se enviará hasta que el siguiente paquete (después del que se ha descartado) llega y es declarado fuera de orden.

Podría tomar un tiempo considerable para que llegue a través del búffer más grande. Algunos experimentos que hicimos con tasa de bits adaptativa de video mostraron que cerca de 200 segmentos podrían ser entregados antes de que la estación emisora retransmita el segmento caído.

Además, si hay múltiples flujos que entran en ella, la cola puede evolucionar en una cola detenida. Es decir, se puede llegar a un estado de equilibrio en el que hay un número fijo o casi fijo de paquetes en la cola. Si esta cantidad no es suficiente para llenar en exceso la memoria intermedia, no se descarta ningún paquete y el control de congestión de TCP es derrotado. Sin embargo, se ha incrementado la latencia para todos los usuarios de la memoria intermedia.

La gestión de buffers

Desde hace algún tiempo, ha habido una conciencia de que las colas de red deben ser gestionadas. Para agregar prioridad a la circulación de determinado tráfico, los bits de capa DiffServ de IP se pueden configurar para poner en práctica una política que da preferencia a determinados tipos de tráfico, como el control de la red o VoIP. Logran esto mediante la separación de los tipos de tráfico en colas separadas.

Pero, esto no elimina el bufferbloat. Algunas colas que contienen el tráfico no priorizado siguen teniendo el problema de ser demasiado grandes. Estos a menudo contienen muchos segmentos TCP de gran tamaño. Por lo tanto, todavía tenemos el problema de los efectos negativos sobre el mecanismo de congestión de TCP.

Varias técnicas de gestión de cola activa (AQM) que se han incorporado incluyen RED (Descarte temprano aleatorio) y WRED (RED ponderada). Éstas fueron diseñadas para descartar los paquetes cuando la memoria intermedia alcanza un nivel crítico, pero no está necesariamente llena. Sin embargo, estas técnicas fueron defectuosas y la configuración de RED demostró ser difícil. En consecuencia, RED y WRED no se aplican ampliamente. Lo que se necesitaba era un método automático.

En el 2012, Kathie Nichols y Van Jacobsen comenzaron a promover una técnica llamada CODEL o el control de retardo en la cola. Este método maneja una cola mediante el seguimiento del tiempo que un paquete está en la cola, ya que los tiempos de la ocupación en la cola es realmente la cuestión crucial.

Hay dos parámetros críticos, el intervalo y el umbral. Si un valor de intervalo de paquetes tiene más retrasos que destinos, los paquetes se reducen al azar. Tenga en cuenta que esta técnica no depende del tamaño de la cola.

Al probar el procedimiento mostró un mejor comportamiento de la latencia general que RED y resultados mucho mejores. Esto fue especialmente cierto con los enlaces de acceso inalámbricos. Además, la técnica prometía ser fácil de encajar en el hardware.

La siguiente recomendación para la mitigación de bufferbloat vino de Dave Taht, Eric Dumazet, Jim Gettys y algunos otros. Llamado fq-CODEL, pretende proporcionar un impacto más uniforme en los diversos flujos a través de la cola. Incluso Kathie Nichols y Van Jacobson están abogando por el uso de fq-CODEL.

Este método separa la cola en 1024 sub-colas por omisión. A continuación, asigna de manera aleatoria cada nuevo flujo a una cola separada. Dentro de cada sub cola, se aplica Codel para ayudar con el control de congestión de TCP. La política de cola se basa en DRR (Déficit de Round Robin).

¿Qué hacen Codel y fq-CODEL?

En primer lugar, se aseguran de que las funciones de control de congestión de TCP sean como se han diseñado. En segundo lugar, mediante la mezcla de los paquetes en las colas, los pequeños paquetes críticos, tales como respuestas DNS y TCP no se quedan atrapadas en grandes colas. En otras palabras, hace que el tratamiento de los paquetes grandes y pequeños sea más equitativo. Muchas investigaciones han demostrado los beneficios del uso de fq-CODEL. De hecho, está en las últimas distribuciones de Linux.

¿A dónde vamos desde aquí?

Por desgracia, la toma de conciencia sobre el bufferbloat todavía no se ha generalizado. Necesitamos más operadores y usuarios de la red para ejecutar pruebas fácilmente disponibles como ICSI Netylyzr, y la prueba en SpeedTest.

Entonces, si detecta un problema importante con bufferbloat, tiene varias alternativas:

  • Cambiar el hardware de acceso a los dispositivos que utilizan una nueva distribución de Linux que contiene fq-CODEL. Asegúrese de que la función esté activada.
  • Coloque un dispositivo entre la computadora y el gateway/router que tiene la capacidad fq-CODEL encendida. Eso va a limitar el uso de grandes cantidades de memoria del router.
  • Si todo lo demás falla, aplique la limitación de velocidad para enlaces ascendentes y enlaces de descarga a algo un poco menos de su capacidad nominal. Esto ayudará a eliminar grandes cantidades de memoria. Le costará una pequeña disminución en el rendimiento con una carga ligera. Sin embargo, debe mejorar dramáticamente los flujos críticos tales como DNS, ARP, y reconocimientos TCP.

Hay varios proveedores muy interesados en la mitigación del bufferbloat. Cisco, en asociación con Comcast, ha adoptado una técnica de gestión de colas llamada PIE (controlador proporcional integral mejorado) desarrollado principalmente por el distinguido ingeniero de Cisco, Rong Pan.

El cable Time-Warner parece estar bien versado en el tema y se prepara para dar pasos hacia el alivio del bufferbloat. Actiontec, un importante proveedor de pasarelas residenciales para Verizon y Centurylink, ha estudiado el bufferbloat. Dicen que están tomando medidas para mitigar sus efectos. Ruckess Wireless, un socio de Juniper, está comprometido con la mejora continua del problema de amortiguación del enlace de acceso.

Sin embargo, algunos proveedores con los que hablamos parecían desconocer el tema. Otros, como Cox Cable, dijeron que la cuestión dependía de los fabricantes de hardware y silicio. Por desgracia, la mayoría de los principales fabricantes de equipos de prueba de la red que contactamos parecían también desconocer el tema.

Esta situación tiene que cambiar. Es fundamental entender que el rendimiento global no es el factor más significativo en detrimento, sobre todo con actividades como la navegación. El factor más importante es el retraso.

Las respuestas con los comandos HTTP GET son a menudo transferencias de archivos cortos a ráfagas, donde el proceso de arranque lento apenas empieza hasta que se termina. Por lo tanto, el retraso en el establecimiento de sesión y la terminación se convierte en una influencia significativa en la duración de la sesión. Además, una visita típica a un popular sitio web con frecuencia puede tener intercambios del 10 a 25 consultas/respuestas DNS que preceden a los comandos GET. Si éstos son frenados por un factor de tres, debido a bufferbloat, sin duda lo notará.

Es muy recomendable que los operadores de redes estudien la gran cantidad de investigación ya disponible sobre el tema de bufferbloat. Luego, las conexiones de red críticas, tales como puntos de acceso inalámbricos y móviles, tienen que ser puestas a prueba para bufferbloat. Es probable que desee tener los datos de estos ensayos para hablar con su proveedor de servicios o punto de acceso inalámbrico.

Phil Hippensteel, Network World (EE.UU.)

Hippensteel es profesor, consultor y escritor con más de 40 años de experiencia en la educación superior.