Resumen

  • RACK usa marcas de tiempo, ACK/SACK, RTT y una ventana de reordenamiento para marcar pérdida; no observa un descarte físico.
  • Un DSACK posterior puede sugerir que la retransmisión fue espuria, pero no identifica la causa de red.
  • El equipo de operaciones debe guardar los insumos de la inferencia y cada copia transmitida, sin convertir la decisión de recuperación en un hecho del incidente.

Recuperar antes de conocer toda la historia

RACK responde una pregunta práctica: ¿hay evidencia suficiente de entregas posteriores y ha pasado tiempo suficiente para retransmitir un rango anterior sin confirmar? El emisor no puede esperar certeza indefinidamente; debe acotar la ambigüedad.

La RFC 8985 exige que otro segmento enviado después haya sido entregado y que el anterior siga sin entrega tras el RTT estimado más la ventana de reordenamiento. Es más sólido que un temporizador aislado, pero sigue siendo una inferencia local en un momento dado.

ECMP, la reparación en enlaces inalámbricos y otros mecanismos alteran el orden. La copia original puede seguir en tránsito cuando se marca perdido su rango. La marca ordena reparar el rango; no declara que alguien vio destruirse ese paquete.

El reloj de RACK forma parte de la decisión

RACK conserva el tiempo de transmisión más reciente de cada segmento, incluidas las retransmisiones. Usa como referencia el segmento enviado más tarde entre los ya entregados y obtiene un RTT reciente.

La ventana de reordenamiento se adapta dentro de límites. Un valor inicial pequeño acelera flujos cortos a cambio del riesgo de retransmisiones espurias. La evidencia de reordenamiento puede ampliarla sin convertirla en espera ilimitada.

TLP cubre los ACK escasos. Antes del RTO, envía datos nuevos o retransmite el segmento con mayor secuencia para provocar respuesta. Ese ACK puede dar a RACK base para inferir pérdidas anteriores; la sonda no observa directamente un descarte.

DSACK cambia el relato retrospectivo

La RFC 2883 permite que el receptor informe un segmento o rango duplicado. Tras una retransmisión, el DSACK solo confirma que llegaron datos duplicados. Unido al historial del emisor, puede sugerir que la retransmisión fue innecesaria, pero no determina qué copia llegó cuándo ni por qué.

Por eso la RFC 8985 recomienda ampliar la ventana cuando DSACK sugiere una retransmisión espuria. DSACK no identifica la cola, radio, enlace, túnel o miembro ECMP responsable. Informa duplicación recibida, no una causa completa.

Fuentes