Control de congestión

La congestión comienza cuando el tráfico llega a una parte de una red más rápido de lo que esa parte puede transportarlo durante un período sostenido. Los paquetes esperan en el búfer de salida de un encaminador, llamado cola. El cuello de botella es el enlace con menor capacidad disponible para ese tráfico a lo largo de su trayecto.

Sigue el exceso

Supón que un encaminador recibe 12 Mbps para un enlace de salida que puede enviar 10 Mbps. No puede acelerar la salida para igualar la entrada. Cada segundo quedan 2 megabits esperando, o 250 000 bytes después de dividir entre 8. Si comienza vacío, un búfer de 1 000 000 de bytes se llena en:

Un paquete que se incorpora detrás de esa cantidad de datos en cola espera a que el enlace transmita los datos que tiene delante:

Una vez que el búfer permanece lleno, la salida sigue transportando solo 10 Mbps. Se descartan aproximadamente 2 Mbps de los 12 Mbps que llegan, una sexta parte del tráfico ofrecido. Estos cálculos consideran tasas de llegada y salida constantes; los tiempos de cada paquete añaden pequeñas variaciones.

Decide si la cola se vaciará

Una ráfaga breve es distinta de una sobrecarga sostenida. Una cola puede absorber una ráfaga y vaciarse cuando las llegadas caen por debajo de la tasa de salida. Si las llegadas constantes igualan exactamente la tasa de salida, una cola existente persiste: cada salida se sustituye por una llegada. Las llegadas sostenidas por encima de la tasa de salida hacen que la cola crezca hasta llenar el búfer.

El tráfico real es irregular. Incluso por debajo de la utilización media completa, las ráfagas hacen esperar a los paquetes. Cerca de la capacidad, queda poco tiempo libre para vaciar esas ráfagas, por lo que el retardo medio aumenta bruscamente. La congestión aumenta principalmente el componente de cola del retardo de los paquetes; el procesamiento, la transmisión y la propagación son componentes distintos.

Identifica la tasa a la que te refieres

Una diferencia de velocidades puede poner de manifiesto el cuello de botella: una red local de 1 Gbps puede alimentar un enlace de acceso de 50 Mbps. La agregación tiene el mismo efecto cuando varias entradas de un encaminador comparten una salida. Una sola entrada puede parecer modesta, aunque su suma sobrecargue esa salida.

Elige el límite correcto

El control de flujo protege el búfer del receptor mediante la ventana de recepción que este anuncia. El control de congestión protege el trayecto entre los extremos. Un receptor puede tener amplia memoria libre mientras un encaminador del trayecto descarta paquetes.

Un búfer mayor en el encaminador puede contener una ráfaga más larga, pero una sobrecarga sostenida llena cualquier búfer finito y añade tiempo de espera. Un enlace limitante más rápido elimina esa falta de capacidad. Entonces otro enlace limita el trayecto; solo se congestiona cuando el tráfico supera la capacidad disponible en él.

Un enlace saturado solo es útil cuando su tráfico ayuda a entregar datos nuevos. La congestión consume capacidad de formas que pueden reducir la entrega de datos útiles aunque la red permanezca ocupada.

Cuenta los costes

El retardo de cola aparece primero. Una videollamada puede resultar difícil de seguir antes de que se descarte ningún paquete, porque la voz llega demasiado tarde. La fiabilidad por sí sola no puede corregir ese retardo.

Los paquetes perdidos generan un segundo coste: un emisor que ofrece entrega fiable los retransmite. Si un enlace de 10 Mbps transporta paquetes del mismo tamaño y el 20 % repite datos ya transportados por ese enlace, como máximo 8 Mbps transportan datos nuevos:

El rendimiento útil de la aplicación es menor después de tener en cuenta las cabeceras y las posibles pérdidas en otros puntos. Por tanto, la actividad del enlace exagera el avance realizado por la aplicación.

Algunas retransmisiones son innecesarias. Un paquete puede estar esperando en una cola larga cuando vence el temporizador del emisor. Su sustituto entra entonces en la misma red ocupada. Ambas copias pueden llegar, pero el receptor conserva los datos una sola vez. La espera en cola ha convertido un problema de retardo en carga ofrecida adicional.

Observa los enlaces anteriores a un descarte

Un descarte cerca del destino puede desperdiciar el trabajo de varios enlaces anteriores. Imagina que un paquete atraviesa los enlaces A y B antes de ser descartado en la cola de C. Las transmisiones en A y B utilizaron capacidad sin entregar ese paquete. La repetición de este patrón deja menos capacidad en los enlaces anteriores para tráfico que podría haber llegado a su destino.

A medida que aumenta la carga ofrecida, el rendimiento también aumenta al principio. Sin embargo, con suficientes descartes posteriores, aumentar la carga envía más tráfico a un trabajo que se desperdiciará. El rendimiento de extremo a extremo puede alcanzar un máximo y después bajar. El colapso por congestión es el caso extremo: la carga ofrecida permanece alta mientras el rendimiento útil cae hacia cero.

En octubre de 1986, el rendimiento entre el Laboratorio Lawrence Berkeley y la Universidad de California en Berkeley cayó de 32 kbps a 40 bps, una reducción por un factor de 800. El trabajo de Jacobson y Karels de 1988 introdujo una respuesta coordinada: inicio lento, evitación de la congestión, mejor estimación del tiempo de ida y vuelta y espera exponencial del temporizador. El control de ventana y unos temporizadores adecuados abordan distintas partes del ciclo de realimentación.

Encuentra el intervalo de funcionamiento útil

El codo de la curva y el precipicio de la curva de Raj Jain describen dos límites. Más allá del codo, la carga añadida aporta poco rendimiento adicional pero mucho más retardo. Más allá del precipicio, el rendimiento baja a medida que predominan las pérdidas y el trabajo desperdiciado. El control de congestión busca una entrega eficiente cerca del codo, manteniéndose alejado del colapso.

Internet no tiene un controlador central que asigne una tasa a cada emisor. Cada emisor debe reaccionar a la información que observa. Si uno sigue transmitiendo a una tasa fija alta mientras los demás la reducen, puede quitarles capacidad y agravar la sobrecarga.

La retransmisión hace fiable un flujo de bytes, pero no elimina el coste de las pérdidas. La recuperación consume capacidad y retrasa la entrega de los datos ausentes; esperar a que venza un temporizador de retransmisión puede detener la conexión mucho más tiempo que la recuperación rápida.

Un emisor no ve directamente todas las colas de los encaminadores de su trayecto. El control de congestión es un proceso de realimentación: observar la entrega, decidir qué significan las observaciones y ajustar la cantidad o la tasa del tráfico que entra en la red.

Localiza la fuente de información

En el control de extremo a extremo, los extremos deducen la congestión a partir de pérdidas o retardos sin un mensaje explícito del encaminador. Reno utiliza las pérdidas. Vegas utiliza cambios en el tiempo de ida y vuelta. BBR construye un modelo del trayecto a partir de mediciones de la tasa de entrega y del RTT.

En el control asistido por la red, un encaminador proporciona información explícita. ECN marca un paquete que viaja hacia el receptor, y este comunica la marca en su acuse de recibo. Los mecanismos ATM más antiguos podían comunicar una tasa permitida explícita. Un encaminador también puede enviar un mensaje directamente al emisor, llamado paquete de aviso de congestión. El mensaje ICMP Source Quench de internet usaba ese enfoque y quedó obsoleto en 2012.

Interpreta las señales con cuidado

Con colas de descarte en cola llena, la pérdida normalmente llega después de que se llene el búfer. La gestión activa de colas puede descartar o marcar paquetes antes. Esto cambia el momento en que llega una señal, sin cambiar la necesidad de que el emisor responda.

El RTT mínimo observado es útil porque aproxima el de un trayecto con poca espera en colas. Un RTT superior a ese mínimo sugiere que hay espera, pero un extremo debe interpretar las mediciones a lo largo del tiempo. Ni una sola muestra variable ni cada paquete inalámbrico perdido identifican la causa con certeza.

Controla una ventana o una tasa

Un emisor basado en ventanas limita los datos en vuelo sin acuse de recibo. A medida que regresan los acuses, se abre espacio para datos nuevos. Un emisor basado en la tasa establece una tasa objetivo y suele utilizar el espaciado de paquetes, distribuyéndolos en el tiempo. Los controles están relacionados:

Por ejemplo, 100 000 bytes por cada 50 ms corresponden a 2 000 000 de bytes/s, o 16 Mbps, cuando la ventana es el límite efectivo. Un controlador basado en la tasa también puede utilizar una ventana como límite superior para los datos pendientes.

Equilibra varios objetivos

La eficiencia significa mantener ocupada la capacidad disponible del cuello de botella. La equidad se refiere a cómo la reparten los flujos que compiten. Un retardo bajo requiere colas cortas; la estabilidad evita grandes oscilaciones repetidas; la capacidad de respuesta significa adaptarse cuando cambian la capacidad o la competencia. Una regla que llena rápidamente un trayecto puede, aun así, ser deficiente para mantener bajo el retardo o compartir con otros algoritmos.

El controlador de TCP suele ejecutarse en el sistema operativo. El controlador de QUIC suele ejecutarse en una biblioteca de la aplicación. UDP no proporciona ningún controlador, por lo que las aplicaciones que lo usan deben aportar su propio control de congestión. El protocolo que transporta los datos no elimina la obligación de responder a la congestión.

La ventana de congestión, cwnd, es un límite del emisor para los datos en vuelo sin acuse de recibo. Se mide en bytes, aunque las secuencias suelen contar segmentos de tamaño máximo. No es un campo de la cabecera TCP. El receptor anuncia un límite distinto, la ventana de recepción, rwnd.

Aplica ambos límites

Las nuevas transmisiones deben ajustarse tanto al control de flujo como al control de congestión. El límite utilizable es:

Si cwnd es de 30 000 bytes y rwnd es de 18 000 bytes, rige el límite del receptor. Con 12 000 bytes aún pendientes, el emisor puede enviar otros 6000 bytes. Después de una reducción de la ventana de congestión, los datos existentes pueden superar el nuevo límite; el emisor espera los acuses de recibo antes de añadir más.

El tamaño máximo de segmento, MSS, cuenta los datos de aplicación y excluye las cabeceras. Una MTU Ethernet de 1500 bytes menos las cabeceras IPv4 de 20 bytes y TCP de 20 bytes deja 1460 bytes, sin opciones. Los estándares usan SMSS para el MSS del emisor.

Convierte una ventana en una tasa

Un emisor limitado por la ventana entrega aproximadamente una ventana por RTT. Para una cwnd de 65 536 bytes y un RTT de 50 ms:

Multiplica por 8 para obtener unos 10,5 Mbps. Esta estimación también requiere suficientes datos de aplicación, una ventana de recepción al menos igual de grande y un trayecto capaz de transportar la tasa resultante.

Llena el trayecto sin llenar su cola

El producto ancho de banda-retardo, BDP, es el ancho de banda del cuello de botella multiplicado por el RTT mínimo sin colas. Para 100 Mbps y 40 ms:

Dividir entre 8 da 500 000 bytes, unos 342 segmentos de 1460 bytes. Un BDP en vuelo mantiene ocupado este cuello de botella idealizado sin una cola persistente. Menos datos dejan capacidad inactiva; los datos sobrantes esperan y aumentan el RTT medido. Calcular el BDP a partir de un RTT ya incrementado confunde los datos en cola con los datos que necesita el trayecto.

La temporización mediante ACK ayuda a mantener el ritmo. Cuando los paquetes salen del cuello de botella, los ACK regresan y liberan espacio para sus sustitutos. En régimen estable, las salidas ayudan así a determinar el momento de las nuevas llegadas. Esta es la idea de conservación de paquetes que sustenta el comportamiento de autotemporización de TCP.

Establece el punto de partida y el umbral

La ventana inicial de RFC 5681 va de dos a cuatro segmentos según SMSS: cuatro hasta 1095 bytes, tres hasta 2190 bytes y dos por encima de ese valor. RFC 6928 permite una ventana inicial de hasta diez segmentos. Una secuencia que comienza en un segmento es útil para enseñar, no afirma que todas las conexiones nuevas comiencen ahí.

ssthresh, el umbral de inicio lento, selecciona el modo de crecimiento. Por debajo de él, TCP utiliza el inicio lento; por encima, la evitación de la congestión. Cuando son iguales, RFC 5681 permite cualquiera de los dos. Un umbral inicial alto permite a un emisor nuevo descubrir la capacidad mediante el inicio lento.

TCP debe descubrir primero cuánto tráfico puede transportar el trayecto. El inicio lento amplía la ventana rápidamente desde un punto de partida pequeño. La evitación de la congestión sondea después con más cautela una vez alcanzado el umbral de inicio lento.

Cuenta los acuses de recibo en el inicio lento

RFC 5681 aumenta cwnd hasta en un SMSS por cada acuse de recibo de datos nuevos:

donde N es el número de bytes recién reconocidos. Con un ACK por cada segmento completo y suficientes datos para llenar cada ventana, cada segmento enviado deja espacio para dos en la siguiente ronda: uno de sustitución y otro gracias al aumento de la ventana.

Empezando en 1 MSS, los valores ronda a ronda son 1, 2, 4, 8, 16, 32 y 64 MSS. Se alcanzan 64 MSS en seis RTT. Con 100 ms por RTT, son 0,6 s. El nombre refleja un comienzo más seguro que enviar inmediatamente una ventana de recepción completa; el crecimiento en sí es exponencial.

Los ACK retardados cambian la cuenta. Si el receptor envía un ACK por cada dos segmentos completos, la regla sencilla por ACK produce un crecimiento aproximado de 1,5 veces por RTT. El conteo adecuado de bytes, descrito en RFC 3465, utiliza los bytes recién reconocidos para abordar la dependencia de la frecuencia de los ACK.

Cambia de modo de crecimiento

Para una secuencia con una cwnd inicial de 1 MSS y ssthresh de 8 MSS, elige la evitación de la congestión cuando sean iguales. La secuencia queda así:

Los tres primeros cambios duplican la ventana. Los cambios posteriores añaden un MSS por RTT. Una pérdida puede interrumpir cualquiera de las dos fases. Las implementaciones que usan HyStart++ (RFC 9406) también pueden abandonar el inicio lento antes cuando aumenta el retardo.

Explica el incremento aditivo

Una regla habitual por ACK durante la evitación de la congestión es:

Con 10 MSS, un ACK añade aproximadamente 0,1 MSS. Durante la ronda llegan unos diez ACK, por lo que el aumento total es de aproximadamente un MSS. El incremento por ACK se hace menor a medida que crece cwnd, manteniendo aproximadamente constante el incremento ronda a ronda.

Esta diferencia importa en un trayecto grande. Pasar de 16 a 32 MSS tarda un RTT en el inicio lento ideal, pero dieciséis RTT en la evitación de la congestión. El crecimiento más lento reduce las sobrecargas repentinas una vez que el emisor dispone de una estimación útil de la capacidad.

Reconoce un reinicio

El inicio lento no se limita al comienzo de una conexión. El vencimiento del tiempo de espera de retransmisión restablece cwnd en un segmento. Un período de inactividad superior al tiempo de espera de retransmisión también exige reiniciar desde una ventana no mayor que la ventana inicial, porque la temporización anterior mediante ACK y la estimación de capacidad pueden haber dejado de ajustarse al trayecto.

La evitación de la congestión no mantiene cwnd en un valor seguro fijo. Sigue añadiendo capacidad hasta que llega información sobre congestión. En un trayecto con descarte en cola llena, este sondeo continuo tiende a crear una cola persistente antes de que las pérdidas indiquen al emisor que debe reducir su tasa.

TCP puede deducir que falta un segmento a partir de un temporizador o de acuses de recibo duplicados. La distinción importa: el vencimiento del tiempo de espera ofrece menos indicios de que la red sigue entregando tráfico que tres ACK duplicados.

Establece el nuevo umbral

Reno utiliza la cantidad realmente pendiente, FlightSize, para establecer:

FlightSize suele estar cerca de cwnd durante una transferencia plenamente activa, pero no tienen por qué ser iguales cuando la aplicación envía pocos datos. El límite inferior impide que el umbral caiga por debajo de dos segmentos.

Después del vencimiento del tiempo de espera, el emisor retransmite, fija cwnd en un SMSS y reinicia el inicio lento. Los vencimientos repetidos para los mismos datos duplican el temporizador de retransmisión. Esta espera exponencial impide que un fallo persistente produzca un flujo igualmente persistente de reintentos.

Recupérate antes de que venza el temporizador

Tres ACK duplicados muestran que llegaron tres segmentos posteriores a un hueco. No significan que se hayan perdido tres segmentos. Uno o dos duplicados pueden deberse a una alteración del orden, por lo que TCP espera al tercero antes de que la retransmisión rápida envíe el segmento ausente.

Reno entra entonces en recuperación rápida. Supón que FlightSize es de 12 MSS. El nuevo umbral es 6 MSS y Reno establece temporalmente:

Los tres segmentos adicionales representan los paquetes que, según los indicios, han salido de la red. Cada ACK duplicado adicional infla cwnd en un MSS, lo que permite seguir enviando cuando la ventana lo permite. Cuando un ACK hace avanzar el acuse de recibo acumulativo, Reno desinfla cwnd a 6 MSS y reanuda la evitación de la congestión.

Con una ventana inicial de 1 MSS y un ssthresh de 8 MSS, cwnd crece 1, 2, 4, 8, 9, 10, 11, 12 MSS antes de la pérdida. Reno acaba continuando en 6, 7, 8, 9. Tahoe reinicia en 1, 2, 4, alcanza el nuevo umbral de 6 y después continúa 7, 8.

Repara varios huecos en una ventana

Reno clásico sale de la recuperación con el primer ACK de datos nuevos. Si ese ACK cubre solo parte de los datos originales en vuelo, queda otro hueco. Reno puede volver a reducir la ventana o agotar el tiempo de espera.

NewReno (RFC 6582) permanece en recuperación ante ese ACK parcial y retransmite el siguiente segmento ausente. Sale cuando se reconocen todos los datos pendientes al entrar en recuperación. SACK informa explícitamente de los bloques recibidos; la recuperación basada en SACK puede identificar y reparar varios huecos en un tiempo de ida y vuelta.

Un episodio de congestión normalmente debería causar una reducción, aunque se pierdan varios paquetes. NewReno y la recuperación basada en SACK lo gestionan de forma más fiable que Reno clásico. CUBIC utiliza un factor de reducción distinto para las señales de congestión habituales y conserva el 70 %, pero también reinicia en un segmento después del vencimiento del tiempo de espera.

Reno clásico aumenta repetidamente su ventana y la reduce tras la congestión. El diente de sierra resultante proporciona una estimación útil en régimen estable cuando el RTT es aproximadamente constante, la retransmisión rápida detecta las pérdidas y no hay vencimientos del tiempo de espera ni inicio lento.

Calcula la ventana media

Sea W la ventana máxima en segmentos. Una reducción a la mitad produce un intervalo de W/2 a W, cuya media es 0,75 W. Multiplica por MSS para obtener bytes por tiempo de ida y vuelta y después divide entre el RTT:

Para W de 24 segmentos, MSS de 1460 bytes y RTT de 80 ms, la tasa máxima es de 3,504 Mbps. La media es de unos 2,63 Mbps. Recuerda que una ventana expresada en segmentos necesita un factor correspondiente al tamaño del segmento; una ventana ya expresada en bytes no lo necesita.

Relaciona el rendimiento con las pérdidas

La aproximación de Mathis expresa el mismo comportamiento de tipo Reno mediante la fracción de pérdidas L:

Si MSS se expresa en bytes y RTT en segundos, T se expresa en bytes/s. Con un MSS de 1460 bytes, un RTT de 0,1 s y una fracción de pérdidas de 0,0001, el denominador es 0,001 s. El resultado es 1 781 200 bytes/s, unos 14,25 Mbps después de multiplicar por 8.

Con una fracción de pérdidas fija, duplicar el RTT reduce el rendimiento a la mitad. Con un RTT fijo, duplicar el rendimiento requiere que las pérdidas bajen a una cuarta parte, porque el denominador contiene la raíz cuadrada de las pérdidas. Una fracción de pérdidas de 0,0001 significa 0,01 %, no 0,0001 %.

Examina el problema de las redes de alta velocidad

Un trayecto de 10 Gbps con un RTT sin colas de 100 ms necesita 1 mil millones de bits, o 125 000 000 de bytes, en vuelo para llenarse. Con segmentos de 1500 bytes se obtienen unos 83 333 segmentos. Reducir esa ventana a la mitad deja unos 41 667 segmentos por recuperar. Reno añade uno por RTT, por lo que recuperarlos tarda unos 4167 s, casi 70 minutos.

Ese valor de 83 333 segmentos es la ventana necesaria para enviar a 10 Gbps en un instante. Un diente de sierra de Reno con una media de 10 Gbps necesitaría un máximo mayor porque su ventana media es solo tres cuartas partes del máximo. La fórmula basada en la tasa de pérdidas estima que mantener una media de 10 Gbps con este MSS y RTT requiere una pérdida de alrededor de un segmento por cada 4,7 mil millones.

Comprueba otros límites

Un controlador no puede entregar más rápido que el cuello de botella, y una ventana de recepción pequeña puede limitar antes que cwnd. Utiliza el menor límite aplicable. Los vencimientos del tiempo de espera reducen la tasa por debajo del modelo sencillo, y un objeto pequeño puede terminar por completo durante el inicio lento. Su tiempo de finalización depende mucho de las rondas de arranque y de la ventana inicial, por lo que la fórmula para transferencias de larga duración describe mal esa transferencia.

Por tanto, un enlace de acceso más rápido solo ayuda cuando elimina un límite efectivo. Un RTT largo, las pérdidas o una ventana pequeña pueden dejar una conexión individual muy por debajo de la capacidad del enlace mejorado.

Si K flujos activos quieren más capacidad de la que un cuello de botella puede darles, una parte igual por flujo es R/K, donde R es la tasa disponible. La eficiencia pregunta si sus tasas suman R. La equidad pregunta con qué igualdad se la reparten.

Representa dos tasas en un diagrama

En un diagrama de Chiu–Jain, las coordenadas horizontal y vertical son las tasas de los dos flujos. La recta de eficiencia es:

La recta de equidad es la diagonal donde las tasas son iguales. Su intersección es la asignación equitativa que utiliza toda la capacidad. En un enlace de 10 Mbps es de 5 Mbps por flujo. Los puntos por debajo de la recta de eficiencia dejan capacidad sin utilizar; los puntos por encima ofrecen más tráfico del que el enlace puede transportar.

Distingue las dos actualizaciones

El incremento aditivo añade la misma cantidad a cada tasa. Partiendo de 8 y 1 Mbps, añadir 0,5 Mbps a cada una da 8,5 y 1,5 Mbps. La diferencia sigue siendo de 7 Mbps, pero el flujo menor gana más en relación con su tasa inicial. En el diagrama, el punto se desplaza en paralelo a la diagonal de igualdad.

El decremento multiplicativo multiplica ambas tasas por el mismo factor. Reducir a la mitad 9 y 2 Mbps produce 4,5 y 1 Mbps. Su proporción no cambia, mientras que la diferencia absoluta baja de 7 a 3,5 Mbps. El punto se desplaza hacia el origen y elimina rápidamente la sobrecarga.

Son dos sentidos distintos de mejora: sumar cantidades iguales mejora el equilibrio relativo; la reducción proporcional disminuye la diferencia absoluta. Repetir ambos pasos impide que la diferencia vuelva a crecer mientras se sondea de nuevo la capacidad.

Sigue varios ciclos

Empieza con 8 y 1 Mbps en el enlace de 10 Mbps. Añade 0,5 Mbps por flujo en cada paso y reduce solo después de que el total supere la capacidad. Después de dos incrementos, las tasas son 9 y 2, con un total de 11. Reducirlas a la mitad da 4,5 y 1.

Cinco incrementos más llevan a 7 y 3,5, con un total de 10,5. Reducirlas a la mitad da 3,5 y 1,75. Las diferencias han sido 7; 3,5 y 1,75 Mbps. Otra reducción sincronizada a la mitad hace que la siguiente diferencia sea de 0,875 Mbps. Los flujos se aproximan a un reparto igualitario mientras su total sigue oscilando alrededor de la capacidad disponible.

Compara otras reglas de actualización

Esta convergencia supone RTT iguales, señales de congestión sincronizadas, respuestas equivalentes y flujos que permanecen activos el tiempo suficiente. El paso aditivo de Reno es de aproximadamente un MSS por RTT y su factor de decremento es de un medio. Otros pasos aditivos positivos y factores de decremento entre cero y uno dan el mismo argumento básico de convergencia. Los flujos reales no tienen por qué cumplir todos estos supuestos, por lo que un par desigual en un instante no demuestra por sí solo un fallo de AIMD.

Los repartos iguales son una referencia útil, pero los flujos reales pueden diferir en demanda, RTT, número de conexiones y controlador de congestión. Una afirmación sobre equidad necesita una respuesta clara a «¿equidad entre qué flujos?».

Calcula el índice de Jain

Para tasas de flujo no negativas con un total distinto de cero, el índice de Jain es:

Las tasas de 8 y 2 Mbps dan una suma de 10 y una suma de cuadrados de 68, por lo que el índice es aproximadamente 0,735. Las tasas iguales dan 1. Si uno de n flujos recibe todo, el índice es 1/n.

El índice mide la igualdad, no la utilización. Dos flujos de 1 Mbps cada uno y dos de 5 Mbps cada uno tienen ambos un índice de 1, aunque utilizan distintas cantidades de un enlace de 10 Mbps. Comprueba la tasa total por separado.

Ten en cuenta la demanda limitada

La equidad max-min da a los flujos de baja demanda lo que necesitan y después reparte la capacidad restante entre los flujos que siguen buscando más. En un enlace de 12 Mbps, tres flujos quieren 2, 8 y 10 Mbps. La parte igualitaria inicial es de 4 Mbps. El primero solo necesita 2, por lo que quedan 10 Mbps para los otros dos. La asignación es, por tanto, 2, 5 y 5 Mbps.

Aumentar una de las tasas mayores exigiría reducir la de un flujo que ya tiene una tasa igual o menor. Esa propiedad define la equidad max-min. Su asignación desigual puede ser adecuada aunque la medida de igualdad de Jain baje de 1.

Identifica ventajas entre flujos

Reno crece una vez por RTT. Con la misma fracción de pérdidas, su rendimiento aproximado es inversamente proporcional al RTT: un flujo de 20 ms puede alcanzar unas cuatro veces la tasa de uno de 80 ms. El acceso igualitario al cuello de botella no elimina esa ventaja temporal.

El reparto también es por conexión. Con nueve conexiones existentes, una aplicación que añada una podría recibir aproximadamente una décima parte del enlace. Si en cambio añade once conexiones comparables, su parte pasa a ser de once veinteavos, o el 55 %. HTTP/2 y HTTP/3 multiplexan muchas solicitudes en una conexión, mientras que los clientes HTTP/1.1 suelen abrir varias conexiones.

Una aplicación UDP de tasa fija puede seguir enviando mientras los flujos TCP reducen su tasa. UDP no proporciona ningún controlador; RFC 8085 pide que las aplicaciones añadan un control de congestión adecuado. Un flujo compatible con TCP no utiliza más ancho de banda que un tráfico TCP comparable en las mismas condiciones. TFRC utiliza la ecuación de rendimiento de TCP para mantener una tasa más uniforme.

Considera la cola y el algoritmo

Una cola FIFO no garantiza partes iguales para los flujos. Su resultado depende del comportamiento de los emisores. La gestión equitativa de colas, incluida la planificación por flujo de FQ-CoDel, proporciona a los flujos colas y oportunidades de servicio separadas.

El crecimiento de CUBIC y el de Reno difieren en trayectos con un BDP grande. El reparto entre BBR y CUBIC también depende de la versión y del tamaño del búfer; las primeras versiones de BBR podían ser agresivas con búferes pequeños. Ningún cálculo de igualdad por sí solo demuestra que distintos controladores coexistirán equitativamente en todos los trayectos.

Una cola con descarte en cola llena acepta paquetes hasta que su búfer está lleno y después descarta las nuevas llegadas. Los emisores basados en pérdidas siguen aumentando su envío hasta que reciben una señal de congestión. Con un búfer grande de este tipo, esa señal solo puede llegar después de que se haya formado una cola larga.

Calcula el retardo oculto en un búfer

Un búfer de 2 000 000 de bytes situado antes de un enlace ascendente de 20 Mbps contiene 16 millones de bits. Si está lleno, un paquete situado detrás de esos datos espera:

Una carga puede mantener así un rendimiento alto mientras añade casi un segundo a una llamada que comparte el enlace ascendente. La latencia excesiva por acumulación en búferes es el exceso de retardo persistente causado por búferes grandes y por el comportamiento del tráfico que los mantiene ocupados.

El almacenamiento en búfer sigue teniendo una finalidad: las ráfagas cortas necesitan un lugar donde esperar. En el modelo sencillo de un único flujo Reno, aproximadamente un BDP de búfer puede mantener ocupado el enlace inmediatamente después de reducir la ventana a la mitad. Hacer el búfer mucho mayor añade espera sin aumentar la tasa de transmisión del enlace.

Señala la congestión antes del desbordamiento

La gestión activa de colas, AQM, descarta o marca paquetes anticipadamente para indicar que los emisores deberían reducir su carga. El desbordamiento físico ya no es la única forma de anunciar la congestión. RFC 7567 recomienda un despliegue generalizado de AQM.

La detección temprana aleatoria, RED, observa una media móvil de la longitud de la cola. Por debajo de un umbral mínimo no emite señales. Entre dos umbrales, descarta o marca con una probabilidad creciente. Por encima del umbral máximo, emite una señal por cada llegada. El cálculo de la media evita que una sola ráfaga corta parezca una sobrecarga persistente, pero es difícil elegir umbrales que funcionen con distintas velocidades y cargas.

Mide directamente el tiempo de espera

CoDel, retardo controlado, mide el tiempo de permanencia de un paquete: el tiempo que pasa dentro de la cola. Su objetivo estándar es de 5 ms y su intervalo es de 100 ms. Si incluso el tiempo mínimo de permanencia observado sigue por encima del objetivo durante un intervalo, existe una cola persistente. Entonces CoDel descarta o marca paquetes con ECN, aumentando la frecuencia de las señales mientras persiste el exceso de retardo.

El mínimo durante un intervalo importa. Una ráfaga puede producir un retardo alto brevemente y vaciarse poco después; una cola cuyo retardo nunca se reduce necesita intervención. La medición del retardo de CoDel permite que sus valores predeterminados funcionen con una amplia gama de tasas de enlace.

FQ-CoDel combina colas separadas por flujo con CoDel. La separación de flujos ayuda a evitar que una transferencia grande coloque todos los paquetes interactivos pequeños detrás de sus datos pendientes.

Las señales tempranas también pueden reducir la sincronización global, en la que muchos flujos pierden paquetes juntos, se reducen a la mitad a la vez y dejan el enlace temporalmente infrautilizado. Las señales tempranas aleatorias distribuyen las reacciones en el tiempo. Con tráfico compatible con ECN, una AQM puede enviar su advertencia mediante una marca y aun así entregar el paquete.

La notificación explícita de congestión, ECN, permite que un encaminador entregue un paquete y advierta de que se está produciendo congestión. La marca cambia el comportamiento del emisor sin crear datos ausentes que deban retransmitirse.

Interpreta el punto de código IP

El campo ECN consta de dos bits en el byte de tipo de servicio de IPv4 o en la clase de tráfico de IPv6.

En el establecimiento TCP clásico de RFC 3168, el SYN del cliente activa ECE y CWR. El SYN-ACK de un servidor que acepta activa ECE. Después de la negociación, TCP clásico marca los paquetes de datos con ECT(0).

Sigue el ciclo de realimentación

Una AQM que descartaría un paquete compatible con ECN como advertencia de congestión puede cambiar su punto de código a CE y reenviarlo. Un paquete Not-ECT no puede llevar esa advertencia y se descarta cuando la AQM necesita emitir una señal. Un búfer completamente lleno sigue descartando paquetes, incluidos los compatibles con ECN.

El receptor devuelve la señal CE activando ECE, eco de ECN, en sus ACK. Continúa hasta que recibe CWR, ventana de congestión reducida, del emisor. Estos indicadores comunican la información y reconocen la respuesta; su presencia no significa que se hayan perdido datos.

Para ECN clásico de tipo Reno, empieza con una cwnd de 20 MSS. Después de que llegue ECE, el emisor reduce cwnd a 10 MSS y activa CWR en su siguiente segmento de datos nuevos. El receptor deja de devolver la señal cuando llega CWR. Los ecos repetidos de la misma ventana no requieren reducciones repetidas a la mitad. La advertencia regresa por el trayecto del acuse de recibo, por lo que la respuesta está sujeta al retardo de la realimentación.

ECN especifica la señal; el algoritmo de congestión proporciona la regla de reducción. Reno reduce a la mitad, mientras que CUBIC normalmente conserva el 70 % ante un episodio ECN. Ambos extremos y un cuello de botella que marque paquetes deben ser compatibles con ECN para que funcione este ciclo.

Utiliza la fracción de marcas

DCTCP, TCP para centros de datos, utiliza marcas frecuentes en un entorno controlado. Estima la fracción de bytes marcados con un valor suavizado alfa:

donde M es la fracción marcada recientemente. Algunas implementaciones usan un valor de g de 1/16. Reduce la ventana mediante:

Con un alfa de 0,2, una ventana de 100 pasa a 90; con un alfa de 1 se reduce a la mitad. DCTCP necesita marcado e información de retorno compatibles. Mezclarlo con TCP clásico en una misma cola ordinaria puede producir repartos inequitativos.

L4S, la arquitectura experimental de los RFC 9330–9332, lleva una respuesta escalable relacionada a los trayectos de internet. ECT(1) identifica el tráfico escalable y una AQM acoplada de doble cola lo separa del tráfico clásico mientras coordina su tratamiento. Las marcas frecuentes cuando la cola aún es corta buscan un retardo de cola de alrededor de un milisegundo. ECT(1) por sí solo no garantiza ese retardo: el controlador y el comportamiento del cuello de botella completan el diseño.

CUBIC aborda el lento crecimiento de Reno en trayectos rápidos y de larga distancia. Su ventana sigue el tiempo transcurrido desde una reducción por congestión, lo que le da una respuesta distinta a la de un incremento fijo de un segmento por RTT. RFC 9438 especifica CUBIC; es el predeterminado en las principales pilas TCP de Linux, Windows y Apple.

Recuerda el último punto de congestión

Ante un episodio habitual de pérdida o congestión ECN, CUBIC registra su ventana como Wmax. Con una ventana plenamente utilizada, su factor de decremento de 0,7 conserva el 70 % de la cantidad de datos en vuelo. Reno conservaría la mitad. El vencimiento del tiempo de espera de retransmisión es distinto: CUBIC sigue a Reno y vuelve a una ventana de un segmento y al inicio lento, mientras establece su umbral con el factor de decremento de CUBIC.

Para el período cúbico básico después de una reducción, la ventana objetivo en segmentos es:

El tiempo t se expresa en segundos. Cuando la ventana reducida es 0,7 Wmax, el tiempo de retorno al máximo anterior es:

Analiza la curva

Con un Wmax de 100 segmentos, la ventana reducida es 70. El valor dentro de la raíz cúbica es 75, por lo que K es aproximadamente 4,22 s. Al cabo de un segundo, la curva está en unos 86,7 segmentos; a los dos segundos está en 95,6; a los tres segundos está en 99,3. Alcanza 100 en K.

Por debajo del máximo anterior, el crecimiento es rápido al principio y después se ralentiza. Esta región cóncava se aproxima con cautela a un punto donde antes ocurrió congestión. Cerca del máximo hay una meseta relativamente plana. Por encima, la región convexa se acelera para sondear la capacidad que ahora podría estar disponible. A los siete segundos, la curva del ejemplo alcanza unos 108,6 segmentos.

Explica la ventaja respecto al RTT y su límite

Reno necesita 50 RTT para volver de 50 a 100 segmentos: 5 s con un RTT de 100 ms y 10 s con uno de 200 ms. El tiempo de retorno de la curva cúbica depende del máximo registrado y del tiempo transcurrido, por lo que su retorno de 4,22 s no depende directamente del número de ACK.

CUBIC también calcula una estimación compatible con Reno. Utiliza un incremento AIMD equivalente de aproximadamente 0,53 segmentos por RTT con un factor de decremento de 0,7, y toma esta estimación cuando supera el objetivo cúbico. Por tanto, los trayectos con RTT corto pueden recuperarse antes que el tiempo de retorno de la curva cúbica pura. El crecimiento basado en el tiempo reduce una fuente importante de sesgo debido al RTT; no hace que toda asignación real sea independiente del RTT.

Ajusta el máximo recordado

Si la congestión reaparece por debajo del máximo anterior, la convergencia rápida de CUBIC reduce el Wmax recordado. Un nuevo episodio en 90 segmentos después de un máximo anterior de 100 da:

La ventana reducida inmediatamente es de 63 segmentos. El máximo recordado y la nueva ventana actual tienen funciones distintas: uno determina el crecimiento futuro, mientras que la otra limita el envío actual.

CUBIC sigue estando basado en pérdidas, con ECN como señal alternativa. Puede crear una cola persistente en un trayecto con descarte en cola llena. Una recuperación más rápida y una reducción habitual más moderada mejoran el uso de trayectos con BDP grande, pero ninguna de las dos garantiza por sí sola un retardo de cola bajo.

Las pérdidas no son la única señal de un trayecto congestionado. El retardo puede revelar datos en cola, mientras que las mediciones de entrega pueden estimar cuánto ancho de banda proporciona el trayecto. Vegas y BBR utilizan estas observaciones de distintas maneras.

Estima los datos en cola con Vegas

Vegas compara una tasa esperada basada en el RTT mínimo o base con la tasa real basada en el RTT medido. Su diferencia, multiplicada por el RTT base, estima los datos del flujo en cola.

Con una cwnd de 50 segmentos, un RTT base de 40 ms y un RTT medido de 50 ms, la entrega esperada es de 1250 segmentos/s y la entrega real es de 1000 segmentos/s. La estimación de la cola es:

Vegas crece por debajo de un umbral inferior y se reduce por encima de un umbral superior. Si el tráfico basado en pérdidas sigue llenando la cola compartida, Vegas observa repetidamente el retardo y reduce su tasa, lo que puede dejarle una parte pequeña.

Construye el modelo de dos componentes de BBR

BBR, ancho de banda del cuello de botella y tiempo de propagación de ida y vuelta, estima el ancho de banda del cuello de botella a partir de las tasas máximas de entrega recientes y el RTT mínimo durante una ventana de medición de 10 s. Su producto estima el BDP. Su objetivo ideal es un enlace plenamente utilizado con aproximadamente un BDP en vuelo y pocos datos en cola.

Una estimación del ancho de banda de 50 Mbps y un RTT mínimo de 30 ms dan 1,5 millones de bits, o 187 500 bytes, por BDP. Un factor de ventana de congestión típico de 2 limita los datos pendientes a unos 375 000 bytes. La tasa de espaciado es un control separado: el factor de espaciado multiplicado por el ancho de banda estimado. Un límite permite tener datos en vuelo; no exige que el emisor envíe al doble del ancho de banda.

Sigue los estados de la versión 3 de BBR

La prueba de crecimiento de Startup es un crecimiento de la tasa de entrega inferior al 25 % durante tres rondas. ProbeRTT se programa como máximo aproximadamente una vez cada 5 s. En el trayecto del ejemplo, ProbeBW Up tiene como objetivo 62,5 Mbps y Down 45 Mbps. Estos detalles de la versión 3 se especifican en el borrador de internet de BBR, no en un RFC publicado de BBR.

Compara las señales y las ventajas y limitaciones

Reno y CUBIC aumentan hasta que las pérdidas o ECN señalan congestión. BBR espacia los paquetes a partir de un modelo de ancho de banda y RTT. Deliberadamente crea una cola breve en Startup y ProbeBW Up, por lo que «basado en un modelo» no significa «nunca crea una cola».

La versión 1 de BBR ignoraba en gran medida las pérdidas. La versión 3 utiliza pérdidas elevadas, alrededor del 2 % en una ronda, para limitar el exceso de envío y mejorar la coexistencia. Puede mantener más rendimiento en trayectos largos con pérdidas aleatorias, pero no puede identificar perfectamente por qué se perdió un paquete. Su respuesta específica a ECN sigue abierta en el borrador; cualquier conexión que declare compatibilidad con ECN debe responder a CE como congestión. El tamaño del búfer, el RTT, la versión y los algoritmos que compiten siguen influyendo en la equidad.

Un protocolo se osifica cuando los dispositivos desplegados dependen tanto de su forma existente que los cambios se vuelven difíciles de desplegar. Los dispositivos intermedios de red inspeccionan las cabeceras TCP y pueden rechazar opciones o indicadores desconocidos. Las implementaciones en el núcleo también distribuyen nuevos comportamientos mediante actualizaciones del sistema operativo, a menudo lentamente.

Identifica los costes que aborda QUIC

TCP ha evolucionado mediante SACK, ECN, escalado de ventana y nuevos controladores de congestión. Sin embargo, su estructura sigue siendo importante para el tráfico web. Una conexión nueva convencional de TCP con TLS necesita el establecimiento de TCP antes del intercambio de TLS. Su único flujo de bytes ordenado también significa que un segmento ausente bloquea la entrega de los bytes posteriores, incluidos los datos de solicitudes no relacionadas. Esto es el bloqueo de cabecera de cola en el transporte.

Las direcciones y los puertos de una conexión pueden crear otro obstáculo cuando un dispositivo cambia de red. QUIC, estandarizado en RFC 9000, cambia estas partes del diseño del transporte mientras transporta sus paquetes sobre UDP. HTTP/3 funciona sobre QUIC.

Combina los intercambios de establecimiento

QUIC integra TLS 1.3 con su intercambio de establecimiento del transporte. En un intercambio sencillo con un RTT de 80 ms, procesamiento insignificante y sin pérdidas, una conexión nueva de TCP con TLS 1.3 envía la solicitud después de dos RTT y recibe los primeros bytes de la respuesta después de tres: 240 ms. Una conexión QUIC nueva puede recibirlos después de dos RTT: 160 ms.

Una conexión QUIC reanudada puede enviar datos anticipados de aplicación en su primer conjunto de paquetes, lo que se denomina 0-RTT. La primera respuesta puede llegar entonces después de un RTT, 80 ms en este ejemplo. Los datos anticipados pueden repetirse, por lo que las aplicaciones los restringen a acciones que se pueden repetir de forma segura. El término 0-RTT describe cuándo puede comenzar el envío, no una respuesta instantánea.

Separa los flujos, no todos los límites compartidos

QUIC transporta flujos de bytes ordenados e independientes. Si un paquete contiene datos para la imagen 1, perderlo no bloquea la entrega de los datos ya recibidos de las imágenes 2 y 3 en flujos separados. Un paquete que transporta varios flujos puede afectar a cada uno de ellos. Todos los flujos siguen compartiendo el controlador de congestión de la conexión, por lo que una pérdida puede reducir su tasa total disponible.

QUIC proporciona entrega fiable de flujos sobre UDP. También proporciona control de flujo tanto por flujo como por conexión. UDP es el soporte, no un sustituto de estas funciones de transporte.

Protege los detalles que pueden cambiar

QUIC cifra las cargas útiles de los paquetes, incluidas todas las tramas de transporte. La protección de cabecera cubre los números de paquete y algunos bits del primer byte. Los campos necesarios para el encaminamiento y la negociación, como los identificadores de conexión y la versión, permanecen visibles. Ocultar los detalles de transporte que pueden cambiar deja a los dispositivos intermedios menos comportamientos de los que depender.

Los identificadores de conexión identifican una conexión independientemente de las direcciones IP y los puertos actuales. Con la validación del trayecto, una conexión puede migrar cuando un teléfono pasa de Wi-Fi a acceso celular, sin iniciar una conexión completamente nueva.

QUIC suele ser una biblioteca en el espacio de usuario. Por tanto, una actualización de la aplicación puede distribuir una mejora del transporte sin esperar a que cambie el núcleo de cada sistema operativo. Esa flexibilidad también asigna a la aplicación la responsabilidad de detectar correctamente las pérdidas y aplicar la seguridad, el control de flujo y el control de congestión.

QUIC mejora lo que un emisor puede aprender de los acuses de recibo, pero sigue teniendo que evitar la sobrecarga del trayecto. RFC 9002 define la detección de pérdidas y un controlador predeterminado similar a NewReno. Las implementaciones pueden utilizar otros algoritmos adecuados, incluidos CUBIC o BBR.

Identifica cada transmisión

Los números de paquete aumentan y nunca se repiten dentro de un espacio de números de paquete. Los datos reenviados viajan en tramas dentro de un paquete nuevo con un número nuevo. Por tanto, un ACK puede identificar la transmisión que llegó, evitando la ambigüedad de TCP entre un segmento original y su retransmisión.

Las tramas ACK informan de los intervalos recibidos y del retardo del ACK del receptor. Después del intercambio de establecimiento, el emisor utiliza un retardo del ACK validado y limitado al ajustar las estimaciones del RTT; no resta automáticamente un retardo arbitrario del receptor de cada muestra.

QUIC declara perdido un paquete cuando se ha reconocido otro con un número al menos tres números de paquete posterior, o mediante su umbral temporal una vez reconocido un paquete posterior. El umbral temporal recomendado es 9/8 del mayor entre el RTT más reciente y el suavizado. Un tiempo de espera de sondeo, PTO, envía sondas que solicitan acuses de recibo. El vencimiento del PTO por sí solo no reduce cwnd al mínimo.

Establece límites de ventana en bytes

Para un tamaño máximo de datagrama d, la ventana inicial de RFC 9002 es:

Con un d de 1200 bytes, el resultado es de 12 000 bytes. Con un d de 1500 bytes, es de 14 720 bytes. La ventana mínima de congestión es de dos datagramas de tamaño máximo, por lo que esos trayectos tienen mínimos de 2400 y 3000 bytes, respectivamente.

En el controlador predeterminado, una pérdida o una nueva señal de congestión CE reduce cwnd a la mitad, con la ventana mínima como límite inferior, y establece ssthresh en la ventana reducida. Un período de recuperación impide otra reducción por pérdidas adicionales de paquetes enviados antes de que comenzara la recuperación. Un acuse de recibo de un paquete enviado durante la recuperación termina el período. El emisor reanuda entonces el crecimiento normal.

Reconoce un fallo sostenido

La congestión persistente es un indicio más sólido que el vencimiento de un solo temporizador. Requiere una secuencia suficientemente larga de paquetes perdidos que solicitan acuse de recibo, sin ningún paquete intermedio reconocido y con una muestra previa del RTT. Su umbral de duración es:

Con un RTT suavizado de 100 ms, una variación de 10 ms, un retardo máximo del ACK de 25 ms y una granularidad del temporizador insignificante, el umbral es de 495 ms. El intervalo de pérdidas que cumple los requisitos debe superar ese valor. El controlador reduce entonces cwnd a dos datagramas, su ventana mínima.

Mantén útiles las señales y la temporización

Los ACK de QUIC pueden comunicar recuentos acumulativos de ECT(0), ECT(1) y CE. Después de validar el funcionamiento de ECN en el trayecto, el emisor trata un nuevo aumento de CE como un episodio de congestión sin necesitar una pérdida de paquetes.

El espaciado distribuye las transmisiones. Una tasa de alrededor de 1,25 veces cwnd dividida entre el RTT suavizado es un enfoque sugerido; los límites de ráfaga pueden cumplir la misma función. Enviar una ventana completa de una vez crea una ráfaga incluso cuando la tasa media es aceptable. El despliegue en el espacio de usuario facilita la distribución de nuevos controladores, pero cada pila sigue teniendo que compartir el ancho de banda de forma responsable.