Resumen

  • ACK Delay expresa la espera intencional del receptor entre recibir el paquete con mayor número reconocido y enviar el ACK.
  • latest_rtt conserva el intervalo local completo antes de aplicar cualquier ajuste por ACK Delay.
  • La interpretación correcta exige ack_delay_exponent, fase del handshake, max_ack_delay y el límite inferior min_rtt.

En muchas tuberías de telemetría, el tiempo entre enviar un paquete y recibir su ACK se toma como RTT, se descodifica ACK Delay y se resta. El resultado se presenta después como latencia de red. El procedimiento parece razonable, pero atribuye al protocolo una precisión que no ofrece. ACK Delay es un informe del receptor sobre una espera deliberada que este controla. No es una lectura directa de propagación, colas de red, latencia unidireccional ni de todo el tiempo consumido en el equipo remoto.

El campo tiene un alcance concreto: cubre la espera entre la recepción del paquete con el número más alto incluido en el reconocimiento y la transmisión del ACK. No representa cada paquete de los rangos ACK. Tampoco incluye los retrasos que el extremo no controla, como el tiempo que un paquete puede pasar en el sistema operativo antes de que QUIC lo procese. El retraso provocado por la falta de claves puede entrar en el informe según las reglas aplicables, pero eso no lo convierte en un medidor universal del procesamiento del host.

El emisor calcula primero latest_rtt con su hora de envío del mayor paquete recién reconocido que solicita ACK y la hora local en que llega el ACK. Por eso el valor bruto contiene el intervalo completo observado. ACK Delay se utiliza después, al calcular smoothed_rtt y rttvar. El campo codificado necesita ack_delay_exponent y los parámetros de transporte correspondientes; sin ellos, un número aislado no es una duración utilizable. El exponente predeterminado es 3. max_ack_delay se expresa en milisegundos y tiene un valor predeterminado de 25 ms, pero los valores predeterminados no sustituyen la negociación real.

min_rtt se obtiene solo de observaciones locales y no se reduce con el ACK Delay comunicado por el par. Es un suelo contra informes erróneos, no una medición de latencia de red pura ni de ida. Tras confirmar el handshake, el emisor usa el menor valor entre el ACK Delay descodificado y max_ack_delay del par, y nunca deja que el ajuste empuje la muestra por debajo de min_rtt. Antes de esa confirmación, max_ack_delay no se usa como límite; pueden aparecer esperas mayores, incluida la espera por disponibilidad de claves.

Un exceso tampoco identifica una causa por sí mismo. Tras la confirmación, el algoritmo trata el retraso que supera max_ack_delay como parte efectiva del retraso del camino, pero la observación puede ser compatible con el planificador del par, pérdida de ACK anteriores o un receptor que incumple las reglas. La autenticación protege el paquete, no demuestra que la declaración sea correcta. Y el dato no prueba procesamiento de aplicación, respuesta del servicio, finalización duradera ni resultado comercial.

La evidencia útil debe conservarse en un registro: conexión y camino, espacio de números, paquete mayor y hora de envío, llegada y procesamiento del ACK, latest_rtt bruto, campo y valor descodificado de ACK Delay, ack_delay_exponent, max_ack_delay del par, estado del handshake, min_rtt, límite y suelo aplicados, muestra ajustada, smoothed_rtt, rttvar y PTO. Separe rangos ACK, disponibilidad de claves, procesamiento local, pérdida de ACK y tiempos de aplicación. El ajuste del estimador no debe renombrarse como medición física.