Servicio de Internet L4S que ofrece baja latencia, baja pérdida y rendimiento escalable: RFC 9330

Resumen de la arquitectura del servicio de Internet L4S

• Objetivo de la arquitectura L4S: lograr baja latencia, bajas pérdidas por congestión y control de rendimiento escalable para las aplicaciones de Internet
• Idea clave: la causa fundamental de la latencia no es la cola en sí, sino el controlador de congestión del emisor que explora la capacidad
• Nuevo algoritmo de control de congestión: en lugar de los algoritmos tradicionales de control de congestión que provocan alta latencia, se pueden adoptar nuevos algoritmos capaces de explorar la capacidad con muy poca latencia
• Forma modificada de ECN: se respalda mediante una forma modificada de la notificación explícita de congestión (ECN) en la red, lo que permite alcanzar simultáneamente baja latencia y alto rendimiento
• Enfoque en despliegue gradual: define mecanismos para que una nueva clase de control de congestión y el control de congestión "clásico" puedan coexistir en una red compartida

Componentes de la arquitectura L4S

• Hosts: los algoritmos de control de congestión escalable ya existen y, a diferencia de los algoritmos clásicos de control de congestión, mantienen constante el tiempo de recuperación incluso cuando aumenta la velocidad del flujo
• Red: aísla el tráfico L4S de la latencia del tráfico clásico y utiliza dos colas para separar la latencia, pero no el ancho de banda
• Protocolo: utiliza identificadores para que los hosts puedan distinguir entre paquetes L4S y clásicos, y para que la red pueda tratar cada tipo de paquete por separado

Opinión de GN⁺

Lo más importante de este texto es que la arquitectura L4S presenta un nuevo enfoque para lograr baja latencia, baja pérdida y rendimiento escalable en los servicios de Internet. Esta arquitectura supera las limitaciones de los algoritmos tradicionales de control de congestión y hace posible una comunicación eficiente mediante el uso de ECN. Puede ser un tema interesante para diseñadores de redes, operadores y usuarios, y podría tener un impacto importante en el desarrollo futuro de Internet.

[GN⁺]

Comentarios de Hacker News

• Curiosidad sobre cómo el receptor le informa al emisor sobre la congestión de la red

  • Se pueden consultar más detalles en el documento RFC 3168
  • Existen tres banderas que soportan ECN (Efficient Congestion Notification)
    • La bandera ECT (Echo Congestion Experienced), que indica que el emisor puede soportar ECN
    • La bandera CE (Congestion Experienced), que el router usa para informar al receptor que hay congestión
    • La bandera ECN-Echo, que el receptor establece al enviar paquetes ACK al emisor
    • El emisor recibe la bandera ECN-Echo y asume que hubo pérdida de paquetes para responder a la congestión
    • El emisor establece la bandera CWR (Congestion Window Reduced) para informar al receptor que reconoció la bandera ECN-Echo y respondió a ella

• Experiencia viendo una demostración real de la tecnología ECN

  • Se vio una demo en vivo de la tecnología ECN en la IETF 118
  • Elimina por completo el buffer bloat, por lo que es muy útil para videollamadas
  • Se siente como una tecnología futurista: agrega bits adicionales a los paquetes IP para indicar que el búfer está lleno

• Recomendación de investigaciones relacionadas de Bob Briscoe

  • Recomiendan los papers clásicos de Bob Briscoe, quien ha dedicado mucho tiempo a la investigación sobre ECN

• Pruebas de L4S en la red de Comcast

  • Comparten un slide deck con resultados de pruebas de L4S en la planta de cable
  • Especulación sobre la posibilidad de que los ISP cobren un peaje por el carril rápido

• Hallazgo de una demo de feed de video para auto RC usando tecnología L4S

  • Comparten un enlace a un video demo que usa tecnología L4S en el feed de video de un auto RC

• Presentación de una serie de webinars sobre L4S

  • Si quieres aprender más sobre L4S, presentan una serie de webinars que empieza en understandinglatency.com
  • Participan como ponentes los autores de L4S, la persona a cargo de las pruebas de campo de L4S en Comcast y voces críticas sobre el tema

• Ingeniosa propuesta sobre cómo pronunciar L4S

  • Un comentario dice que le gustaría que L4S se pronunciara "L-Force"

• Problemas de equidad en L4S y cómo resolverlos

  • Surgen problemas si existen actores "maliciosos" que ignoran la retroalimentación de congestión y buscan quedarse con una mayor parte del ancho de banda
  • La solución es complementar L4S con fair queuing y hacer que el control de congestión pueda detectar fair queuing
  • Comparten un enlace de GitHub sobre control de congestión con reconocimiento de fair queuing

• Explicación sobre cómo L4S reduce el bucle de retroalimentación de latencia

  • Comparten un enlace a un video con una explicación de cómo L4S reduce el bucle de retroalimentación de latencia

• Confusión sobre mejoras en videoconferencia y streaming

  • Expresan confusión sobre cómo L4S, basado en TCP, contribuiría a mejorar videoconferencias y streaming, que usan UDP