问题标签 [congestion-control]

TCP Reno、HSTCP、STCP 还是快速 TCP？或者我们可以用当前流行的内核改变算法？

我尝试使用 Mininet 模拟由 2 个主机和 1 个交换机组成的网络。一台主机作为发送方，使用 iperf 工具不断地向另一台主机（接收方）发送数据包。

H1----------------------------------------开关-------- ------H2

--------100Mbps|0.125ms------------100Mbps|0.125ms------

主机和交换机之间的链路带宽为100Mbps，延迟为0.125ms。

每个发送的数据包大小为 1.5KB，Switch 有 400 个数据包的缓冲区。

每条链路的延迟为 0.125ms，因此 H1、H2 之间的 RTT 为 4*0.125=0.5ms

CWND（拥塞窗口）是发送方在一个 RTT 中发送的数据包数，因此吞吐量计算为：吞吐量 = CWND/RTT。

因为 MAX(吞吐量) < 带宽所以 CWND < RTT*bandwidth=0.5*10^(-3)*100*10^6=50000b~6KB = 4packets

但是当我使用 tcp_probe 工具监控 CWND 时，它令人惊讶地显示 CWND 总是大于 200KB（~120packets），比我预期的要大得多。

即使缓冲区是 400 个数据包，但它不能有这么大的 CWND。

请为我解释一下，我真的被这个问题困住了。谢谢！

2台主机通过交换机与link1、link2对应连接。

H1--------开关---------H2

交换机具有缓冲区 B（数据包大小）和支持 ECN。当缓冲区队列超过 K（数据包大小）时，它将标记数据包。

Link1 的带宽 bw1 大于 link2 bw2 和 host1 连续发送数据包的带宽。

Host1 通过增加拥塞窗口来提高其发送速率。因为 bw1>bw2 所以一段时间后，交换机必须缓冲数据包。如果队列接近 K 阈值，交换机将使用 ECN 标记数据包。

假设有一次，host1 有拥塞窗口 CW1。这意味着从那时起，在一个 RTT 中，最多有 CW1 数据包在传输中。

那么，在一个 RTT 中，有多少个被 ECN 在交换机上标记的数据包。我想计算分数。

谢谢你。

假设我们谈论许多发送者向接收者发送数据包的情况。
通常，发送者会通过使用限制发送速率的滑动窗口来控制拥塞。

我们有：

使用来自网络（路由器、交换机）的显式或隐式反馈信息，发送方将cwnd控制发送速率。

通常，rwnd总是足够大，发件人只关心cwnd。但是如果我们考虑rwnd，用它来限制snd_cwnd，它会使拥塞控制更有效。

rwnd是接收器能够接收的数据包（或字节）数。我关心的是发件人的能力。

问题：
1. 那么接收方如何知道有多少流向它发送数据包？
2. 接收方是否知道发送方的 snd_cwnd？

假设一台主机与其他主机一起向一台主机发送数据包。所有主机都连接到支持 ECN 标记的交换机。

如果它加入的时间是网络拥塞和交换机标记每个数据包传入的时间。

但是这个主机只是在慢启动阶段开始，当它发送第一个数据包时，它会被标记为 ECN。

那么，该主机是否仍处于慢启动或进入拥塞避免阶段？

DCTCP 是用于数据中心环境的 TCP 的变体。来源在这里

DCTCP 使用商品交换机中的 ECN 功能将交换机中缓冲区的队列长度限制在阈值 K 左右。这样做，很少发生丢包，因为 K 远小于缓冲区的容量，因此缓冲区几乎没有满。

DCTCP 实现了小流的低延迟，同时保持大流的高吞吐量。原因是当队列长度超过阈值 K 时，将向发送者反馈拥塞通知。在发送方，随着时间的推移计算拥塞概率值，因此发送方将根据拥塞程度相应地降低发送速率。

DCTCP 指出，小队列长度将减少延迟或流的传输时间。我对此表示怀疑。因为除非丢包导致重传等高延迟。在 DCTCP 中，丢包很少发生。

• 交换机上的小队列迫使发送者降低发送速率，因此迫使数据包在发送者的 TX 缓冲区中排队。

• 交换机上更大的队列使发送方具有更高的发送速率，并且数据包在发送方的 TX 缓冲区中排队，现在它在交换机的缓冲区中排队。

所以我认为小队列和大队列的延迟仍然是一样的。

你怎么看？

下面的 tcpdump 日志是从我最近运行的测试中复制的。一开始一切都很顺利。然后客户端最终压倒了路由器，然后很多数据包 [# - 6176] 被丢弃（永远不会看到它们的 ACK）。然后在 6177，由于 rto 定时器超时而触发重传。

所以这里有问题：

1. 当有重传时，发送方拥塞窗口（snd_cwnd）会发生什么？操作系统是 linux 内核 3.4.42。如前所述，当重新传输时，snd_cwnd 将减少为 1。如果是这样，为什么还可以发送6179、6180包？
2. 为什么 6179、6180 没有得到确认？相反，6178 可以得到确认，这意味着数据包可以通过。

I am currently studying the Additive Increase Multiplicative Decrease method, used in TCP as congestion avoidance technique. If we have K TCP sessions sharing a common link of bandwidth R, it is said that this technique guarantees fairness for all the sessions, i.e, each session will have a throughput of R/K.

Now, I'd like to prove this fairness mathematically (reaching the conclusion that, regardless of the initial values of the throughput of each session, they will all eventually tend to R/K).

Thanks !

AIMD Additive increase Multiplicative Decrease CA 算法在检测到丢失时将拥塞窗口的大小减半。但是，除了“直觉”之外，有哪些实验/统计或理论证据表明除以 2 是最有效的方法（而不是另一个数值）？有人可以向我指出支持这一观点或调查这一主张的出版物或期刊论文吗？

我想弄清楚的问题是：

在这个问题中，我们考虑 TCP 慢启动阶段引入的延迟。考虑通过一个速率为 R 的链路直接连接的客户端和 Web 服务器。假设客户端想要检索大小正好等于 15S 的对象，其中 S 是最大段大小 (MSS)。将客户端和服务器之间的往返时间表示为 RTT（假设为常数）。忽略协议头，确定何时检索对象（包括 TCP 连接建立）时

1. 4S/R > S/R + RTT > 2S/R
2. 8S/R > S/R + RTT > 4S/R
3. S/R > RTT

我已经有了解决方案（这是教科书上的问题），但我不明白他们是如何得到答案的。

1. RTT + RTT + S/R + RTT + S/R + RTT + 12S/R = 4 · RTT + 14 · S/R
2. RTT + RTT +S/R + RTT +S/R + RTT +S/R + RTT + 8S/R = 5 · RTT + 11 ·S/R
3. RTT + RTT + S/R + RTT + 14S/R = 3 · RTT + 15 · S/R

这是与答案相关的图像：

哪种对我有意义：每种情况都是 RTT 时间多于或少于传输一定数量段所需时间的情况。因此，对于第一个，每个 RTT 需要 3S/R 到 S/R 秒。从那里我不明白慢启动是如何运作的。我认为它只会增加每个确认数据包的窗口大小。但是，例如在#1 的解决方案中，似乎只有两个数据包被发送和确认，而窗口大小却跳到 12S？我在这里想念什么？