【RFC3522 TCP 的 Eifel 检测算法】（翻译）

原文 https://datatracker.ietf.org/doc/html/rfc3522 The Eifel Detection Algorithm for TCP TCP的Eifel检测算法

概述

Eifel 检测算法允许 TCP 发送方检测其是否已进入不必要的丢失恢复后验。它要求为连接启用 RFC 1323 中定义的 TCP 时间戳选项。 Eifel 检测算法利用了 TCP Timestamps 选项消除了 TCP 中的重传歧义这一事实。根据在丢失恢复期间到达的第一个可接受 ACK 的时间戳，它决定是否不必要地进入丢失恢复。 Eifel 检测算法为未来的 TCP 增强提供了基础。这包括通过恢复 TCP 发送方的拥塞控制状态来退出丢失恢复的响应算法。

我们将八位字节的首次传输称为“原始传输”。相同八位字节的后续传输被称为“重传”。在大多数情况下，该术语同样适用于数据段而不是八位字节。然而，通过重新打包，一个段可以包含八位字节的首次传输和重传。在这种情况下，该术语仅在应用于八位字节时才一致。对于 Eifel 检测算法，这没有区别，因为它在重新打包时也能正常运行。

我们使用 [RFC793] 中定义的术语“可接受的 ACK”。这是一个确认先前未确认数据的 ACK。我们使用术语“duplicate ACK”和[WS95]中定义的变量“dupacks”。变量“dupacks”是在发送快速重传之前已被 TCP 发送方接收到的重复 ACK 的计数器。我们使用变量“DupThresh”来指代所谓的重复确认阈值，即需要到达 TCP 发送方以触发快速重传的重复 ACK 的数量。目前，DupThresh 被指定为固定值 3 [RFC2581]。未来的 TCP 可能会实现自适应 DupThresh。

1. 简介

重传歧义问题 [Zh86], [KP87] 是 TCP 发送方无法区分重传后到达的第一个可接受的 ACK 是响应原始传输还是重传。在基于超时的重传和快速重传之后，会出现此问题。 Eifel 检测算法使用 [RFC1323] 中定义的 TCP Timestamps 选项来消除重传的歧义。因此，它允许 TCP 发送方后验地检测它是否已经进入了不必要的丢失恢复。

TCP 发送方的这一附加功能在 TCP 的丢失恢复和拥塞控制算法可能经常被错误触发的环境中非常有用。这可能是由于数据包重新排序、数据包重复或导致虚假超时的数据或 ACK 路径中的突然延迟增加造成的。例如，在广域无线接入网络中，由于切换、由于更高优先级流量（例如语音）引起的资源抢占，或者因为移动发射机穿过无线电覆盖空洞（例如，参见顾01]）。在这样的无线网络中，通常在虚假超时之后发生的通常不必要的返回 N 重传会产生严重的问题。它们会降低端到端的吞吐量，对网络造成无用的负载，并浪费传输（电池）功率。请注意，在此类网络中，无论如何建议使用时间戳 [RFC3481]。

基于 Eifel 检测算法，TCP 发送方可以选择实现专用响应算法。这种响应算法的一个目标是减轻错误触发的损失恢复的后果。这可能包括恢复 TCP 发送方的拥塞控制状态，并避免提到的不必要的返回 N 次重传。另一个目标是调整协议参数，例如重复确认阈值 [RFC2581] 和 RTT 估计器 [RFC2988]。这是为了降低在连接进行时再次错误触发 TCP 丢失恢复的风险。但是，此类响应算法超出了本文档的范围。注意：最初的提议，“Eifel 算法”[LK00]，包括检测和响应算法。本文档只定义了检测部分。响应部分在[LG03]中定义。

Eifel 检测算法的一个关键特性是它已经检测到在丢失恢复期间到达的第一个可接受的 ACK 时，快速重传或超时是否是虚假的。这对于能够避免提到的返回 N 次重传至关重要。另一个特点是 Eifel 检测算法对于 ACK 丢失具有相当强的鲁棒性。

此外，DSACK 选项 [RFC2883] 可用于检测 TCP 发