Resumen

  • El RFC 10055 registra cómo Chromium habilitó ECN sobre UDP en Apple, Linux y Windows; es un documento informativo, no una orden para unificar las API del sistema operativo.
  • La señal solo es útil para una aplicación si el socket la habilita, entrega datos auxiliares por datagrama y el código interpreta correctamente el formato de cada plataforma.

La red puede marcar un paquete y el kernel puede conservar la marca; aun así, el controlador de congestión puede no enterarse. El salto entre IP y espacio de usuario es una frontera operativa, no un detalle invisible.

El RFC 10055 surgió de experimentos para que Chromium utilizara ECN sobre UDP en Apple, Linux y Windows. Su valor es documentar las diferencias que el desarrollador debe manejar. El RFC tiene carácter Informational: no obliga a cada plataforma a adoptar una interfaz determinada y advierte que sus instrucciones reflejan una situación concreta en el momento de redactarse.

El ECN ocupa dos bits del campo IP. El RFC 3168 define la señal de notificación explícita de congestión; L4S amplía su función arquitectónica en el RFC 9330. QUIC, que usa UDP, valida los contadores ECN por ruta y desactiva ECN si detecta incoherencias, conforme al RFC 9000. Esa verificación depende de que el transporte pueda observar las marcas recibidas.

El RFC 10055 separa dos operaciones: solicitar al socket que informe las marcas y extraer la marca de cada datagrama mediante datos auxiliares, normalmente con recvmsg(). En IPv4, Linux, Apple y FreeBSD usan IP_RECVTOS; en IPv6 usan IPV6_RECVTCLASS. Linux añade una condición cuando un socket IPv6 también acepta IPv4: hay que habilitar además IP_RECVTOS. Apple y FreeBSD no necesitan ese paso adicional en el caso descrito.

Windows ofrece WSASetRecvIPEcn() y entrega la información como control data a través de WSARecvMsg. Pero el RFC señala excepciones para sockets de doble pila y direcciones IPv4 representadas como IPv6. Una biblioteca portable debe validar el tipo y configuración real del socket, no inferir capacidad a partir de que la aplicación use IPv6.

También cambia el formato de los datos. Linux, Apple y FreeBSD pueden devolver el byte entero del campo DS, que incluye seis bits DSCP y dos de ECN. Windows comunica únicamente el codepoint ECN mediante IP_ECN o IPV6_ECN. Si el mismo parser aplica a todos los sistemas una extracción diseñada para el byte completo, los resultados pueden dejar de ser comparables.

La emisión presenta otra decisión. Apple, FreeBSD y Linux permiten configurar una marca estable a nivel de socket; para un socket compartido entre conexiones con capacidades distintas puede convenir el marcado por paquete. El RFC indicaba que Windows no ofrecía marcado por socket. Además, escribir IP_TOS o IPV6_TCLASS puede cambiar también DSCP en algunos sistemas. La aplicación debe preservar la configuración existente y coordinar escrituras concurrentes para que la gestión de ECN no altere la política de servicio de otro componente.

Por eso, “recibimos ECN” no debe ser un único booleano de producto. Hay que distinguir una ruta sin marcas de una opción no configurada, un mensaje auxiliar ausente o un valor mal interpretado. La investigación de un cero debe remontarse al cmsg antes de atribuirlo al camino. El RFC advierte además que una implementación desigual puede ayudar a identificar el sistema operativo del host, aunque no ofrece una medición de la prevalencia o eficacia de ese fingerprinting.

Una prueba útil registra, por versión del sistema y familia IP, la opción aceptada, el tipo y tamaño del mensaje de control, el codepoint extraído, la conservación de DSCP y la validación que realiza el transporte. La recepción es un recibo de interfaz; no prueba que el emisor haya ajustado su tasa ni que mejorara el servicio.

El diseño puede mantener un objetivo común pequeño —exponer correctamente la marca de cada paquete sin destruir el DSCP— y permitir que cada sistema lo cumpla mediante su API local. La interoperabilidad se vuelve verificable cuando las pruebas hacen visible cada salto de esa cadena.

Fuentes