【RFC3449 网络路径不对称对 TCP 性能的影响】（翻译）

原文 https://datatracker.ietf.org/doc/html/rfc3449 

概述

本文档描述了由于非对称效应而产生的 TCP 性能问题。由于不同的根本原因，这些问题出现在几个接入网络中，包括带宽不对称网络和分组无线b子网。然而，这两种情况下 TCP 性能的最终结果是相同的：由于从接收器到发送器的 ACK 反馈的不完善和可变性，性能通常会显着下降。

该文件详细介绍了对这些影响的几种缓解措施，这些措施已在文献中提出或评估，或者目前已部署在网络中。这些解决方案结合使用本地链路层技术、子网和端到端机制，包括：(i) 管理用于承载 ACK 的上行瓶颈链路的信道的技术，通常使用报头压缩或减少TCP ACK 的频率，(ii) 处理这种降低的 ACK 频率的技术，以保留 TCP 发送方的确认触发的自时钟，以及 (iii) 以相反方向调度数据和 ACK 数据包的技术，以在存在两路流量的时候提高性能。本文描述了每种技术，以及已知问题和使用建议。本文末尾提供了建议摘要。

目录

   1. 本文档中使用的约定
     2. 动机
     2.1 传输和接收容量的差异导致的不对称性
     2.2 反向共享媒体导致的不对称
     2.3 一般问题
   3. 非对称如何降低 TCP 性能？
     3.1 非对称容量
     3.2 MAC 协议交互
     3.3 双向流量
     3.4 非对称网络路径的损失
   4. 使用主机缓解措施提高 TCP 性能
     4.1 修改后的延迟 ACK
     4.2 大的MSS的使用
     4.3 ACK拥塞控制
     4.4 窗口预测机制
     4.5 基于Cwnd估计的确认
     4.6 TCP 发送者起搏
     4.7 TCP 字节计数
     4.8 背压
   5. 使用透明修改提高 TCP 性能
     5.1 类型 0：头部压缩
       5.1.1 TCP 头部压缩
       5.1.2 其他鲁棒性头部压缩算法
     5.2 类型 1：反向链路带宽管理
       5.2.1 ACK 过滤
       5.2.2 ACK 抽取
     5.3 类型 2：处理不频繁的 ACK
       5.3.1 ACK重建
       5.3.2 ACK 压缩和压扩
       5.3.3 减轻由偶发 ACK 产生的 TCP 数据包突发
     5.4 类型 3：上行链路调度
       5.4.1 上游瓶颈链路按流排队
       5.4.2 ACK优先调度
   6. 安全考虑
   7. 总结
   8. 致谢
   9. 参考文献
   10. IANA 考虑
   附录：显示网络路径不对称的子网示例
   作者地址
   完整的版权声明

1. 本文档中使用的约定

FORWARD DIRECTION：非对称网络路径上数据传输的主要方向。它对应于在容量、延迟、错误率等方面具有较好特性的方向。前向的数据传输称为“正向传输”。正向传输的数据包遵循 IP 网络的前向路径。

REVERSE DIRECTION：转发 TCP 传输流的确认的方向。数据传输也可能发生在这个方向（并且被称为“反向传输”），但它通常比正向传输量小。反向通常表现出比正向更差的特性。反向传输的数据包沿着反向路径通过 IP 网络。

上游链路：通常具有比相应下游链路少得多的能力的特定瓶颈链路。拥塞不仅限于这条链路，也可能发生在正向和反向的任何一点（例如，由于与其他交通流共享）。

下游链路：正向路径上的一条链路，对应于上行链路。

ACK：累积的 TCP 确认 [RFC791]。在本文档中，该术语是指携带累积确认 (ACK) 但不携带数据的 TCP 段。

DELAYED ACK FACTOR, d：TCP ACK 确认的 TCP 数据段的数量。 d 的最小值为 1，因为每个数据包最多应该发送一个 ACK​​ [RFC1122，RFC2581]。

STRETCH ACK：Stretch ACK 是一种确认，涵盖超过 2 个先前未确认数据段 (d>2) [RFC2581]。由于实现错误 [All97b, RFC2525] 或由于 ACK 丢失 [RFC2760]，stretch ACK 可以通过设计（尽管这不是标准的）发生。

标准化带宽比，k：前向与返回方向的原始带宽（容量）的比率除以两个方向使用的数据包大小的比率 [LMS97]。

SOFTSTATE：在协议 [Cla88] 使用的网络设备中建立的每个流状态。状态在一段时间后到期（即，会话到期时不需要明确删除），并在流继续的同时不断刷新（即，丢失的状态可以重建而无需交换额外的控制消息）。

2. 动机

几种网络技术表现出非对称特性，包括有线数据网络（例如 DOCSIS 有线电视网络 [DS00、DS01]）、直播卫星（例如，使用数字视频广播的 IP 服务、DVB、[EN97] 与交互式回信道）、甚小孔径卫星终端 (VSAT)、非对称数字用户线 (ADSL) [ITU02、ANS01] 和几个分组无线电网络。这些网络越来越多地被部署为高速互联网接入网络，因此非常需要实现良好的 TCP 性能。然而，网络路径的不对称性通常使这具有挑战性。附录中提供了一些表现出不对称性的网络示例。

不对称性可能表现为发送和接收容量的差异、丢包率的不平衡或发送和接收路径之间的差异 [RFC3077]。例如，当容量不对称时，使得 TCP ACK 使用的反向路径上的容量减少，缓慢或不频繁的 ACK 反馈会降低 TCP 正向性能。类似地，底层媒体访问控制 (MAC) 和物理 (PHY) 协议中的不对称性可能会使传输 TCP ACK（与其大小不成比例）变得昂贵，即使容量是对称的。

2.1 发送和接收容量差异导致的不对称性

网络路径可能是不对称的，因为上行链路和下行链路以不同的速率运行和/或使用不同的技术实现。

当携带 TCP ACK 的尽力而为 IP 流与其他业务流（例如电话）共享可用的上行容量时，容量的不对称性可能会显着增加，尤其是保留了上行容量的流。这包括在 IP 层（例如，有保证的服务 [RFC2212]）或在子网层（例如，使用 DOCSIS [DS01] 中的主动授权服务支持 IP 语音 [ITU01]，或在ADSL 上的 ATM [ITU02, ANS01]的虚拟CBR连接）。

当存在多个上行链路时，可以通过在多个可用上行链路之间划分上行流量来减少不对称性。

2.2 反向的共享媒体导致的不对称

在采用集中式多路访问控制的网络中，不对称性可能是网络中心辐射式架构（即单个基本节点与多个下游节点通信）的基本结果。中央节点通常会产生较少的传输开销，并且在调度其自己的下游传输时不会产生延迟。相比之下，上行传输会受到额外的开销和延迟（例如，由于传输突发之间的保护时间和争用间隔）。这会产生显着的网络路径不对称。

由于每个节点必须首先使用争用 MAC 协议请求每个数据包的带宽（例如，DOCSIS 1.0 MAC 限制每个节点在每个上行时分间隔 [DS00] 中最多发送一个数据包），上行容量可能会进一步受到限制）。采用动态按需分配带宽 (BoD) 的卫星网络也为每个发送的数据包消耗 MAC 资源（例如，[EN00]）。在这些方案中，可用的上行链路容量是 MAC 算法的函数。 MAC 和 PHY 方案还引入了每次上行传输的开销，这可能对于传输短数据包（包括 TCP ACK）很重要，变得与传输 MTU 大小的数据包一样昂贵。

2.3 一般问题

尽管依赖于容量的不对称性和依赖于 MAC 的不对称性之间存在技术差异，但由于相同的根本原因，两种网络路径都会降低 TCP 性能：ACK 反馈的不完善性和可变性。本文档详细讨论了该问题并描述了可以减少或消除约束的几种技术。

3. 非对称如何降低 TCP 性能？

本节描述网络路径不对称对 TCP 性能的影响。读者可参考 [BPK99, Bal98, Pad98, FSS01, Sam99] 了解更多细节和实验结果。

3.1 非对称容量

当前向和返回路径具有非常不同的容量时，降低单向传输性能的问题取决于上行链路的特性。对于此类网络路径上的单向流量，会出现两种类型的情况：当上游瓶颈链路有足够的队列以防止数据包 (ACK) 丢失时，以及当上游瓶颈链路具有小缓冲区时。每个都被依次考虑。

如果上游瓶颈链路有很深的队列，因此这不会在相反方向丢弃 ACK，那么性能是归一化带宽比 k 的强函数。例如，对于 10 Mbps 的下行链路和 50 Kbps 的上行链路，原始容量比为 200。对于 1000 字节数据包和 40 字节 ACK，数据包大小的比值为 25。这意味着 k 为 200 /25 = 8。
因此，如果接收方确认比每 8 (k) 个数据包一个 ACK​​ 的频率更高，则上游链路将在下游链路之前变得饱和，从而限​​制了前向的吞吐量。请注意，达到的 TCP 吞吐量由接收方通告窗口或 TCP 拥塞窗口的最小值 cwnd [RFC2581] 决定。

当使用延迟 ACK 时 如果ACK 没有被丢弃（在上游瓶颈链路上）并且 k > 1 或 k > 0.5 [RFC1122]，则 TCP ACK 时钟中断。考虑由发送方快速连续发送的两个数据包。在到达接收器的途中，这些数据包根据前向最小瓶颈链路的容量分开。 ACK 时钟的原理是响应接收这些数据包而生成的 ACK 将这个时间间隔一直反映到发送方，使其能够传输保持相同间隔的新数据包 [Jac88]。带有延迟 ACK 的 ACK 时钟反映了实际触发 ACK 的数据包之间的间隔。然而，有限的上行容量和上行瓶颈路由器的排队改变了反向路径的 ACK 间隔，因此在发送方被观察到。当 ACK 以比链路可以支持的速度更快的速度到达上游瓶颈链路时，它们会相互排在后面。当它们从链路出现时，它们之间的间距相对于它们的原始间距被扩大，是上游瓶颈容量的函数。因此，TCP 发送方以比没有 ACK 排队时更慢的速率输出新数据包。连接的性能不再单独依赖于下游瓶颈链路；相反，它受到到达 ACK 的速率的限制。作为副作用，发送方的 cwnd 增长速度也减慢了。

当反向路径上的上游瓶颈链路饱和时，会出现第二个副作用。饱和链路会导致数据包持续排队，导致所有使用瓶颈链路的终端主机观察到的路径往返时间 (RTT) [RFC2998] 增加。这会影响协议控制循环，也可能触发错误超时（发送主机低估路径 RTT）。

当上游瓶颈链路具有相对少量的缓冲空间来容纳 ACK 时，就会出现不同的情况。随着传输窗口的增长，这个队列被填满，ACK 被丢弃。如果接收方要确认每个数据包，则每 k 个数据包中只有一个ACK 将发送给发送方，其余 (k-1) 由于上游链路缓冲区的缓冲区溢出而被丢弃（这里 k 是前面提到的归一化带宽比）。在这种情况下，反向瓶颈链路容量和缓慢的 ACK 到达率不会直接导致任何性能下降。但是，ACK 的频率低会导致性能下降的三个原因：

1. 发送方以大量突发数据包的形式传输数据，仅受可用 cwnd 的限制。如果发送方在 k 中仅收到一个 ACK​​，它会以 k（或更多）个数据包的突发形式传输数据，因为每个 ACK​​ 将滑动窗口移动至少 k 个（已确认的）数据包（TCP 数据段）。这增加了沿前向路径丢失数据包的可能性，尤其是当 k 很大时，因为路由器不能很好地处理大量突发数据包。

2. 当前的 TCP 发送方实现通过计算收到的 ACK 数量而不是每个 ACK​​ 实际确认的数据量来增加其 cwnd。后一种方法，也称为字节计数（第 4.7 节），是在拥塞避免期间增加 cwnd 的标准实现选项 [RFC2581]。因此，较少的 ACK 意味着 cwnd 的增长速度较慢，这会降低长延迟连接的性能。

3. 发送方 TCP 的快速重传和快速恢复算法 [RFC2581] 在 ACK 丢失时效果较差。即使接收方发送的数据超过 DupACK 阈值（> 3 个 DupACK）[RFC2581]，发送方也可能不会收到阈值数量的重复 ACK。此外，在快速恢复期间，发送方可能没有收到足够多的重复 ACK 来充分扩