Resumen

  • QUIC DATAGRAM lleva un datagrama de aplicación de forma no fiable y conserva su límite, sin retransmisión ni orden relativo entre mensajes DATAGRAM.
  • max_datagram_frame_size anuncia disposición direccional para recibir, no capacidad, entrega ni procesamiento garantizados.
  • Un ACK demuestra actividad de la capa de transporte, no confirmación de la aplicación ni finalización de la operación en la aplicación.

La frontera importante no es entre “enviado” y “no enviado”, sino entre hechos de capas distintas. Un resultado exitoso de la llamada local puede indicar aceptación por una implementación; no demuestra transmisión por la red, recepción en el par, conservación en memoria ni procesamiento por su aplicación. QUIC DATAGRAM está pensado para mensajes en los que la pérdida puede aceptarse. Preserva una unidad de datos, pero no crea offsets de stream, entrega ordenada de bytes ni retransmisión tras la detección de pérdida. Tampoco ordena un mensaje DATAGRAM con respecto a otro.

También hay que separar el frame QUIC DATAGRAM del datagrama UDP que transporta un paquete QUIC. El frame está dentro del paquete QUIC; el paquete puede viajar dentro de un datagrama UDP. La existencia de cada envoltura produce una evidencia diferente. Confundir el portador UDP con el mensaje de aplicación borra la frontera que el registro operativo necesita conservar.

max_datagram_frame_size se negocia por dirección. El valor predeterminado es cero. Un valor distinto de cero indica disposición para recibir frames conformes en esa dirección, sujeto a las condiciones de negociación y a las reglas aplicables al estado 0-RTT conservado. El emisor no puede superar el valor anunciado. Aun así, la señal no promete memoria, capacidad de procesamiento, entrega futura ni aceptación por la aplicación. El límite efectivo puede ser menor por max_udp_payload_size y por el MTU de la ruta. La extensión no fragmenta frames DATAGRAM; el protocolo de aplicación debe asumir el máximo utilizable menor.

Un frame DATAGRAM pertenece a la conexión QUIC y no tiene identificador de stream. El protocolo de aplicación debe asignar identificadores de flujo lógico, interpretar los datos, decidir la expiración, deduplicar, imponer orden si lo necesita y definir qué significa terminar una operación. El transporte no puede inferir la identidad de un mensaje comercial ni saber si una repetición representa el mismo intento.

Tras la presentación local del datagrama a QUIC, QUIC genera un frame y trata de colocarlo en el primer paquete disponible, sujeto al control de congestión y al pacing. Si todavía no se permite el envío, la implementación debe conservarlo hasta que se permita o descartarlo sin transmitirlo. Una política de expiración de la aplicación puede causar un descarte previo a la transmisión. Por eso, el resultado exitoso de una API debe describirse por su contrato concreto; RFC 9221 no lo convierte en recibo de transmisión, recepción o terminación.

En el receptor, un frame válido debe entregarse a la aplicación de inmediato solo si puede procesarlo y conservar su contenido en memoria. DATAGRAM no tiene control de flujo explícito y no cuenta como datos de stream para los límites ordinarios. La ausencia de bloqueo por crédito no prueba capacidad. El receptor puede descartar un frame que no pueda procesar.

Los frames DATAGRAM solicitan ACK aunque no se retransmitan después de una pérdida detectada. El paquete puede ser reconocido con retraso dentro de los límites normales. Un emisor puede usar paquetes de sondeo para provocar un ACK más rápido. La reordenación puede corregir una evaluación provisional de pérdida. El ACK demuestra procesamiento en la capa de transporte del receptor, no procesamiento exitoso de la aplicación. La persistencia duradera o la finalización de la operación necesita una señal definida por la aplicación.