webrtc中基于时延的拥塞控制TCC

传输协议

1. 扩展头
   在原audio, video screen等流stream的sequnce number的基层上， 增加传输层的sequence number, 即所有的流都会有统一的transportSeq.

uint16_t transportSeq;

2. 反馈报文

• 反馈报文定义

struct ControlPacket_TransportFeedback {
    uint16_t baseSeq;
    uint16_t packetStatusCount;
    uint24_t baseTime;
    uint8_t feedbackCount;
    uint16_t packetStatus[n];
    uint16_t recvDeltas[n];
};

字段名	含义	长度（bit）	值
baseSeq	这次反馈的头一个包的transportSeq	16	0 - 65535
packetStatusCount	总共反馈多少个包的状态	16	0 - 65535
baseTime	收端的时间，可用baseSeq收到的时间	24	绝对时间的后24位，单位ms, 做64ms的倍数
feedbackCount	feedback序号，便于知道丢失transportfeedback	8	0 - 255
packetStatus[n]	每个包的状态，具体每一位含义见下表		16 * n
recvDeltas[n	]收到包的时间差值，具体每一位含义见下表		16 * n

• packetStatus定义
  共两种， 其一：

struct PacketStatus_Repeat {
    uint8_t type : 1;
    uint8_t status : 2;
    uint13_t count ;
};

字段名	含义	长度（bit）	值
type	两种packetStatus中哪一种	1	0
status	包的状态	2	0x00 -- 未收到 ; 0x01 -- 收到,且recv delta较小; 0x02 --收到，且recv delta 较大; 0x03保留
count	有多个连续的包处于这种状态	13	1 - 8095

其二：

struct PacketStatus_Continue {
    uint8_t type : 1;
    uint8_t symbol : 1;
    uint14_t symbolVector;
};

字段名	含义	长度（bit）	值
type	两种packetStatus中哪一种	1	1
symbol	包的状态的分类	1	0 -- 只有“收到”， “未收到”两种状态； 1 -- 有以上三种状态
symbolVector	如果symbol = 0, 则可包含14个包的状态； 如果symbol = 1, 则包含7个包的状态。	14

• recvDeltas定义
  Recv delta 较小 ： [-128, 127] ms
  Recv delta 较大 ： [-2048, 2047] ms， 并去掉较小部分
  注：这个定义同参考draft不同。

struct RecvDeltas_Small {
    uint8_t delta1;
    uint8_t delta2;
};

字段名	含义	长度（bit）	值
delta1	接收到的包的时间差	8	如果recvDeltas的第一个包，则是recvtime - baseTime (ms),否则是，recvtime - lastRecvTime, 即跟前一个包的时间差；
delta2	接收到的包的时间差	8	如果recvDeltas的第一个包，则是recvtime - baseTime (ms);否则是，recvtime - lastRecvTime, 即跟前一个包的时间差；

struct RecvDeltas_Large {
    uint8_t delta;
};

字段名	含义	长度（bit）	值
delta	接收到的包的时间差	16	如果recvDeltas的第一个包，则是recvtime - baseTime (ms);否则是，recvtime - lastRecvTime, 即跟前一个包的时间差；

• 反馈报文频率
  draft建议： 一个rtt或是30 - 50ms。

实践： 先定为400ms, 基于多次实验测试数据调节。

基于传输反馈的拥塞控制

1. TCC算法

• trendline计算：

根据反馈的recv delta计算delay(同rtcp jitter):

然将delay做累加和平滑：

smoothingCoef是个经验值， 在webrtc trendline_estimator.cc中取0.9。

另外还有一个recvTime = recvTime(i) - firstRecvTime;
接着将recvTime, accumulatedDelay和smoothedDelay保存到一个固定窗口大小的队列HistoryQueue中，

然后按以下公式计算线性斜率：

得到的slope即是我们需要的带宽变化趋势。

为了限制slope不让它跑偏了，
在HistoryQueue中取前80%的包中最小的accumlatedDelay(k), 以及这个包对应的recvTime(k),
在HistoryQueue中取后80%的包中最大的accumlatedDelay(m), 以及这个包对应的recvTime(k)

slope不能大于slope(max)。

基于slope判断出网络带宽的使用状态： overuse, underuse, normal。

最后，基于新的网络带宽状态， 通过AIMD调整带宽。

• trendline计算带来的优势：
  • 算法简洁,易于实现和改进
  • 平滑jitter

参考

1. https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
2. Webrtc source code