Resumen

  • El equipo que expuso en RIPE 93 detectó bits ECN borrados en 2.278.845 de 52.916.794 trazas que llegaron a destino: el 4,3 % de esa muestra.
  • El borrado apareció en el 6,7 % de las trazas IPv4 exitosas y el 3,9 % de las IPv6. Negociar ECN al inicio y conservar su marca durante el viaje son pruebas distintas.

Un servidor acepta hablar de congestión. El paquete sale con la marca puesta. Varios saltos después, esa marca llega afeitada. La charla de Danesh Zeynali en RIPE 93 colocó esa escena en la agenda; el trabajo original de su equipo puso números a la pérdida.

De 52.916.794 trazas que alcanzaron servidores web, universidades y direcciones de una lista IPv6, 2.278.845 mostraron bits relacionados con ECN puestos a cero por algún equipo del trayecto. El 4,3 % se refiere a esas trazas completadas. Al separar familias, la tasa llega al 6,7 % para IPv4 y al 3,9 % para IPv6. Son resultados sobre rutas observadas desde siete puntos AWS, con el sesgo de perspectiva que ello implica.

También midieron el saludo inicial. El 94,37 % de los destinos IPv4 y el 93,66 % de los IPv6 negociaron ECN desde los siete puntos de observación. El porcentaje cuenta destinos, no rutas. Y el 3,26 % de los servidores web IPv4 de la muestra incumplió una comprobación básica después de negociar. Si una presentación mezcla esos tres números como si fueran una sola prueba de «ECN listo», ha perdido la ruta antes que el paquete.

La metodología publicada utiliza cuatro traceroutes por destino: distintas marcas ECN y un recorrido de control. En las muestras de extremos, unos pocos sistemas autónomos concentraban buena parte de los borrados; al probar direcciones aleatorias de prefijos, no apareció un AS dominante. Cambiar el mapa de destinos cambia la lista de responsables que merece investigación.

La arquitectura de baja latencia L4S descrita en RFC 9330 depende de ECN. Los extremos pueden estrecharse la mano; si un intermediario borra la marca, la conversación sobre congestión pierde su mensaje más importante.