QUIC no es lo suficientemente rápido en Internet rápido

• QUIC es un protocolo del que se esperaba un cambio revolucionario para mejorar el rendimiento de las aplicaciones web, pero su desempeño no cumple con lo esperado
• Este artículo analiza de forma sistemática el rendimiento de QUIC en redes de alta velocidad

Resumen

• En Internet de alta velocidad, la pila UDP+QUIC+HTTP/3 muestra hasta un 45.2% menos de tasa de transferencia de datos en comparación con TCP+TLS+HTTP/2
• La brecha de rendimiento entre QUIC y HTTP/2 se amplía a medida que aumenta el ancho de banda disponible
• Este problema se observa en clientes ligeros de transferencia de datos y en los principales navegadores web (Chrome, Edge, Firefox, Opera), en distintos hosts (escritorio, móvil) y en varias redes (banda ancha cableada, celular)
• Afecta no solo la transferencia de archivos, sino también diversas aplicaciones como el streaming de video (hasta un 9.8% menos de bitrate de video) y la navegación web
• Mediante un análisis riguroso de rastreo de paquetes y perfiles del kernel y del espacio de usuario, se identifican las causas raíz
• En particular, el overhead de procesamiento del lado receptor es alto debido al exceso de paquetes de datos y a los ACK de QUIC en espacio de usuario
• Se presentan recomendaciones concretas para mitigar los problemas de rendimiento observados

Causas raíz de la degradación del rendimiento

• Se produce un exceso de overhead de procesamiento de paquetes a nivel de kernel en el lado receptor
  • QUIC no usa UDP GRO (Generic Receive Offload), por lo que debe procesar muchos más paquetes que TCP
  • Esto se confirma por la cantidad mucho mayor de llamadas a la función netif_receive_skb en QUIC
• También se produce un exceso de overhead de procesamiento de paquetes de QUIC en espacio de usuario
  • Hay un gran costo al procesar la gran cantidad de paquetes entregados por el kernel
  • La generación de ACK de QUIC en espacio de usuario también es una causa del overhead

Propuestas para mitigar la degradación del rendimiento

• Introducir UDP GRO en el lado receptor
  • Reduce la cantidad de paquetes que debe procesar la pila UDP, disminuyendo el overhead en kernel y espacio de usuario
  • Sin embargo, desplegar UDP GRO en diversos entornos de cliente puede no ser sencillo
• Mejorar soluciones de offloading como GSO/GRO para adaptarlas a QUIC
  • Permitir el offloading incluso para trenes de paquetes UDP de distinto tamaño
  • Agregar una configuración de pacing adecuada a GSO para evitar congestión de red
• Optimizar la lógica de QUIC en el lado receptor
  • Retrasar el envío de ACK de QUIC para reducir el overhead de generación de respuestas
  • Usar recvmmsg para leer múltiples paquetes UDP a la vez y mejorar el rendimiento
• Usar descargas multihilo
  • En archivos grandes, las descargas multihilo que aprovechan varios núcleos de CPU pueden mejorar el rendimiento de recepción
  • Sin embargo, hay que considerar problemas de equidad

[GN⁺]

Opiniones en Hacker News

• La interfaz de syscall es compleja y la API base es demasiado lenta para paquetes de tamaño normal (unos 1500 bytes)
  • GSO ayuda, pero la API es compleja y recientemente también ha tenido muchos bugs
• Debido a las mitigaciones de Spectre, el costo de syscall ha aumentado
  • Es necesario reemplazar los sockets BSD / la API POSIX
  • uring es complejo, pero hace falta una API de nivel intermedio
• El búfer UDP del sistema es demasiado pequeño por defecto
  • Solo lo usan expertos, y los expertos ajustan la configuración
• Es posible optimizar el stack UDP
  • GSO lo demuestra, pero GSO en sí es caro y complejo
• Algunas optimizaciones disponibles actualmente solo funcionan a escala baja o media
  • Por ejemplo, el binding de conexión para evitar búsquedas de ruta
• Implementar GSO puede mejorar mucho el rendimiento
  • Probablemente será necesario aumentar el tamaño del búfer del lado de la plataforma
• Al inicio de QUIC, el stack UDP estaba menos optimizado que el stack TCP
  • Se necesitan optimizaciones como UDP generic receive offload
• Parece que HTTP/2 también se lanzó con prisa
  • Chrome eliminó el soporte para server push
  • Hace falta pensarlo más
• QUIC y HTTP/2 muestran un rendimiento similar cuando el ancho de banda de red es bajo
  • Cuando el ancho de banda supera los 500Mbps, el rendimiento de QUIC cae
  • Esto es principalmente un problema en redes locales
• Google tiende a trasladar la carga de procesamiento a los usuarios
  • Por ejemplo, el códec de video AV1 se distribuyó a consumidores cuando no había capacidades de decodificación por hardware
• El artículo de investigación está en arXiv
  • https://arxiv.org/pdf/2310.09423
• Se menciona un ping con RTT de 0.23ms
  • Incluso con latencia alta, QUIC sigue siendo lo mejor
• Leer RFC9000 es difícil y complejo
  • La idea de alto nivel de QUIC es simple, pero la especificación exige manejar muchas excepciones
• Se ofrece el PDF gratuito del estudio
  • https://arxiv.org/pdf/2310.09423
• Mover los protocolos de conexión al espacio de usuario podría no ser un buen plan