Resumen

  • Las RFC 9621–9623 separan requisitos y prohibiciones obligatorios de preferencias flexibles; la implementación combina ambos con la política del sistema, la memoria de conexiones anteriores y las opciones disponibles ahora.
  • Ready confirma que una pila admisible alcanzó el estado establecido. No demuestra que ganara cada preferencia ni revela candidatos descartados, datos de caché, reglas de ordenación o resultado de negocio.

El primer equipo abrió una conexión con una red corporativa activa y un historial reciente favorable a QUIC. El segundo estaba en otra red, conservaba otra experiencia y tenía una política distinta sobre interfaces. Ambos entregaron un objeto Connection; ambos emitieron Ready. El contrato abstracto funcionó. Lo que no podía deducirse de ese evento era el recorrido que había producido cada ganador.

RFC 9621 propone una arquitectura donde la aplicación describe propiedades del servicio en lugar de fijar cada mecanismo. RFC 9622 define la API abstracta. RFC 9623 muestra cómo una implementación reúne rutas, protocolos y representaciones del destino, construye ramas y compite con ellas.

La abstracción permite incorporar nuevos transportes sin reescribir todas las aplicaciones. También puede aprovechar varias direcciones, interfaces y caminos. Su precio operativo no es necesariamente peor rendimiento; es que la autoridad de elegir cambia de lugar. Para auditarla hay que observar algo más que la llamada y su éxito.

La intensidad de una propiedad determina quién puede ceder

RFC 9622 asigna cinco valores a muchas propiedades de selección. Require conserva solo opciones que ofrecen la propiedad; si ninguna existe, la operación falla. Prohibit elimina todas las que la ofrecen. Prefer adelanta las opciones deseadas, pero permite seguir sin ellas. Avoid las retrasa, pero no las excluye. No Preference no establece una prioridad aplicativa.

La implementación debe respetar todos los Require y Prohibit. No tiene que convertir Prefer y Avoid en resultados garantizados. De hecho, el documento advierte que el desenlace puede variar con los protocolos, caminos y contextos disponibles.

Esta semántica evita promesas accidentales solo si llega hasta el producto. “Preferir baja latencia” no significa “cumplir una latencia máxima”. “Evitar redes medidas” no significa “nunca facturar datos”. Si el negocio no puede aceptar el sustituto, la propiedad debe ser una restricción o debe existir un control posterior que cierre esa diferencia.

Tampoco conviene usar el nombre de una interfaz como prueba. Wi-Fi no equivale a gratuidad ni privacidad. La red celular no equivale por definición a alto coste. RFC 9622 pide expresar la característica relevante, por ejemplo mediante información de dominio de aprovisionamiento, en vez de inferirla de la etiqueta física.

Tres fuentes pueden vetar la misma rama

La aplicación aporta una parte del mandato. RFC 9623 añade la política dinámica del sistema y la política predeterminada de la implementación. Una administración puede bloquear una red medida, el sistema puede reservar una interfaz para ciertos procesos y el componente de transporte puede aplicar valores iniciales cuando la aplicación no dice nada.

Cada camino elegido debe ajustarse a las restricciones de las tres capas. Si una política impide la acción, la API puede comunicar PolicyProhibited. Sin embargo, RFC 9621 no normaliza una interfaz para leer o modificar la política del sistema, porque sus detalles dependen de la plataforma y no son necesarios para la interoperabilidad de la aplicación.

Así aparece una asimetría. El programa puede declarar una intención portable, pero no recibe obligatoriamente una explicación portable de cómo se combinaron las reglas. El mismo código puede ser correcto en dos equipos y producir ganadores diferentes sin que Ready identifique la causa.

La portabilidad de la forma de la API no debe venderse como portabilidad del resultado. Para esta última harían falta el mismo contexto de red, la misma política, el mismo conjunto de protocolos, la misma memoria y las mismas reglas de carrera.

El orden de las ramas ya es una decisión

RFC 9623 recomienda ordenar la construcción: primero caminos de red, después opciones de protocolo y por último destinos derivados. El orden evita combinaciones inválidas, pero también da precedencia a algunas preferencias.

El ejemplo más claro mezcla una preferencia por Wi-Fi con otra por SCTP. Si el historial indica que SCTP no funciona en Wi-Fi, la rama Wi-Fi ofrece TCP, mientras LTE puede ofrecer SCTP y TCP. Al ramificar primero por camino, Wi-Fi/TCP puede comenzar antes que LTE/SCTP. No existe un único cálculo que sume de forma neutra “Wi-Fi” y “SCTP”; existe un árbol con precedencia.

Un registro que conserve solo el ganador pierde la estructura causal. Para explicar la elección necesita los caminos y protocolos reunidos, las ramas eliminadas, las propiedades que actuaron como filtro y las que solo alteraron el orden.

Los destinos tampoco son constantes. Distintas interfaces pueden resolver un nombre de manera diferente. Un proxy puede cambiar dirección y puerto. Un transporte puede existir en un camino y no en otro. La lista de candidatos tiene fecha, red y entorno.

Competir no significa obedecer al candidato más rápido

RFC 9623 distingue carreras simultáneas, escalonadas y por conmutación tras fallo. Probar todo a la vez reduce espera, pero consume más recursos y deja estado sin usar; por eso no se recomienda como opción general. El modo escalonado abre alternativas con retrasos que pueden depender del RTT previsto. El modo de conmutación espera a que falle una opción preferida.

Esta última elección protege políticas fuertes. Si un proxy debe tener prioridad, lanzar al mismo tiempo la ruta directa puede saltárselo porque fue unos milisegundos más rápida. La estrategia de espera reconoce que el tiempo no siempre es el objetivo dominante.

RFC 8305 formaliza una carrera escalonada conocida para IPv6 e IPv4. TAPS extiende la idea a más dimensiones. El primer candidato que establece comunicación es un ganador legítimo solo después de demostrar que pertenecía al conjunto admisible.

La seguridad fija el límite. RFC 8922 integra parámetros de seguridad con el servicio de transporte. RFC 9623 advierte que un atacante puede bloquear el intento inicial para inducir el secundario. Si el segundo ofrece menos protección, la disponibilidad se convierte en descenso de seguridad. Las alternativas en carrera deben conservar los requisitos duros y propiedades de seguridad equivalentes.

La caché convierte observaciones en poder de selección

Las implementaciones pueden guardar respuestas DNS, sesiones TLS, cookies TCP Fast Open y medidas como RTT, latencia de establecimiento o tasa de éxito. RFC 9040 describe el contexto de compartir información entre bloques de control TCP. El pasado puede ordenar o podar la carrera siguiente.

Eso acelera conexiones, pero crea retroalimentación. Una opción que ganó recibe más observaciones; una que se podó deja de generar evidencia nueva. Un fallo antiguo puede sobrevivir a la reparación del camino. Una medida tomada en una red ya abandonada puede contaminar una decisión actual si su ámbito es impreciso.

RFC 9621 permite separar contextos de conexión para que tickets, caché y multiplexación no vinculen actividades que debían quedar aisladas. La memoria de rendimiento también tiene, por tanto, un perímetro de privacidad.

Una prueba útil no necesita copiar secretos. Puede registrar el ámbito de caché, la clase de dato usada, su edad y el motivo de expiración. Sin esa procedencia, “la caché dijo que era mejor” no es una explicación comprobable.

Lo que acredita Ready

RFC 9623 considera terminada la fase de establecimiento cuando al menos una pila puede transmitir y recibir datos de aplicación. RFC 9622 emite Ready al entrar en el estado establecido. El recibo es local y preciso: ya existe una pila utilizable que debería cumplir las restricciones obligatorias.

No acredita qué preferencia perdió, por qué una rama fue podada, si el remoto procesó un mensaje, si el usuario obtuvo respuesta o si la elección mejoró el servicio. Esas son etapas separadas.

RFC 9623 menciona Network.framework de Apple, NEAT, NEATPy y PyTAPS como implementaciones que seguían el enfoque en cierto grado. La documentación Network de Apple confirma la realidad de una API que reúne protocolos y restricciones de camino. Ni esa documentación ni el anexo equivalen a una certificación uniforme de comportamiento o trazabilidad.

Fuentes