为什么拥塞控制过程部署在发送节点?
我知道避免在路由器上部署拥塞控制的限制之一是路由器需要维护流状态,这增加了路由器的负担。撇开这个不谈,还有其他限制在路由器端部署拥塞的缺陷吗?
为什么拥塞控制过程部署在发送节点?
我知道避免在路由器上部署拥塞控制的限制之一是路由器需要维护流状态,这增加了路由器的负担。撇开这个不谈,还有其他限制在路由器端部署拥塞的缺陷吗?
确实存在需要路由器支持或部署在路由器中的拥塞控制。一个例子是 XCP ( https://www.ietf.org/proceedings/61/slides/tsvwg-5.pdf ),其中路由器分配带宽而不保持每个流的状态。另一个是数据中心 TCP,它使用路由器提供的 ECN 标记来检测拥塞程度。这两个示例适用于具有一个权限的网络。在互联网上有许多具有不同目标的权威/行为者。如果我们将拥塞控制放在路由器中,我们选择什么拥塞控制策略?
假设您有两个流,A 和 B,以及两个路由器,R1 和 R2。R1 的容量为 100Mbit/s,R2 的容量为 10Mbit/s。流 A 仅流经 R1,流 B 流经 R1 和 R2。假设我们平均分享 R1 的容量,A 和 B 各获得 50Mbit/s。B经过只有10Mbit/s的R2,所以无法使用R1给它的50Mbit/s。在这种情况下应该怎么办?R1 应该可能会更改分配,但如何?如果路由器位于互不信任的不同域中,则协商是不可能的。路由器不信任终端系统,因此终端系统无法将分配信息传达给路由器。
在我看来,主要问题是定义一个被 Internet 中所有参与者接受的拥塞控制策略。在终端系统中进行拥塞控制的一个强有力的论据是端到端原则。TCP 拥塞控制是传输层功能,不应该在互联网层实现,因为它不是所有传输层算法 (UDP) 都使用的。