- El RFC 9330 define la arquitectura L4S para reducir la latencia por encolado y las pérdidas por congestión en aplicaciones de Internet, y ubica la causa raíz de la latencia no tanto en la cola misma sino en el control de congestión del emisor orientado a explorar capacidad
- L4S combina control de congestión escalable en el host emisor, AQM en el cuello de botella y protocolos basados en ECN, y utiliza el codepoint ECT(1) del campo IP-ECN para identificar paquetes L4S
- La latencia objetivo de encolado es de menos de 1 ms en promedio y de alrededor de menos de 2 ms en el percentil 99; en ejemplos con DCTCP y Dual-Queue Coupled AQM, incluso bajo sobrecarga la latencia de encolado en el percentil 99 se mantiene aproximadamente en 1~2 ms
- Para coexistir con el control de congestión Classic de la familia Reno/CUBIC, L4S separa la latencia del tráfico Classic y del tráfico L4S, pero está diseñado para compartir el ancho de banda a largo plazo en vez de dividirlo de forma fija
- L4S complementa, en lugar de reemplazar, Diffserv, FQ-CoDel, PIE y BBR; TCP necesita retroalimentación precisa como AccECN, mientras que QUIC y DCCP ya ofrecen la retroalimentación ECN necesaria para L4S
El problema de latencia que L4S busca resolver
- Cada vez son más frecuentes las situaciones donde tráfico que prefiere baja latencia —como web, voz, videoconferencia, juegos, escritorio remoto, aplicaciones en la nube, AR/VR y control remoto— llena enlaces cuello de botella
- Aunque al ubicar cachés y servidores cerca de los usuarios se ha reducido la latencia de propagación, el encolado sigue siendo un componente principal e intermitente de la latencia
- Incluso con AQM moderno, los picos de latencia de cientos de ms no son raros
- El AQM Classic suele configurarse para amortiguar la variación en diente de sierra de la cola de un único flujo de larga duración, por lo que durante ese flujo los picos de latencia total de la red pueden llegar a ser aproximadamente el doble de la latencia base del trayecto
- El objetivo de L4S es latencia de encolado muy baja, pérdidas muy bajas y rendimiento escalable
- Latencia de encolado muy baja significa menos de 1 ms en promedio y alrededor de menos de 2 ms en el percentil 99
- Las aplicaciones interactivas más exigentes empiezan a sentirse poco naturales cuando la latencia de extremo a extremo supera los 50 ms o incluso los 20 ms
- Como la pérdida provoca demoras por retransmisión en aplicaciones interactivas, la baja pérdida también es un objetivo central
La causa de la latencia: más que la cola, el control de congestión Classic
- L4S identifica la causa raíz de la latencia por encolado no en la cola misma sino en el control de congestión orientado a explorar capacidad del emisor
- Los controles de congestión Classic como Reno y CUBIC hacen que la ocupación de la cola varíe en grandes patrones de diente de sierra
- Si AQM mantiene la cola demasiado poco profunda, el control de congestión Classic no puede aprovechar bien el enlace en cada valle del diente de sierra
- A medida que aumenta la velocidad del flujo, el tiempo de recuperación del control de congestión Classic se alarga, y el control de la cola y de la utilización se vuelve más laxo
- El control de congestión escalable mantiene constante el tiempo promedio entre señales de congestión, es decir, el tiempo de recuperación, incluso cuando aumenta la velocidad del flujo
- DCTCP es un ejemplo ampliamente usado en entornos controlados
- Está implementado y desplegado en Windows Server Editions, Linux y FreeBSD
- Prague sobre TCP/QUIC, SCReAM para L4S y la parte L4S ECN de BBRv2 también entran como ejemplos de control de congestión escalable
Los tres componentes de la arquitectura L4S
- L4S se compone de tres elementos
- Control de congestión escalable en el host emisor
- AQM en el cuello de botella de la red
- Un protocolo basado en ECN que se encarga de identificar paquetes y transportar la señal de congestión entre ambos
- La baja latencia no la entrega directamente la red, sino el comportamiento cuidadoso del control de congestión escalable del emisor L4S
- El papel principal de la red es aislar la baja latencia del tráfico L4S de la mayor latencia de encolado que necesita el tráfico Classic
- La red usa ECN para avisar a la capa de transporte de señales muy tempranas de crecimiento de la cola
- No espera a suavizar mucho la variación de la cola antes de señalizar, como hace un AQM Classic
- El soporte de ECN es indispensable para L4S
- El emisor usa el campo ECN para que la red pueda distinguir paquetes L4S de paquetes Classic
ECN y el codepoint ECT(1)
- L4S necesita una señal de congestión más fina que supere la restricción del ECN Classic de que “la señal ECN debe tratarse como equivalente a una pérdida”
- La señal debe poder ocurrir con mayor frecuencia
- Debe poder emitirse de inmediato, sin introducir grandes demoras para suavizar la variación de la cola
- RFC8311 flexibiliza algunos requisitos de RFC3168 para permitir experimentos con L4S
- RFC9331 especifica el uso de ECT(1) como identificador de paquetes L4S
- El codepoint CE se utiliza para indicar Congestion Experienced tanto en el procesamiento L4S como en el Classic
- Si un AQM Classic anterior en el trayecto marca paquetes ECT(0) con CE, existe el riesgo de clasificarlos por error en la cola L4S
- Según el Apéndice B del RFC9331, para que haya un efecto dañino tendrían que coincidir cinco condiciones poco frecuentes y, aun así, la probabilidad de una retransmisión errónea es extremadamente baja
- Los operadores pueden querer poner en la cola L4S tráfico no L4S que sea lo bastante bajo y suave como para no generar cola
- Ejemplos: VoIP, datagramas de baja tasa para sincronización de juegos en línea, DNS y LDAP
- En esos casos haría falta una marca aparte, como EF, NQB o un identificador específico del operador
Dual-Queue Coupled AQM
- L4S busca ofrecer baja latencia sin exigir necesariamente que el componente de red procese cada flujo por separado
- El diseño representativo, Dual-Queue Coupled AQM, usa dos colas
- La cola L4S mantiene baja latencia
- La cola Classic puede tener una cola más grande, necesaria para que el tráfico Classic mantenga la utilización del enlace
- DualQ está diseñado para comportarse como una membrana semipermeable: separa la latencia, pero no divide el ancho de banda de forma fija
- El AQM Classic genera su propia probabilidad de drop o marcado basada en la congestión de su cola, y la acopla a las señales de la cola Classic y de la cola L4S
- La señal de congestión acoplada hace que los flujos L4S reduzcan su velocidad para dejar capacidad disponible a los flujos Classic
- El scheduler puede dar prioridad a la cola L4S
- En escalas de tiempo cortas, drena rápidamente los bursts L4S para proteger la baja latencia
- En escalas largas, mayores al RTT, el acoplamiento de señales de congestión de la cola Classic compensa esa prioridad y genera una equidad aproximada por flujo en el ancho de banda
- Cuando solo hay tráfico L4S, el AQM de la cola L4S empieza a marcar congestión con una cola muy poco profunda para mantener baja la latencia de encolado
Diferencias entre el encolado por flujo y DualQ
- Los esquemas de encolado por flujo como FQ-CoDel y FQ-PIE también pueden usarse con L4S
- En Linux se modificaron para que el umbral superficial de marcado ECN se aplique solo a paquetes ECT(1)
- A los flujos Not-ECT o ECT(0) se les aplica AQM Classic, mientras que a los flujos ECT(1) se les aplica normalmente un umbral superficial de menos de 1 ms
- El enfoque por flujo separa las colas de cada flujo, pero no elimina el encolado que genera el propio flujo
- El enfoque DualQ no requiere inspección más profunda que la capa IP, porque el identificador L4S está en el campo IP-ECN
- Puede usarse incluso cuando los identificadores de transporte están cifrados, como con IPsec o túneles VPN cifrados
- En los enfoques por flujo, la red asume el control relativo de la velocidad entre flujos de aplicación
- DualQ separa el problema de ofrecer baja latencia del problema de controlar la velocidad de los flujos, y si hace falta se puede añadir por separado un policing de velocidad por flujo
Requisitos del lado del host
- El emisor debe implementar control de congestión escalable
- DCTCP es el ejemplo más extendido, pero para usarlo en la Internet pública necesita mejoras de seguridad y rendimiento
- Las partes de los requisitos Prague L4S relacionadas con el riesgo de perjudicar a terceros están incluidas como requisitos normativos en el RFC9331
- TCP Prague está implementado como implementación de referencia en Linux
- Los protocolos de transporte distintos de TCP también deben implementar una respuesta de congestión escalable y marcarla con el codepoint ECT(1) para usar servicios L4S
- Se estudian variantes escalables para QUIC
- La parte L4S ECN de BBRv2 se presenta como control de congestión escalable para TCP, QUIC y otros
- También se implementó una variante L4S de SCReAM para medios RTP
- La retroalimentación ECN varía según el protocolo
- DCCP y QUIC proporcionan retroalimentación ECN suficientemente fina para L4S
- La retroalimentación ECN existente en TCP asume que una marca ECN equivale a una pérdida, por lo que no puede usarse con TCP escalable
- El receptor TCP necesita soporte para AccECN, una retroalimentación ECN más precisa
- SCTP necesitaría implementar y desplegar un nuevo diseño ECN para soportar L4S
- Para RTP, el RFC6679 y el RFC8888 definen retroalimentación ECN suficiente
Por qué se necesita señalización explícita de congestión
- L4S usa la señalización explícita de congestión como mecanismo principal en lugar de la pérdida
- Los drops degradan el rendimiento y al mismo tiempo sirven como señal, lo que crea una tensión entre “daño que conviene minimizar” y “señal que conviene tener con frecuencia”
- La señalización explícita basada en ECN puede usarse varias veces por RTT sin causar daño, lo que ayuda a mantener cortas las colas
- L4S traslada el suavizado desde la red hacia el host
- Como la red no conoce el RTT de cada flujo, en el enfoque Classic debe asumir el peor RTT posible
- Por eso la señal de congestión Classic puede retrasarse entre 100 y 200 ms
- Cada host sí conoce su propio RTT, así que puede suavizar solo lo necesario, normalmente del orden de unos pocos ms
- La cola L4S usa una nueva variante de ECN L4S que no equivale a drop, mientras que la cola Classic usa ECN Classic o drop
La base de la escalabilidad del rendimiento
- El control de congestión Reno Classic alarga su tiempo de recuperación a medida que aumenta el producto ancho de banda-retardo
- En el ejemplo, el RTT máximo en el pico del diente de sierra es de 30 ms
- Si la tasa de paquetes de Reno aumenta 8 veces, de 1,250 packet/s a 10,000 packet/s, eso equivale aproximadamente a pasar de 15 Mb/s a 120 Mb/s con paquetes de 1500 B, y el tiempo de recuperación crece de 422 ms a 3.38 s
- CUBIC, a 120 Mb/s, opera en modo Reno-friendly y tarda unos 4.3 s en recuperarse
- A 960 Mb/s entra en modo true CUBIC y el tiempo de recuperación pasa a 12.2 s
- A 7.68 Gb/s, el tiempo de recuperación llega a 24.3 s
- El control de congestión escalable, como DCTCP o Prague, induce en promedio 2 señales de congestión por RTT, y esa propiedad se mantiene sin importar la velocidad del flujo
- En 2020, la capacidad promedio mundial de acceso fijo era de 103 Mb/s, y en 2019 el RTT base promedio hacia CDN era de 25 a 34 ms
- Un único flujo de descarga CUBIC puede tardar, en el mejor de los casos, unos 200 RTT en recuperarse tras una reducción de la ventana de congestión, es decir, unos 5 segundos
Relación con tecnologías existentes
- Diffserv trata la asignación de ancho de banda para tráfico importante y la latencia de encolado del tráfico sensible a la latencia, mientras que L4S solo aborda el problema de la latencia de encolado
- Diffserv es efectivo cuando solo parte del tráfico en el cuello de botella necesita baja latencia
- Si todo el tráfico del cuello de botella quiere baja latencia, desaparece la ventaja de distinguirlo con Diffserv
- El identificador L4S no expresa un requisito de calidad, sino un compromiso de comportamiento: una respuesta de congestión escalable
- Los AQM Classic como PIE y FQ-CoDel reducen mucho la latencia de encolado frente a no tener AQM
- L4S los complementa y no elimina la necesidad de desplegarlos ampliamente
- Solo con AQM es difícil eliminar la tensión entre latencia y utilización del enlace debido al gran diente de sierra del control de congestión Classic
- ABE cambia la reacción del host ante el marcado ECN para aumentar la utilización del enlace y el throughput de flujos con ECN, pero sigue suponiendo que la red trata igual ECN y drop
- BBR controla la latencia de encolado de extremo a extremo sin lógica especial en la red
- BBR mantiene una latencia de encolado razonablemente baja, pero no tan baja como L4S
- BBRv2 puede usar, cuando sea posible, ECN L4S y comportamiento de control de congestión escalable L4S
Aplicaciones donde puede usarse
- L4S puede mejorar de forma importante la calidad de aplicaciones existentes cuando hay carga
- Juegos y cloud gaming
- VoIP
- Videoconferencia
- Navegación web
- Streaming de video adaptativo
- Mensajería instantánea
- Una latencia de encolado más baja habilita funciones como video interactivo en la nube y VR/AR en la nube
- En demos de L4S, sobre un enlace de acceso de banda ancha de 40 Mb/s, video interactivo en la nube y VR pudieron funcionar al mismo tiempo mientras varias aplicaciones sensibles a la latencia y descargas compartían la misma cola cuello de botella
- Con una latencia base de extremo a extremo de 7 ms, la latencia adicional por encolado fue de alrededor de 1 ms
- Con AQM alternativos, el video seguía de forma perceptible los gestos con los dedos y los movimientos de cabeza
- Tareas como hacer pan del video con un swipe o con movimientos de cabeza tienen requisitos de latencia mucho más estrictos que VoIP
- La telepresencia remota interactiva y el control remoto asistido por video de máquinas y procesos industriales son difíciles de considerar confiables sin una latencia de encolado extremadamente baja
Modelo de despliegue e introducción gradual
- L4S AQM no es una arquitectura que solo funcione si se despliega en toda la Internet
- Las redes públicas de acceso a Internet suelen diseñarse para que el cuello de botella aparezca en un único enlace lógico conocido por sitio
- Un sitio puede ser un hogar, un dispositivo móvil o una red pequeña o mediana de campus o empresa
- Es una generalización aplicable a varias tecnologías de acceso: xDSL, cable, PON, celular, inalámbrico, satélite y otras
- En downstream, desplegar L4S AQM en la entrada del enlace cuello de botella permite obtener la mayor parte de los beneficios, y en upstream aplica igual al desplegarlo en la entrada del enlace upstream
- Para que un flujo L4S obtenga beneficio normalmente se requieren tres elementos
- El control de congestión del emisor
- El AQM del cuello de botella
- En transportes antiguos como TCP, retroalimentación mejorada del receptor
- El orden de despliegue puede variar
- DCTCP ya existente puede aprovecharse en entornos de prueba controlados
- Desplegar TCP Prague y AccECN permite usar L4S en la Internet pública
- QUIC ya soporta desde el inicio la retroalimentación ECN necesaria para L4S, por lo que desplegar control de congestión Prague del lado emisor es más simple
Restricciones según la tecnología de enlace
- Wi-Fi, PON y cable agregan en bursts varios paquetes de datos y almacenan en búfer los paquetes que llegan mientras se forma ese burst
- Ethernet y DSL no hacen esa agregación de paquetes
- Ese buffering de agregación no puede ser reducido por el emisor, así que no debe contarse como parte de la cola controlada por AQM
- Los enlaces inalámbricos como celular, Wi-Fi y satélite pueden variar de capacidad de forma rápida y amplia, por lo que se considera deseable mantener una cola residente para aprovechar aumentos repentinos de capacidad
- Las redes celulares son más complejas además por los requisitos de buffering para que los handovers pasen desapercibidos
- L4S no puede eliminar todas estas necesidades de buffering
- Si se elimina “el poste más largo”, es decir, el buffering necesario por el gran diente de sierra del control de congestión Classic, surge más incentivo para reducir otros factores de buffering como el tamaño del burst agregado o el intervalo de scheduling MAC
Cuellos de botella no L4S y manejo de pérdidas
- Aunque L4S esté activado entre dos hosts, si el cuello de botella no soporta ECN el emisor L4S debe coexistir de forma segura con Reno frente a los drops
- Esta regla protege al tráfico Classic, pero degrada el servicio L4S cuando hay pérdidas
- Pérdidas transitorias por bursts en colas poco profundas
- Errores de transmisión, como interferencia eléctrica
- Policing de velocidad
- Hay tres enfoques en investigación para abordar esto
- Ignorar en el control de congestión Prague algunas pérdidas con baja probabilidad de ser por congestión
- Recuperar errores de transmisión con una combinación de RACK, L4S y retransmisión de enlace sin reordenamiento
- Policers híbridos de velocidad ECN/drop
- Los escenarios de despliegue donde estos problemas son menores, como en redes cableadas, pueden avanzar en paralelo con esa investigación
Seguridad y policing de tráfico
- En la Internet actual, por lo general la separación de capacidad en enlaces compartidos entre sitios se maneja con schedulers, y no es común aplicar policing universal de velocidad a flujos individuales de aplicación
- L4S está diseñado para no romper ese estado
- DualQ está diseñado para no dar a flujos no reactivos una ventaja de velocidad mayor que la de un AQM de cola única
- Si se necesita policing de velocidad por flujo, puede añadirse de forma independiente a la distinción L4S/Classic
- L4S está diseñado para reducir la latencia sin perjudicar la latencia ni la velocidad del tráfico Classic, así que no hace falta limitar el acceso al servicio L4S con policing de velocidad solo para proteger al tráfico Classic
- Algunos operadores pueden ofrecer servicio L4S solo a un grupo limitado, como clientes premium
- En ese caso pueden usar, además del campo ECN, identificadores locales como rangos de direcciones de origen
- Si el identificador local no coincide, incluso con ECT(1) el tráfico puede enviarse a la cola Classic
- El servicio L4S requiere moderación no solo en velocidad, sino también en burstiness
- La función de protección de cola de baja latencia para DOCSIS preserva la baja latencia redirigiendo parcialmente a la cola Classic los flujos que generan cola
- Las funciones de protección de cola única no son un elemento obligatorio de la arquitectura L4S, y parte de los experimentos de L4S busca verificar si realmente son necesarias
Túneles y privacidad
- Como L4S AQM señaliza la congestión mediante el campo ECN, cuando opera dentro de túneles o en capas inferiores ese campo ECN debe propagarse entre capas conforme a los estándares
- La arquitectura L4S no excluye enfoques que inspeccionan identificadores de la capa de transporte
- Un ejemplo es FQ-CoDel con soporte L4S añadido
- La innovación clave, DualQ AQM, no requiere inspección más profunda que el encabezado IP más externo
- Aunque el usuario cifre los identificadores de flujo de aplicación con IPsec o túneles VPN cifrados, no necesita renunciar a la baja latencia
- Como L4S puede ofrecer baja latencia a un conjunto amplio de aplicaciones, disminuye la necesidad de distinguir aplicaciones individuales o clases detalladas mientras atraviesan la red
1 comentarios
Opiniones en Hacker News
Esto está realmente genial. El mes pasado vi una demo en vivo en IETF 118 en Praga, y parecía muy bueno para videollamadas porque elimina por completo el bufferbloat
Parece que hay que poner un bit adicional en los paquetes IP para incluir información como si el búfer está lleno, pero en la práctica funcionó, y me dejó con la sensación de “no sabía que esto era posible”
Para quienes no les funcione el enlace con marca de tiempo, es en 1 hora 21 minutos. Edición: no era; esto era el resumen del hackathon y no es fácil encontrar la presentación
Me dio curiosidad cómo el receptor le informa la congestión al emisor y me puse a buscar, pero no fue tan fácil de encontrar como esperaba. Lo esencial está documentado en https://www.rfc-editor.org/info/rfc3168
Dicho de forma simple, no hay una sola bandera, sino unas tres. Hay una bandera con la que el emisor le indica al router que puede soportar ECN, una bandera con la que el router le indica congestión al receptor, y una bandera que el receptor establece al enviar paquetes ACK
El emisor indica soporte ECN con el punto de código ECT, y un router compatible con ECN, en lugar de descartar el paquete, establece el punto de código CE en el encabezado IP y lo reenvía. El receptor establece ECN-Echo en el siguiente ACK TCP, y el emisor reacciona a la congestión como si hubiera pérdida de paquetes; luego establece la bandera CWR en el encabezado TCP del siguiente paquete
Bob Briscoe lleva mucho tiempo pensando en esta dirección. Recomiendo estos textos clásicos relacionados
http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A...
https://dl.acm.org/doi/pdf/10.1145/1080091.1080124
Se hicieron algunas pruebas en la red de cable de Comcast, y estas diapositivas lo explican
https://datatracker.ietf.org/meeting/118/materials/slides-11...
No sé adónde llevará esto, pero me hace pensar que los ISP podrían empezar a cobrar peaje por carriles rápidos
Opinión personal, pero trabajo en Comcast
Si quieres saber más sobre L4S, hoy empieza una serie de webinars en understandinglatency.com. Presentarán algunos de los autores de L4S, el responsable de las pruebas de campo de L4S en Comcast y también voces críticas
Encontré una demo breve de uso real con un feed de video de un auto RC: https://www.youtube.com/watch?v=RZmS10djDEg
Es un avance en la dirección correcta, pero si hay aunque sea un actor malicioso que ignore la retroalimentación de congestión y solo quiera una porción mayor del ancho de banda, surgen problemas. Entonces los demás participantes se hacen a un lado y el actor injusto obtiene lo que quiere
Para los participantes bien comportados es difícil saber si los demás cumplen las reglas, y tendrían que saber que existe fair queuing para confiar en que L4S los tratará de forma justa
Este problema se puede resolver complementando L4S con fair queuing como fq_codel y haciendo que el control de congestión pueda detectar la presencia de fair queuing: https://github.com/muxamilian/fair-queuing-aware-congestion-...
El debate sobre fair queuing es parte de un debate más amplio. Sin fair queuing, independientemente de L4S, la equidad ya la implementan los hosts finales, y un host final como un servidor puede ignorar la reacción a la congestión y tomar más que su porción justa. Esto no es un problema nuevo creado por L4S, aunque algunos creen que L4S facilita tomar una porción mayor
Quienes apoyan fair queuing creen que la red debe garantizar un reparto justo, pero no todos están de acuerdo con la métrica de equidad que eligieron. En particular, uno de los principales defensores de L4S no está de acuerdo, como puede verse en el paper enlazado aquí: https://news.ycombinator.com/item?id=38598023
Me da curiosidad qué cambia realmente para el usuario. Por ejemplo, ¿las videollamadas se vuelven más cercanas al tiempo real? Normalmente hay unos 0.5 a 1 segundo de retraso, lo que causa muchos cortes e interrupciones cuando la gente habla. ¿Qué otras aplicaciones mejorarían mucho?
Para ajustarse a un bitrate de menos de 3 Mbps hay que hacer compromisos difíciles entre calidad, bitrate, tiempo de CPU y latencia. Una laptop común tiene una CPU lenta o, aunque tenga una CPU de 6 núcleos, mantiene una frecuencia baja cuando funciona con batería. La codificación de video acelerada por hardware tampoco es universal, así que se sacrifican calidad y latencia
El Wi‑Fi también suma latencia, especialmente cuando la laptop funciona con batería. Para gestionar NAT, muchos servicios de videollamadas usan servidores en la nube como relés, lo que agrega latencia
https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
Funciones con mucha interactividad, como juegos y videoconferencias, también mejoran mucho sin latencia. Renderizar páginas web, hacer streaming de video o procesar interacciones con asistentes de IA como Alexa hoy requieren muchos viajes de ida y vuelta, así que casi todo lo que implique interacción entre el usuario y el dispositivo puede mejorar
En esencia, L4S es una tecnología que reduce el bucle de retroalimentación de latencia. La segunda mitad de este video lo explica bastante bien: https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp