Resumen

  • PADDING es una trama de un byte, sin contenido ni valor semántico; añade bytes, pero no transporta datos de aplicación, STREAM ni CRYPTO.
  • Un paquete compuesto solo por PADDING está en vuelo y consume la ventana de congestión sin provocar los ACK que la abren; RFC 9000 indica que el emisor SHOULD añadir periódicamente otras tramas ack-eliciting.
  • El cliente MUST ampliar a 1200 bytes cada datagrama UDP que transporte Initial; el servidor MUST hacerlo para un datagrama que transporte un paquete Initial ack-eliciting. Ninguna de las dos reglas prueba progreso.

Un operador ve un datagrama UDP de 1200 bytes y registra «Initial útil». Después observa crecer los bytes en vuelo y lo interpreta como avance. Esa conclusión mezcla registros distintos: longitud del datagrama UDP; límites y tipo de los paquetes QUIC; bytes PADDING; presencia de tramas que provocan ACK; bytes en vuelo; cambios de la ventana de congestión; ACK; estado de la negociación; resultado de la aplicación.

Una trama QUIC PADDING tiene el tipo 0x00 y consiste únicamente en su byte identificador. No tiene contenido ni valor semántico. Puede aumentar el tamaño del paquete, ayudar a alcanzar el mínimo de Initial y reducir parte de la información disponible para el análisis de tráfico. No lleva datos de aplicación, STREAM ni CRYPTO, ni confirmación, resultado o señal de finalización. Sus bytes no prueban procesamiento útil del par, avance de la negociación o entrega a la aplicación.

Un datagrama puede contener un Initial con PADDING junto a otras tramas, o varios paquetes QUIC reunidos. La longitud no revela qué bytes hicieron avanzar la negociación; esa conclusión requiere analizar, en un extremo autorizado, los límites de los paquetes y las tramas protegidas. Un paquete que contiene PADDING puede incluir además una trama ack-eliciting y ser reconocido. El ACK aporta evidencia limitada del procesamiento del paquete; no convierte PADDING en contenido semántico.

RFC 9000 define como ack-eliciting el paquete que contiene una trama distinta de ACK, PADDING y CONNECTION_CLOSE. PADDING por sí solo no provoca que el receptor envíe un ACK. No obstante, un paquete que contiene PADDING cuenta como en vuelo para el control de congestión. Si solo contiene PADDING, consume la ventana sin generar los ACK que la abren. Por eso el emisor SHOULD añadir periódicamente otras tramas ack-eliciting. El aumento de bytes en vuelo no equivale a progreso útil.

La regla de 1200 bytes tiene un alcance concreto. El cliente MUST ampliar cada datagrama UDP que transporte un paquete Initial hasta al menos 1200 bytes, mediante PADDING o coalescencia de paquetes. El servidor MUST hacer lo mismo con un datagrama que transporte un paquete Initial ack-eliciting. La regla prueba el soporte de una MTU razonable del camino y la ampliación del cliente reduce también la amplificación disponible antes de validar la dirección. No exige 1200 bytes de contenido de negociación y no todos los Initial usan PADDING.

Antes de validar la dirección, todos los bytes de carga UDP atribuibles a la conexión cuentan en el límite de tres veces del servidor, incluidos los bytes PADDING. La falta de significado no elimina el coste. PADDING puede modificar tamaños observables y reducir parte de la información del análisis de tráfico, pero no garantiza privacidad ni oculta tiempo, dirección, cantidad de paquetes o todas las longitudes. La retención segura de pruebas y el registro separado son recomendaciones editoriales, no requisitos de QUIC.