Tcp 为什么在终端主机上部署拥塞控制

为什么在发送方节点部署拥塞控制过程

---

我知道避免在路由器上部署拥塞控制的限制之一是路由器需要保持流状态，这增加了路由器的负担。抛开这一点不谈，是否还有其他缺陷限制在路由器端部署拥塞？

确实存在需要路由器支持或部署在路由器中的拥塞控制。一个例子是XCP（），其中路由器分配带宽而不保持每流状态。另一种是数据中心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可能应该更改分配，但如何更改？如果路由器位于不同的域，并且彼此不信任，那么协商是不可能的。路由器不信任终端系统，因此终端系统无法将分配信息传达给路由器

---

在我看来，主要的问题是定义一个为互联网上所有参与者所接受的拥塞控制政策。端到端原则是在端系统中进行拥塞控制的有力论据。TCP拥塞控制是传输层功能，不应在internet层实现，因为并非所有传输层算法（UDP）都使用它。

根据Maxmin Fairity，分配将为90:10。通过将公平性写入目标函数，例如max sum（log（f_i）），i是每流量，给出比例公平性。然而，这个原始问题是由终端节点（控制流）而不是路由器来解决的。二元性问题可以通过路由器来解决。这取决于如何将问题公式化。一些分布式算法可以解决类似于该问题的多公共流问题。但是，它们部署在很小的区域（如无线传感器网络）。我想知道的是在计算方面有实际的限制。你的评论很清楚。但是，我可能需要进一步了解。>我想知道的是，在计算方面存在实际限制：在数据中心环境中，路由器/交换机每秒应处理尽可能多的数据包。在路由器中引入拥塞控制很可能会带来更多的开销，而不是防止拥塞的收益。第二个问题是协调分配的路由器之间的通信开销。反对路由器拥塞控制的主要论点是端到端原则。拥塞控制不是网络层的一部分。