Resumen

  • PTO activa uno o dos datagramas de sondeo que solicitan ACK y aumenta el backoff.
  • No declara por sí mismo que un paquete se perdió ni demuestra congestión o un ACK perdido.
  • El temporizador, el espacio de números de paquete, la sonda, los ACK posteriores y la pérdida declarada son pruebas distintas.

La confusión aparece cuando una canalización de operaciones convierte un evento de temporizador en una conclusión completa. La expiración de PTO ocurre dentro de un espacio de números de paquete concreto. Indica que los paquetes que solicitan ACK no produjeron el progreso esperado durante el periodo calculado, o que un servidor puede necesitar sondear antes de validar la dirección del cliente. La respuesta es buscar progreso: el endpoint envía al menos una sonda y puede enviar hasta dos datagramas de tamaño completo que solicitan ACK; después aumenta el backoff. Ese paso no identifica ningún paquete perdido.

PTO se mantiene por espacio de números de paquete. Initial, Handshake y Application Data no deben mezclarse en una sola cola. El cálculo ordinario es smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay; en Initial y Handshake, el término max_ack_delay se fija en cero. El PTO de Application Data no se arma antes de la confirmación del handshake. El emisor reinicia el PTO cuando envía o recibe ACK para paquetes que solicitan ACK y cuando descarta las claves Initial o Handshake. Tras el vencimiento, el siguiente periodo duplica el actual; los periodos consecutivos aumentan exponencialmente en los distintos espacios de números de paquete y finalmente quedan limitados por el idle timeout.

La detección de pérdida conserva otra lógica. Un time-threshold loss-detection timer tiene prioridad y el PTO no debe armarse mientras esté establecido. Los ACK posteriores pueden conducir a una declaración por packet threshold o time threshold según RFC 9002. Ese momento posterior no debe retroproyectarse sobre la expiración anterior. Marcar como perdidos todos los paquetes no confirmados al vencer PTO es adelantar una decisión que todavía no tiene su evidencia.

También importa cómo se describe el siguiente datagrama. Si hay datos nuevos, deben usarse. Si no, puede llevarse información ya enviada en una trama nueva y en un paquete nuevo. Cuando no hay datos disponibles, PING u otra trama que solicite ACK puede cumplir la función. RFC 9000 dice que los paquetes QUIC perdidos no se retransmiten completos: la información que necesita reparación se transporta de nuevo en tramas y paquetes nuevos. Enviar información otra vez no es reproducir el mismo paquete; PING y PADDING no contienen información retransmisible.

Antes de validar la dirección, los sondeos del servidor cuentan contra el anti-amplification limit. Si el presupuesto no permite más datos, el servidor no debe armar su PTO hasta que otro datagrama del cliente aumente el presupuesto. El cliente puede necesitar sondear para desbloquear al servidor. Este límite describe una restricción de envío, no demuestra pérdida ni identifica un ACK ausente.

RFC 9002 permite como estrategia de implementación marcar perdidos los paquetes restantes en vuelo en lugar de enviar una sonda. Es una decisión explícita, no el significado de PTO, y puede provocar una reducción innecesariamente agresiva de la tasa del controlador de congestión. Una expiración tampoco demuestra que la congestión causó la falta de progreso, que el receptor procesó datos de aplicación, que un servicio respondió o que una operación empresarial terminó.