Resumen

  • El algoritmo Eifel de RFC 3522 compara el timestamp del primer ACK aceptable con el de la retransmisión que inició recuperación. Si el ACK lleva una marca anterior, puede demostrar que el original provocó el reconocimiento y que la recuperación se inició innecesariamente.
  • Esa conclusión no devuelve por sí sola cwnd, ssthresh, el RTO ni el rendimiento. El registro debe separar evidencia de transmisión, clasificación, excepciones, estado previo guardado, algoritmo de respuesta, estado aplicado y resultado del servicio.

La pérdida era una hipótesis que TCP convirtió en acción. Venció un temporizador o llegó el umbral de ACK duplicados; salió una copia; la ventana se redujo. Cuando apareció la marca temporal del original, cambió la explicación del pasado, no el contenido de las variables presentes.

RFC 3522 fue publicada en abril de 2003 como Experimental. No especifica un Internet Standard. Su alcance es deliberadamente pequeño: elimina la retransmission ambiguity mediante TCP Timestamps y decide a posteriori si el emisor entró sin necesidad en loss recovery.

La etapa (RESP) del algoritmo ordena no hacer nada. La respuesta queda para otro documento y otra prueba. Ese espacio vacío evita que una buena inferencia se convierta, sin control, en una restauración universal.

El ACK identifica cuál de las dos historias ocurrió

Al iniciar recuperación, el emisor pone SpuriousRecovery en falso y guarda como RetransmitTS el Timestamp Value de la retransmisión inicial. No debe sobrescribirlo por retransmisiones posteriores del mismo episodio.

Después espera el primer ACK aceptable, es decir, uno que reconoce datos antes no reconocidos. Si su Timestamp Echo Reply es menor que RetransmitTS, ese ACK tuvo que responder a un envío original anterior. Tras las comprobaciones conservadoras, la recuperación puede declararse espuria.

El valor está en decidir con el primer ACK. Tras un timeout falso, ACK de originales demorados pueden empujar al emisor a retransmitir en cadena. Detectar pronto limita ese daño.

Sin embargo, la evidencia es posterior al acto: antes hubo disparador, modificación de estado y una copia enviada. El orden causal forma parte del recibo.

Retraso, reordenación y duplicación comparten máscara

Una subida súbita de demora puede hacer que el RTO expire mientras el ACK ya viaja. La reordenación de tres o más segmentos puede generar los duplicados suficientes para fast retransmit. La duplicación de datos o ACK puede fabricar el mismo patrón.

El detector no adjudica causa. Una marca antigua demuestra qué transmisión fue reconocida, no por qué llegó en ese orden. No identifica operador, enlace, radio ni dominio responsable.

Una fast retransmit innecesaria suele añadir una copia y reducir a la mitad la ventana. Un timeout espurio puede forzar slow start y una secuencia de copias go-back-N. Son costes distintos; una etiqueta común no basta para calcularlos.

También existe el fast timeout: el timer vence antes que el ACK duplicado que habría señalado una pérdida real. Esperar habría cambiado el mecanismo, pero no la necesidad de recuperación. La RFC no lo llama espurio.

Una igualdad no absuelve

La comparación es estricta. El eco debe ser menor que RetransmitTS. Con reloj grueso o camino rápido, original y copia pueden recibir la misma marca. El algoritmo conserva la reducción porque la evidencia no distingue.

Esto parece perder una oportunidad de optimización, pero protege contra rollback por ambigüedad. La ausencia de prueba no se transforma en prueba por conveniencia.

El evento auditable guarda ambos valores, granularidad, operador y rama. Un campo verde «Eifel» borra si el resultado fue positivo, negativo o inconcluso.

Perder todos los ACK cambia el significado de “innecesario”

Puede llegar el original y perderse toda la tanda de ACK. El emisor no tiene otra salida que expirar y retransmitir. La copia repite bytes ya recibidos, pero el timeout era inevitable y la reducción puede señalar congestión del camino inverso.

Al recibir el duplicado, un receptor puede ecoar la marca del último segmento en orden, anterior a la copia. El comparador simple lo confundiría con recuperación falsa.

Por eso el paso 5 incorpora DSACK y comprueba si el ACK cubre todo lo pendiente. En ciertas condiciones termina sin declarar espurio. La negativa a revertir también es resultado del algoritmo.

Registrar solo el valor final pierde qué excepción evitó una conclusión insegura.

Un receptor puede intentar fabricar la absolución

Un receptor que miente puede devolver una marca anterior y presentar una retransmisión genuina como innecesaria. La variante segura almacena timestamps de originales pendientes y requiere coincidencia exacta con el original correspondiente.

La mejora cuesta memoria y depende de que llegue el ACK preciso. Es más sensible a pérdida y reordenación de ACK. Una granularidad pobre facilita adivinar el valor.

«Timestamps activos» no equivale a evidencia confiable. El modelo necesita declarar qué valores se conservaron, qué sabía el receptor, qué podía falsificar y qué incertidumbre se aceptó.

Restaurar exige haber guardado

RFC 3522 menciona posibles respuestas: restaurar estado, impedir retransmisiones posteriores, adaptar DupThresh o estimadores RTT. No las ejecuta.

RFC 4015 define después la respuesta Eifel. Separar documentos refleja separar responsabilidades. Para reponer cwnd o ssthresh, el emisor necesita haber guardado valores previos. Un diagnóstico correcto no reconstruye un número sobrescrito.

Además, una copia espuria puede coexistir con pérdida real en la misma ventana. RFC 3708 muestra ese límite al hablar de DSACK. Probar que el segmento N+1 se retransmitió de más no prueba que N no se perdió.

La respuesta debe declarar qué estado restaura y qué evidencia de congestión conserva. No hay rollback total implícito.

El resultado queda después de la respuesta

Una respuesta puede recuperar variables guardadas, enviar datos nuevos o adaptar un temporizador. Después hay que observar la escritura y el comportamiento: ventana efectiva, retransmisiones siguientes, ACK, pérdida y entrega.

La hoja de ruta TCP y documentos posteriores como RACK-TLP, QUIC y CUBIC mantienen la cautela frente a señales espurias en entornos donde la capacidad también puede haber cambiado de verdad. Son comparación, no prueba de adopción de Eifel.

Si el compromiso es entregar bytes, se conservan rangos reconocidos. Si es latencia, se mide. Si es una operación de aplicación, la aplicación confirma. La corrección de una inferencia de transporte no cierra automáticamente esos resultados.

Diseñar el recibo antes del timeout

Registrar negociación y granularidad temporal, rango original y marca, disparador, contador dupack o timer y variables de congestión antes de reducirlas. Vincular la retransmisión inicial y evitar que RetransmitTS cambie.

Guardar el ACK aceptable, rango, eco, DSACK y salida del paso 5. Identificar variante base o segura. Para la respuesta, versión, variables salvadas, restauradas, adaptadas o retenidas.

Correlacionar luego pérdida real, reordenación, nuevas copias y resultado. Los contadores agregados sirven para tendencias; no explican una restitución discutida.

Límite de la evidencia

Este Artículo no identifica implementación TCP, sistema, proveedor, operador, red, ruta, receptor, usuario, flujo, incidente o despliegue. No afirma adopción, uso de timestamps, pérdida, reordenación, rendimiento, energía, seguridad ni resultado comercial actual.

RFC 3522 se presenta como Experimental de abril de 2003, no como Internet Standard. RFC 4015, 5681, 5682, 6298 y 7323 guardan su ámbito. RFC 9438, 8985 y 9002 son contexto posterior, no evidencia de implementación.

Las notas de Heng Lu sobre autoridad y running code son lentes editoriales declaradas. Ayudan a separar señal, estado y resultado; no expresan intención de IETF.

La conclusión es acotada: el timestamp puede absolver al original, pero la ventana solo vuelve mediante una respuesta separada y verificable.

Fuentes