主页 / computer / 问题 / 1829530
Accepted
ConventionalProgrammer
Asked: 2024-02-09 21:44:29 +0800 CST

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

  • 772

引用维基百科：

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

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

可能的情况是，这对网络的有益影响并不值得付出努力，而接收端之所以是回显拥塞的一方，可能是因为路由器无法费心在网络中准备控制消息。许多连接都受到监管的环境。但是，我找不到有关此主题的任何来源。

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

networking

1 个回答

  1. Best Answer

    我的问题是，为什么首先遇到拥塞的路由器不立即发送例如ICMP消息给发送者（我知道ICMP没有拥塞选项，但是，它不能简单地实现吗？ ）

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

    因此，已经有关于ECN 与 Source Quench 的讨论：

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

      ICMP 源抑制的最大问题是：

      • 该机制会导致在拥塞情况下产生更多流量（尽管是在另一个方向）
      • 当 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 不引入新流量（保守的“无害”属性，因为添加流量来处理过多流量可能会使情况变得更糟）。
    • 0

相关问题