显式拥塞通知 (ECN)，为什么路由器不发出通知？

Question

引用维基百科：

“当两个端点都支持 ECN 时，它们会用 ECT(0) 或 ECT(1) 标记其数据包。路由器将 ECT(0) 和 ECT(1) 代码点视为等效。如果数据包穿过正在经历拥塞的主动队列管理 (AQM) 队列（例如，使用随机早期检测 (RED) 的队列），并且相应的路由器支持 ECN，则它可能会将代码点更改为 CE，而不是丢弃数据包。此操作称为“标记”，其目的是通知接收端点即将发生拥塞。在接收端点，此拥塞指示由上层协议（传输层协议）处理，并需要回送到发送节点，以通知其降低传输速率。“

因此，拥塞反馈机制是在传输层 (TCP) 中通过接收端发送 ECE 标志设置为 1 的段来执行的。我的问题是，为什么首先遇到拥塞的路由器不立即将 ICMP 消息发送回发送方（我知道 ICMP 没有拥塞选项，但是，不能简单地实现吗？），以便发送方可以更早地减少其拥塞窗口？为什么要等到数据报到达接收端？如果段到达接收端的时间足够长，导致发送方突发传输导致缓冲区膨胀（可能通过早期通知可以防止这种情况），从而导致路由器上的其他连接即使可能持续很短的时间也会经历高延迟和抖动，会发生什么情况？

这种情况可能对网络产生的有益影响不值得付出努力，而接收端之所以会回应拥塞，可能是因为路由器无法在众多连接受到监管的环境中准备控制消息。但是，我找不到有关此主题的任何资料。

此外，我最初认为数据包可能需要经过所有路由节点才能明确哪些节点正在经历拥塞，但是，在帧、数据报和段头字段中都没有跟踪单个节点的信息选项。我认为段到达接收端发送拥塞反馈而不是由路由器直接发送的另一个原因是将拥塞控制保持在传输层（特别是 TCP）上，但互联网层（例如 IPv4）也通过 2 位 ECN 字段支持拥塞信息，这让我对这个原因产生了怀疑。不过，我不确定我的推理是否具有实际意义。

Answer 1

我的问题是，为什么第一个遇到拥塞的路由器不立即向发送方发送回 ICMP 消息（我知道 ICMP 没有拥塞选项，但是，不能简单地实现吗？）

这种机制早在 1980 年就已存在——它是ICMP“源抑制”消息。（它得到了已删除于 1995 年；我想我记得读过一些关于它存在不够精确的问题并且受到欺骗的“Source Quench”数据包的影响的帖子。）

因此，已经有人讨论过ECN 与源抑制：

• 根据https://wiki.geant.org/pages/releaseview.action?pageId=121340501：

  ICMP Source Quench 的最大问题是：

  • 该机制会导致在拥塞情况下产生更多流量（尽管是在另一个方向）
  • 当 ICMP 源抑制消息丢失时，它无法减慢发送方的速度。

• 根据https://personal.utdallas.edu/~kxs028100/courses/Papers/explicit-congestion-notification.pdf：

  源抑制消息很少使用，部分原因是它们会在拥塞时消耗网络带宽 [...] 在草案中，源抑制消息被批评为消耗网络带宽，并且既无效又不公平 [...] 这种慢启动与较小的慢启动阈值相结合的使用使源抑制对于高速环境中的大窗口 TCP 连接特别没有吸引力。

• 根据https://end2end-interest.postel.narkive.com/PlR0pX2J/e2e-ecn-vs-source-quench：

  • ECN 利用目的地能够到达源的优势（源抑制可能无法到达，因为 ICMP 不是端到端的）。
  • ECN 利用 TCP 目的地能够保留状态来重新传输 ECN 信号（出于多种原因，要求路由器保留源抑制重新传输的状态是有问题的）。
  • ECN 不会引入新的流量（保守的“不伤害”属性，因为添加流量来处理过多的流量可能会使情况变得更糟）。