PROSAGA码农传奇-webrtc-使用 GCC 的 TWCC 基于延迟的估计

我一直在学习 Google 拥塞控制以及它如何从网络收集数据。我希望确认我对t(i) - t(i-1)延迟如何有用的理解。 我的理解是发件人用时间戳（所谓的，abs-send-time）标记每个数据包。此时间戳基于发送方的时钟。当数据包被传输到接收器时，接收器旨在计算它接收到的数据包之间延迟的“变化”。 据推测，这种延迟变化有助于推断路由器何时缓冲数据包，从而导致网络拥塞。然后，GCC 算法可以降低比特率以适应在数据包最终丢失到丢弃它们的缓冲区之前。 我的问题是，接收方如何准确测量数据包之间延迟的变化？我了解单向延迟是多么棘手，因为时钟不同步。因此，SR/RR 使用 RTT 来估计双向延迟。 因此，发送者在每个数据包上加上一个 标记abs-send-time，这些数据包以一定的间隔发送。该间隔应在abs-send-time时间戳中捕获。 例子：
<pre><code>packet_1 abs-send-time = 2022-01-01: 00: 00 : 00 : 000
delay of 10 ms (so called sender_delay_1)
packet_2 abs-send-time = 2022-01-01: 00: 00 : 00 : 010
delay of 10 ms (so called sender_delay_2)
packet_3 abs-send-time = 2022-01-01: 00: 00 : 00 : 020
</code></pre>作为接收方，我们可以推断发送间隔是每 10 毫秒。现在，如果接收间隔不是每 10 ms 一次，则接收方知道网络中的某些东西阻止了每 10 ms 接收数据包。 如果receiver_delay_1在接收端是 10 毫秒，并且receiver_delay_2是 20 毫秒，您知道尽管以 10 毫秒的间隔发送，receiver_delay_2表示第三个数据包比预期的接收间隔长 10 毫秒（基于它们被发送的间隔在（由 推断abs-send-time）。 总结一下： abs-send-time通知接收者发送速率是多少。然后接收器可以使用该信息来测量数据包的接收速率。当他们相等时，一切都很好。当接收速率和发送速率之间存在差异时，这可以推断出路径变得拥塞，因为路由器中的延迟会增加数据包接收速率之间的差异。 这是一个正确的理解吗？