Resumen

  • RESET_STREAM_AT sólo puede aparecer después de que el par anuncie el parámetro vacío reset_stream_at. La negociación autoriza una trama; no decide qué bytes tienen valor para la aplicación.
  • Reliable Size es un piso mínimo y puede bajar. Una trama antigua que llega tarde no restablece el número mayor, aunque sus demás campos todavía deben comprobarse.
  • WebTransport protege por una regla propia la cabecera que identifica la sesión. Sin ese contrato superior, “reinicio fiable” no garantiza que el receptor pueda atribuir el flujo abortado.

Aprobado para publicación no significa RFC publicado

El 6 de septiembre de 2026, Marten Seemann y Kazuho Oku presentaron la revisión 11 de QUIC Stream Resets with Partial Delivery. El Datatracker la muestra como Internet-Draft de Standards Track del grupo QUIC. También registra “Submitted to IESG for Publication”, “IANA OK — Actions Needed” y “Approved-announcement to be sent”. La decisión de aprobación existe, pero todavía faltan el anuncio formal y la salida editorial como RFC. Este análisis no inventa un número ni convierte el borrador en norma terminada.

El cambio llega después de la teleconferencia del IESG del 3 de septiembre. La comparación con la revisión 10 revela trabajo sustantivo: una prohibición normativa para el uso no negociado, la palabra “minimum” en la definición de Reliable Size, una explicación precisa de la retransmisión de información, controles de consistencia separados, tratamiento inequívoco del reordenamiento y una salida a cero después de STOP_SENDING.

El resultado muestra que hay varias decisiones, no una sola función. El receptor concede la capacidad. El emisor declara el error, el tamaño final y un compromiso actual. La aplicación reconoce el significado de los primeros bytes. Más tarde, el receptor puede dejar de quererlos. La ingeniería falla cuando una etiqueta comprime esas potestades en un booleano.

La autorización nace en el par

El soporte se anuncia mediante reset_stream_at, parámetro 0x1d cuyo valor debe estar vacío. Un valor no vacío provoca TRANSPORT_PARAMETER_ERROR. La revisión 11 añade que un endpoint MUST NOT enviar la trama de tipo 0x24 si el par no publicó ese parámetro.

No basta con detectar una versión moderna de software, recordar otra conexión o suponer que el destinatario ignorará una extensión desconocida. El estado del handshake actual es la fuente de autoridad. El emisor no puede apropiarse de una capacidad del receptor sólo porque conoce la sintaxis.

En 0-RTT, ambos extremos recuerdan si el servidor anunció la extensión. Si éste acepta los datos tempranos, no puede desactivar la capacidad en la conexión reanudada. Puede rechazar 0-RTT; lo que no puede hacer es aceptar el contexto previo y negar al mismo tiempo la premisa que permitió al cliente construir las tramas tempranas.

Nada de esto asigna significado al prefijo. El parámetro dice “puedo procesar esta extensión”, no “prometo que tu sesión estará identificada” ni “acepto para siempre el primer mínimo que envíes”.

Un mínimo no es un corte exacto

RESET_STREAM_AT lleva Stream ID, Application Protocol Error Code, Final Size y Reliable Size. Final Size mantiene la contabilidad completa del flujo. Reliable Size es la cantidad mínima que debe llegar a la aplicación aun cuando el stream termine con error. Si supera Final Size, hay FRAME_ENCODING_ERROR.

Por debajo del mínimo, la pérdida obliga a retransmitir. Por encima, el emisor debería dejar de hacerlo, pero el stack receptor puede entregar bytes que ya recibió. La aplicación puede ver más que Reliable Size. El campo no ordena borrar datos; define un suelo de servicio.

Ese suelo tampoco queda congelado. Una trama posterior puede anunciar un número menor. Un RESET_STREAM corriente tiene el mismo efecto de entrega que Reliable Size igual a cero. La secuencia es monotónica hacia abajo: reducir está permitido; aumentar, prohibido. Hasta el acuse, deben retransmitirse la información del valor vigente y los bytes que éste protege.

El diseño da al emisor una opción de retirada. Puede abandonar una obligación previa, pero no restaurarla una vez reducida. Para el receptor, el dato operativo es el menor valor válido recibido, no el máximo histórico ni el primero que apareció en el log.

El orden de los paquetes no cambia el orden de las decisiones

Un ejemplo basta. El emisor fija primero 100 bytes y luego reduce a 16. El paquete con 16 puede adelantarse. Cuando llega la antigua trama con 100, el receptor mantiene 16. De otro modo, la red podría revivir accidentalmente una obligación que el protocolo sólo permite disminuir.

La revisión anterior decía ignorar la trama que incrementaba Reliable Size. Eso podía leerse como una licencia para saltarse también un Error Code o Final Size contradictorio. La revisión 11 limita el descarte al incremento. El código de error no puede cambiar entre resets; Final Size no puede cambiar entre resets ni frente a STREAM con FIN. Las infracciones siguen causando STREAM_STATE_ERROR y FINAL_SIZE_ERROR.

Cada campo afirma algo distinto. El piso puede estar desactualizado mientras las otras afirmaciones conservan valor probatorio. Esta separación es parte de la seguridad de estado, no una sutileza editorial.

El protocolo de aplicación define lo que no puede perderse

El borrador permite que una aplicación establezca un umbral por debajo del cual Reliable Size no puede bajar. QUIC conoce offsets y retransmisiones, pero no sabe qué contenido crea una relación de negocio o de protocolo.

En WebTransport over HTTP/3, la revisión 16 exige que un reset de stream de datos use RESET_STREAM_AT y cubra al menos la cabecera WebTransport. Allí vive el ID que asocia el stream con una sesión. Si el ID se pierde, el receptor puede tener un error sin dueño: no sabe qué sesión debe contabilizarlo ni qué estado liberar.

El borrador Media over QUIC Transport formula una obligación más flexible. Reliable Size debería incluir la cabecera del subgroup stream para identificar la suscripción y contabilizar los streams reseteados al procesar PUBLISH_DONE. Sin un prefijo adecuado, el estado puede sobrevivir hasta timeout.

No conviene traducir MUST y SHOULD como si fueran la misma política. Cada protocolo decide cuánto pesa la identidad frente a la retirada. La extensión de transporte aporta un mecanismo de mínimo decreciente; la aplicación aporta la razón para limitar esa disminución.

STOP_SENDING cambia quién sigue beneficiándose

STOP_SENDING comunica que la aplicación receptora ya no quiere datos del stream. La revisión 11 recomienda que una respuesta con RESET_STREAM_AT use Reliable Size cero. Insistir en retransmitir un prefijo positivo después de esa señal consume recursos para una parte que ya retiró su interés.

El cero reconduce la operación al reset normal y confirma que la primera promesa puede ceder. En ciertos protocolos, un intermediario aún puede necesitar una cabecera para encaminar el error o cerrar una cuenta en otro salto. Esa excepción debe escribirse como invariante de aplicación, con beneficiario, longitud, límite temporal y forma de reconciliarla con la cancelación.

La fiabilidad no es autoridad ilimitada. Es una obligación acotada. Sin condiciones de salida, el atributo deseable se convierte en retención forzosa de recursos ajenos.

Tras el reset siguen vivos el flujo y la contabilidad

Final Size permanece sometido al control de flujo del stream y de la conexión. Si falta crédito, el emisor puede verse obligado a aplazar RESET_STREAM_AT. Superar el límite del receptor provoca FLOW_CONTROL_ERROR. La trama genera ACK y su información se repite en caso de pérdida; también se recuperan los datos bajo el mínimo vigente.

Por ello, resetear no equivale a liberar de inmediato. El lado emisor llega a Data Recvd sólo después de confirmar la información actual y el prefijo. El receptor espera esos bytes. Durante ese intervalo sigue existiendo exposición a compromiso y agotamiento de recursos.

La observabilidad debe seguir la realidad: negociación, valor inicial, menor valor, Final Size, bytes retransmitidos, bloqueo por crédito, llegada de STOP_SENDING, tiempo hasta estado terminal y objetos que sólo desaparecen por timeout. Una métrica que cuenta resets, sin medir la deuda posterior, favorece la apariencia administrativa.

Límites de lo comprobado

Las fuentes prueban el texto, su evolución y el razonamiento de revisión. No prueban despliegue, rendimiento, interoperabilidad o una incidencia real. No se ensayó ningún navegador, CDN, relay, stack QUIC ni plataforma multimedia. El estado de IANA indica acciones pendientes; no afirmamos que todas las entradas solicitadas sean ya definitivas.

Las revisiones citadas de WebTransport y MoQ también pueden cambiar. Sirven como ejemplos normativos del límite de aplicación, no como predicción de su forma final. La propia revisión 11 sigue dentro del proceso de publicación.

La conclusión duradera es una disciplina de control: permiso de trama, mínimo vigente, prefijo indispensable y deseo de parar pertenecen a autoridades distintas. El running code debe conservarlas como hechos separables y auditables.

Fuentes