【RFC6582 TCP快速恢复算法的NewReno修改】（翻译）

原文 https://datatracker.ietf.org/doc/html/rfc6582  The NewReno Modification to TCP's Fast Recovery Algorithm TCP快速恢复算法的NewReno修改

RFC 5681 记录了以下四种相互交织的 TCP 拥塞控制算法：慢启动、拥塞避免、快速重传和快速恢复。 RFC 5681 明确允许对这些算法进行某些修改，包括使用 TCP 选择性确认 (SACK) 选项 (RFC 2883) 的修改，以及在没有SACK的情况下响应“部分确认”的修改（覆盖新数据的 ACK，但不是所有未完成的数据）检测到丢失）。本文档描述了一种用于响应部分确认的特定算法，称为“NewReno”。这种对部分确认的回应最初是由 Janey Hoe 提出的。本文档废弃了 RFC 3782。

1. 简介

对于 [RFC5681] 中描述的 TCP 快速恢复算法的典型实现（首先在 1990 BSD Reno 版本中实现，并在 [FF96] 中称为“Reno 算法”），TCP 数据发送方仅在重传超时发生后或在三个重复确认到达触发快速重传算法后才重传数据包。一次重传超时可能会导致重传多个数据包，但每次调用 RFC 5681 中的快速重传算法只会导致重传单个数据包。

当在单个窗口中发生多个数据包丢失时，Reno TCP 会出现两个问题。首先，Reno 通常会超时，如 [Hoe95] 中所述。其次，即使避免了重传超时，也可能发生多次快速重传和窗口减少，如 [F94] 中所述。当发生多个数据包丢失时，如果 SACK 选项 [RFC2883] 可用，则 TCP 发送方有信息来智能决定在快速恢复期间重传哪些数据包以及不重传哪些数据包。

本文档适用于无法使用 TCP 选择性确认 (SACK) 选项的 TCP 连接，要么是因为该选项不受本地支持，要么是因为 TCP 对等方未表示愿意使用 SACK。

在没有 SACK 的情况下，TCP 发送方在快速恢复期间进行重传决策时可用的信息很少。从三个重复的确认中，发送方推断数据包丢失，并重新传输指示的数据包。在此之后，数据发送方可以接收额外的重复确认，因为当发送方进入快速重传时，数据接收方确认已经在传输中的额外数据包。

在从单个数据窗口丢弃多个数据包的情况下，当发送方收到对重传数据包的确认（即第一次进入快速重传时重传的数据包）时，发送方可用的第一个新信息就会出现。如果有单个数据包丢失且没有重新排序，则该数据包的确认将确认在进入快速重传之前传输的所有数据包。然而，如果有多个数据包丢失，则对重传数据包的确认将确认在快速重传之前传输的部分而非全部数据包。我们称这种确认为部分确认。

连同其他一些建议，[Hoe95] 建议在快速恢复期间，TCP 数据发送方通过推断下一个顺序数据包已丢失并重新传输该数据包来响应部分确认。本文档描述了对 RFC 5681 中快速恢复算法的修改，其中包含对快速恢复期间收到的部分确认的响应。我们称这种改进的快速恢复算法为 NewReno，因为它是历史上被称为 Reno 的行为的轻微但显着的变化。本文档不讨论 [Hoe95] 和 [Hoe96] 中的其他建议，例如在慢启动期间更改 ssthresh 参数，或在快速恢复期间为每两个重复确认发送一个新数据包的建议。本文档中的 NewReno 版本也借鉴了文献 [LM97] [Hen98] 中对 NewReno 的其他讨论。

对于无法使用 SACK 的 TCP 连接，我们并不声称此处描述的 NewReno 版本的快速恢复是响应部分确认的快速恢复的最佳修改。根据我们在称为 ns-2 [NS] 的网络模拟器中对 NewReno 修改的经验以及 NewReno 的大量实现，我们相信这种修改提高了快速重传和快速恢复算法在各种场景中的性能。此 RFC [RFC2