跳到主要内容

5. IP 中的显式拥塞通知

5. IP 中的显式拥塞通知​

本文档规定互联网为初始拥塞提供拥塞指示 (如 RED 和更早工作 [RJ90] 中那样), 其中通知有时可以通过标记数据包而不是丢弃数据包来完成. 这使用 IP 头部中的 ECN 字段, 该字段包含两个比特, 形成四个 ECN codepoint, 从 '00' 到 '11'. ECN-Capable Transport (ECT) codepoint '10' 和 '01' 由数据发送端设置, 用于指示传输协议端点具备 ECN 能力; 我们分别称它们为 ECT(0) 和 ECT(1). 本文档中的短语 "the ECT codepoint" 指两个 ECT codepoint 中的任意一个. 路由器将 ECT(0) 和 ECT(1) codepoint 视为等价. 发送端可以逐包自由使用 ECT(0) 或 ECT(1) codepoint 来指示 ECT.

同时使用两个 ECT codepoint, ECT(0) 和 ECT(1), 的主要动机是让数据发送端能够验证网络元素没有擦除 CE codepoint, 并验证数据接收端按照传输协议要求向发送端报告接收数据包中设置了 CE codepoint. 发送端和接收端如何使用 ECT(0) 与 ECT(1) codepoint 之间区别的指导, 将在每个传输协议的单独文档中提供. 特别是, 本文档不涉及 TCP 端节点如何利用 ECT(0) 与 ECT(1) codepoint 之间区别的机制. 只需要单个 ECT codepoint 的协议和发送端 SHOULD 使用 ECT(0).

not-ECT codepoint '00' 指示未使用 ECN 的数据包. CE codepoint '11' 由路由器设置, 用于向端节点指示拥塞. 到达满队列的数据包会被丢弃, 就像不存在 ECN 时一样.

+-----+-----+
| ECN FIELD |
+-----+-----+
  ECT   CE         [Obsolete] RFC 2481 names for the ECN bits.
   0     0         Not-ECT
   0     1         ECT(1)
   1     0         ECT(0)
   1     1         CE

图 1: IP 中的 ECN 字段

使用两个 ECT codepoint 实质上在数据包头部中提供了一个 1-bit ECN nonce, 而路由器在设置 CE codepoint 时必然会 "clear" 该 nonce [SCWA99]. 例如, 清除 CE codepoint 的路由器会更难重构原始 nonce, 因而重复清除 CE codepoint 更可能被端节点检测到. ECN nonce 还处理传输接收端在向传输发送端报告接收数据包中是否设置了 CE codepoint 时可能作弊的问题. 第 20 节更详细讨论了使用两个 ECT codepoint 的动机, 以及第四个 ECT codepoint (即 codepoint '01') 的一些替代可能性. 第 11 节讨论与不理解 ECT(1) codepoint 的早期 ECN 实现的向后兼容性.

在 RFC 2481 [RFC2481] 中, ECN 字段被划分为一个 ECN-Capable Transport (ECT) bit 和一个 CE bit. RFC 2481 中仅设置 ECN-Capable Transport (ECT) bit 的 ECN 字段对应于本文档中的 ECT(0) codepoint, 而 RFC 2481 中同时设置 ECT 和 CE bit 的 ECN 字段对应于本文档中的 CE codepoint. Codepoint '01' 在 RFC 2481 中未定义, 这就是只需要单个 ECT codepoint 时推荐 ECT(0) 的原因.

      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |          DS FIELD, DSCP           | ECN FIELD |
   +-----+-----+-----+-----+-----+-----+-----+-----+

     DSCP: differentiated services codepoint
     ECN:  Explicit Congestion Notification

图 2: IP 中的 Differentiated Services 和 ECN 字段

IPv4 TOS 字节中的 bit 6 和 bit 7 被指定为 ECN 字段. IPv4 TOS 字节对应于 IPv6 中的 Traffic Class 字节, 并且 ECN 字段的定义在两者中相同. IPv4 TOS 字节 [RFC791] 和 IPv6 Traffic Class 字节的定义已被 6-bit DS (Differentiated Services) field [RFC2474, RFC2780] 取代. Bit 6 和 bit 7 在 [RFC2474] 中列为 Currently Unused, 并在 RFC 2780 中被规定为可供 ECN 实验性使用. 第 22 节简要介绍 TOS 字节的历史.

由于 TOS 字节历史上并不稳定, 本文档规定的 ECN 字段用法不能保证与过去对这两个比特的使用向后兼容. 第 22 节讨论这种缺乏向后兼容性的危险.

在使用 ECN 的传输接收端收到 CE packet 之后, 端系统对 ECN-capable transport 所遵循的拥塞控制算法必须与当前对单个丢弃数据包的拥塞控制响应基本相同. 例如, 对 ECN-capable TCP 而言, 对任何包含丢包或 ECN 指示的数据窗口, 源 TCP 必须将其拥塞窗口减半.

要求对 CE packet 的拥塞控制响应与对丢包的响应基本相同, 原因之一是支持 ECN 在端系统和路由器中的增量部署. 某些路由器可能丢弃 ECN-capable 数据包 (例如使用相同的 AQM 策略进行拥塞检测), 而其他路由器在等价拥塞水平下设置 CE codepoint. 类似地, 路由器可能丢弃不具备 ECN 能力的数据包, 但在等价拥塞水平下对 ECN-capable 数据包设置 CE codepoint. 如果对 CE codepoint 的拥塞控制响应不同于对丢包的响应, 这可能导致不同流受到不公平对待.

另一个目标是端系统对拥塞最多每个数据窗口 (或更宽松地说, 每个往返时间) 响应一次, 以避免对单个数据窗口中的多个拥塞指示作出多次响应.

对路由器而言, 只有当路由器原本会把 ECN-capable 数据包作为向端节点指示拥塞而丢弃时, 才 SHOULD 设置该数据包的 CE codepoint. 当路由器缓冲区尚未满, 并且路由器准备丢弃一个数据包以通知端节点发生初始拥塞时, 路由器应首先检查该数据包 IP 头部中是否设置了 ECT codepoint. 如果设置了, 则路由器 MAY 在 IP 头部中设置 CE codepoint, 而不是丢弃该数据包.

所有端节点都具备 ECN 能力的环境可能允许开发设置 CE codepoint 的新准则, 以及端节点响应 CE packet 的新拥塞控制机制. 然而, 这是研究问题, 本文档不再进一步讨论.

当路由器收到 CE packet (即设置了 CE codepoint 的数据包) 时, CE codepoint 保持设置, 数据包正常转发. 当拥塞严重且路由器队列已满时, 随着新数据包到达, 路由器别无选择, 只能丢弃一些数据包. 我们预计, 在大多数端系统具备 ECN 能力并参与 TCP 或兼容拥塞控制机制的 ECN-capable 环境中, 数据包丢弃会变得相对少见. 在资源配置良好的 ECN-capable 环境中, 数据包丢弃主要应发生在瞬态期间或存在不合作源时.

上述关于何时可以设置 CE 而不是丢弃数据包的讨论, 默认适用于所有 Differentiated Services Per-Hop Behaviors (PHBs) [RFC 2475]. PHB 的规范 MAY 更详细说明兼容实现如何在设置 CE 和丢弃数据包之间作出选择, 但这不是必需的. 当丢弃的原因不是拥塞, 或并非希望向端节点发出初始拥塞信号时, 路由器 MUST NOT 设置 CE 来替代丢包 (例如, diffserv 边缘节点可能被配置为无条件丢弃某些类别的流量, 以防止它们进入其 diffserv 域).

我们预计路由器会基于平均队列大小所指示的初始拥塞来设置 CE codepoint, 使用 [FJ93, RFC2309] 中提出的 RED 算法. 据我们所知, 这是当前 IETF 中唯一正在讨论的让路由器在缓冲区溢出前主动丢弃数据包的提案. 然而, 本文档并不试图规定某个具体的主动队列管理机制, 例如 RED; 如有需要, 这项工作留给 IETF 的其他领域. 虽然 ECN 与路由器上需要合理的主动队列管理机制密切相关, 反向关系却并不成立; 主动队列管理机制正在独立于 ECN 开发和部署, 在没有 ECN 的 IP 架构中使用数据包丢弃作为拥塞指示.

最后于 更新