search

yuanrongxi / razor

A google's congestion Control Algorithm
MIT License
352 stars 152 forks source link

请教下袁老师gcc/bbr算法在可靠网络上的应用问题 #25

Open lcodecorex opened 4 years ago

lcodecorex commented 4 years ago

袁老师， 您好！我们做了一个基于VNC的远程桌面软件，由于RFB协议的限制，只能在可靠网络上工作（TCP/RUDP）。VNC中没有流控的概念，所以想引入gcc/bbr算法进行拥塞控制。 我们有以下几点要求，对低延时的追求胜过对带宽利用率的追求：

先简单介绍下基于VNC的远程桌面，它工作在可靠网络中，会通过算法找到当前帧相对于上一帧的变化区域，然后对这个区域进行Tight编码（融合了调色板、JPEG编码），然后发送。

所以当桌面没有变化时，数据量基本为0；当桌面有变化时，数据量和变化区域大小有关，可能忽大忽小，不可控。我们希望，桌面的最后的变化能快速发送到接收端，一些中间变化在带宽有限时可以忽略。

在可靠网络上，拿不到丢包相关信息，所以我准备尝试Vegas，BBR，以及GCC的基于延迟的拥塞控制的算法部分。

我有以下几点疑惑： 1、bbr算法得到一个带宽的时候，如果现在的数据量不够的话，它必须要发送一些padding数据。在我们的场景下，数据量会忽大忽小。带宽大的时候，感觉会需要发送很多padding数据，会很浪费带宽。 2、我们的数据量的变化和数据发送时间是比较随机的，且数据格式受RFB协议限制，拥塞控制只能通过扩展协议来做。这种情况下，pacing机制还能用吗？GCC的到达时间滤波器和延迟梯度模型还能生效吗？ 3、GCC算法需要接受端反馈数据包的到达时间，但两个端上的时间一般都是对不齐的。这样的话，用到达时间和RTT在一起计算不太合适。razor没有考虑到这个问题吗？还是算法能屏蔽两个端上时间不同步的问题？

由于缺少拥塞控制方面的经验，不能确定我们的场景适合使用哪个算法，希望袁老师能给一点建议，非常感谢！

yuanrongxi commented 4 years ago

BBR如果你不需要探测最大带宽上线的话，可以不用padding, 可以只是一个最大阈值。GCC是用包到达时间相对值来做判定了，不是单纯的绝对时间,不存在时间戳对齐的问题。

lcodecorex commented 4 years ago

好的，谢谢袁老师！这样看来可能bbr更适合我们的使用场景？ 还有一个问题是关于pacing的。我们目前是在可靠网络上工作（TCP），即使我们在应用层做了数据的平滑发送，到了传输层可能还是会变成突发数据。这个问题应该怎么解决？

yuanrongxi commented 4 years ago

数据突发是和你产生的数据频率和量有关关系对吧？如果你要求平滑，可能会带来一些延迟。其实TCP本身是有拥塞控制的，突发只要在拥塞控制的条件限制下传输问题不大。

Jadaeu commented 4 months ago

袁老师， 您好！我们做了一个基于VNC的远程桌面软件，由于RFB协议的限制，只能在可靠网络上工作（TCP/RUDP）。VNC中没有流控的概念，所以想引入gcc/bbr算法进行拥塞控制。 我们有以下几点要求，对低延时的追求胜过对带宽利用率的追求：

  • 1、实时性强（低延时）
  • 2、较小的带宽占用
  • 3、弱网对抗能力强
  • 4、快速感知拥塞

先简单介绍下基于VNC的远程桌面，它工作在可靠网络中，会通过算法找到当前帧相对于上一帧的变化区域，然后对这个区域进行Tight编码（融合了调色板、JPEG编码），然后发送。

所以当桌面没有变化时，数据量基本为0；当桌面有变化时，数据量和变化区域大小有关，可能忽大忽小，不可控。我们希望，桌面的最后的变化能快速发送到接收端，一些中间变化在带宽有限时可以忽略。

在可靠网络上，拿不到丢包相关信息，所以我准备尝试Vegas，BBR，以及GCC的基于延迟的拥塞控制的算法部分。

我有以下几点疑惑： 1、bbr算法得到一个带宽的时候，如果现在的数据量不够的话，它必须要发送一些padding数据。在我们的场景下，数据量会忽大忽小。带宽大的时候，感觉会需要发送很多padding数据，会很浪费带宽。 2、我们的数据量的变化和数据发送时间是比较随机的，且数据格式受RFB协议限制，拥塞控制只能通过扩展协议来做。这种情况下，pacing机制还能用吗？GCC的到达时间滤波器和延迟梯度模型还能生效吗？ 3、GCC算法需要接受端反馈数据包的到达时间，但两个端上的时间一般都是对不齐的。这样的话，用到达时间和RTT在一起计算不太合适。razor没有考虑到这个问题吗？还是算法能屏蔽两个端上时间不同步的问题？

由于缺少拥塞控制方面的经验，不能确定我们的场景适合使用哪个算法，希望袁老师能给一点建议，非常感谢！

楼主您好，我目前也在做一个面向远程桌面视频流场景下的带宽预测的项目，内容和您上面描述的非常相似，所以我想问问一下您们最后采用的是bbr来进行拥塞控制吗？我目前想的是基于bbr带宽探测部分进行改进，由于缺少相关知识，过程中遇到很多困难，如果可以的话，可以分享一下您的经验吗？非常感谢！