Resumen

  • Un aviso de duplicación puede mostrar que una retransmisión concreta fue innecesaria, pero no que todos los segmentos de esa ventana llegaran sin pérdidas.
  • RFC 3708 solo permite concluir que se puede deshacer el cambio de congestión cuando todos los elementos retransmitidos de la ventana anterior están reconocidos y marcados como duplicados, sin que se active una condición de parada.

El ejemplo decisivo casi invita al error. El emisor retransmite los segmentos N y N+1. Solo se perdió N; N+1 simplemente llegó tarde. Cuando el receptor marca N+1 como duplicado, el emisor descubre que esa retransmisión sobraba. No descubre que la red no perdió nada: N sigue siendo una señal real de pérdida. Restaurar el estado de congestión de toda la ventana borraría una evidencia que aún importa.

Esa es la distinción central de RFC 3708, un memorando Experimental publicado en febrero de 2004. Expone métodos prudentes para utilizar los avisos de duplicados de TCP DSACK y de SCTP mediante números de secuencia de transmisión duplicados (TSN). Distingue dos usos. Una pila puede contar notificaciones para supervisión o contabilidad. Si el emisor quiere deshacer cambios de control de congestión, necesita el algoritmo de desambiguación, bastante más exigente.

El algoritmo pregunta primero si se retransmitió el rango de secuencia o TSN informado. Si se retransmitió más de una vez durante esa ventana, el procesamiento se detiene y no se restaura el estado anterior de congestión. Si el emisor nunca lo retransmitió, el aviso puede indicar que la red replicó el paquete. RFC 3708 pide entonces dejar de usar este algoritmo durante el resto de la conexión: los informes siguientes serían más difíciles de atribuir a retransmisiones innecesarias del propio emisor.

Ni siquiera un aviso que coincide con una retransmisión basta. El emisor revisa todos los segmentos o fragmentos retransmitidos en la ventana de datos anterior. Solo si todos están reconocidos y marcados como duplicados concluye que todas esas retransmisiones fueron espurias y que no hubo pérdidas en esa ventana. Si queda una retransmisión sin esa marca, el aviso no permite concluir nada. Otra salvaguarda detiene el proceso cuando la tabla SACK TCP está vacía y el DSACK empieza en SND.UNA, patrón compatible con la pérdida de una ventana completa de ACK. En tal situación, reducir la velocidad sigue siendo lo prudente.

El método necesita memoria adicional: además del estado normal de recuperación SACK, la implementación conserva qué números de secuencia o TSN ya fueron reconocidos como duplicados. Eso permite una inferencia acotada, no certidumbre sobre la honestidad del receptor ni sobre todos los sucesos del trayecto. La sección de seguridad advierte que un receptor podría etiquetar como duplicados datos reordenados durante una pérdida real y causar una modificación peligrosa del estado de congestión.

RFC 2883 define cómo el receptor codifica datos duplicados mediante bloques D-SACK, pero no ordena al emisor qué hacer. RFC 3522 sigue otra vía: Eifel puede detectar antes una retransmisión espuria usando marcas de tiempo TCP, a cambio de incluir la opción de marca de tiempo en todos los paquetes. RFC 3708 es más lento, pero enseña a separar dos preguntas: si sobró una retransmisión y si la evidencia permite declarar limpia la ventana entera. No especifica qué acción tomar una vez detectada.

Fuentes: RFC 3708, estado de RFC 3708, RFC 2883, RFC 3517, RFC 3522, RFC 2960, RFC 4960.