RTP 控制协议 (RTCP) 反馈用于拥塞控制

摘要

有效的 RTP 拥塞控制算法，需要比标准 RTP 控制协议(RTCP)发送方报告(SR)和接收方报告(RR)数据包提供的关于数据包丢失、定时和显式拥塞通知 (ECN) 标记的更细粒度的反馈。

本文档描述了 RTCP 反馈消息，旨在使用 RTP 对交互式实时流量启用拥塞控制。反馈消息设计用于基于发送方的拥塞控制算法，其中 RTP 流的接收方向发送方发送回 RTCP 反馈数据包，其中包含发送方执行拥塞控制所需的信息。

1.简介

对于交互式实时流量，例如视频会议流，典型的协议选择是在用户数据报协议 (UDP) 上运行的实时传输协议 (RTP) [RFC3550]。 RTP 不提供任何服务质量 (QoS)、可靠性或及时交付的保证，并期望底层传输协议能够这样做。仅 UDP 肯定无法满足这一期望。然而，RTP 控制协议 (RTCP) [RFC3550] 提供了一种机制，RTP 流的接收方可以通过该机制定期向该 RTP 流的发送方发送传输和媒体质量度量。发送方可以使用该信息来执行拥塞控制。

由于缺乏用于此目的的标准化消息，拥塞控制算法的设计者开发了专有的 RTCP 消息，这些消息仅传送各自设计所需的参数。直接的结果是，不同的拥塞控制设计不能互操作。为了实现算法演进以及跨设计的互操作性（例如，不同的速率自适应算法），非常需要具有通用的拥塞控制反馈格式。

为了帮助实现单播 RTP 拥塞控制的互操作性，本备忘录指定了一种通用的 RTCP 反馈数据包格式，可供网络辅助动态自适应 (NADA) [RFC8698]、多媒体自时钟速率自适应 (SCReAM) [RFC8298]、谷歌拥塞控制 [Google-GCC] 和共享瓶颈检测 [RFC8382]，并且，希望未来的 RTP 拥塞控制算法也能做到这一点。

2. 术语

关键词“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们以全部大写形式出现时，本文档中的“应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。

此外，[RFC3550]、[RFC4585] 和 [RFC5506] 中定义的术语也适用。

3. 用于拥塞控制的 RTCP 反馈

基于对 NADA [RFC8698]、SCReAM [RFC8298]、Google 拥塞控制 [Google-GCC] 和共享瓶颈检测 [RFC8382] 的分析，已确定以下每 RTP 数据包拥塞控制反馈信息是必要的：

RTP 序列号：RTP 流的接收方需要将收到的 RTP 数据包的序列号反馈给发送方，以便发送方可以确定哪些数据包已收到、哪些数据包丢失。许多拥塞控制算法将数据包丢失用作拥塞的指示。

数据包到达时间：RTP 流的接收方需要将每个 RTP 数据包的到达时间反馈给发送方。某些拥塞控制算法将数据包延迟和/或延迟变化（抖动）用作拥塞信号。

数据包显式拥塞通知（ECN）标记：如果使用ECN[RFC3168][RFC6679]，则需要在接收到的RTP数据包中反馈2位ECN标记，指示对于每个RTP数据包是否被标记为not-ECT， ECT(0)、ECT(1) 或 ECN 拥塞经历 (ECN-CE)。（“ECT”代表“支持ECN的传输”。）如果RTP流量使用的路径支持ECN，则发送方可以使用ECN-CE标记信息作为拥塞控制信号。

每个 RTP 流均由其同步源 (SSRC) 标识符。因此，RTCP 反馈格式需要按 SSRC 对其报告进行分组，为每个收到的 SSRC 发送一个报告块。

实际上，我们注意到主机操作系统 (OS) 进程中断可能会在不适当的时间发生。因此，需要记录发送方的 RTP 数据包发送时间以及接收方相应的 RTP 数据包到达时间刻意的照顾。这是因为主机操作系统的持续时间相对于单向延迟估计中所需的精度，中断可能很重要。具体地，需要在发送方发送RTP分组之前的最后机会记录发送时间，并且需要在最早的可用机会记录到达接收方的时间。

3.1. RTCP拥塞控制反馈报告

拥塞控制反馈可以作为定期调度的 RTCP 报告的一部分或在 RTP/AVPF 早期反馈数据包中发送。如果作为早期反馈发送，并且使用 RTP/AVPF 配置文件 [RFC4585] 或 RTP/SAVPF 配置文件 [RFC5124]，则拥塞控制反馈可以在非复合 RTCP 数据包 [RFC5506] 中发送。

无论如何传输，拥塞控制反馈都会作为传输层反馈消息（RTCP 数据包类型 205）发送。该RTCP数据包的格式如图1所示：

图 1：RTCP 拥塞控制反馈数据包格式

前 8 个八位位组包括标准 RTCP 标头，其中 PT=205 和 FMT=11 指示这是拥塞控制反馈数据包，并且 SSRC 设置为 RTCP 数据包发送方的 SSRC。

[RFC4585] 的第 6.1 节要求 RTCP 标头后跟正在报告的 RTP 流的 SSRC。因此，RTCP 标头后面跟着一个用于已从其接收到 RTP 数据包的每个 SSRC 的报告块，后面跟着一个报告时间戳。

每个报告块都以它正在报告的接收到的 RTP 流的 SSRC 开始。接下来，报告块包含每个 RTP 数据包的 16 位数据包度量块，该数据包的序列号在 begin_seq 到 begin_seq+num_reports 范围内（含）（使用算术模 65536 计算，以考虑可能的序列号环绕）。如果报告块中包含的 16 位数据包度量块的数量不是 2 的倍数，则必须在最后一个数据包度量块之后添加 16 位零填充，以使数据包度量块的末尾与下一个数据包度量块对齐。 32 位边界。 num_reports 的值可以为 0，表示该 SSRC 不包含任何数据包度量块。每个报告块不得包含超过 16384 个数据包度量块（即，它不得在单个报告中报告超过四分之一的序列号空间）。

每个16位数据包度量块的内容包括R、ECN和ATO字段，如下所示：

已接收（R，1 位）：一个布尔值，指示数据包是否已接收已收到。 0 表示尚未接收到数据包，并且该 16 位数据包度量块中的后续 15 位（ECN 和 ATO）也设置为 0 并且必须被忽略。 1 表示已收到数据包，需要解析块中的后续位。

ECN（2 位）：数据包的回显 ECN 标记。如果未收到或未使用 ECN，这些位将设置为 00。

到达时间偏移（ATO，13 位）：RTP 数据包到达接收器的时间，作为该 RTCP 拥塞控制反馈报告的报告时间戳 (RTS) 字段所表示的时间之前的偏移。 ATO 字段以 1/1024 秒为单位（选择该单位是为了给出与 RTS 字段的精确偏移），因此，例如，ATO 值 512 表示相应的 RTP 数据包在 RTS 字段表示的时刻之前恰好半秒到达。如果测量值大于 8189/1024 秒（该值将编码为 0x1FFD），则必须报告值 0x1FFE 以指示超出范围的测量。如果测量不可用或者 RTP 数据包的到达时间晚于 RTS 字段表示的时间，则必须为数据包报告 ATO 值 0x1FFF。

RTCP 拥塞控制反馈报告数据包以报告时间戳字段（RTS，32 位）结束。这表示该数据包报告的时刻，也是计算到达时间偏移值的时刻。 RTS 字段的值源自用于生成 RTCP 发送方报告 (SR) 数据包中的 NTP 时间戳字段的同一时钟。它被格式化为 NTP 格式时间戳的中间 32 位，如 [RFC3550] 第 4 节中所述。

RTCP 拥塞控制反馈数据包应包含每个活动 SSRC 的报告块。给定 SSRC 的连续报告中报告的序列号范围通常是连续的，但可以发送重叠的报告（并且需要在以下情况下发送）

其中 RTP 数据包重新排序发生在连续报告之间的边界上）。如果一个 RTP 数据包在一份报告中被报告为已接收，则该数据包也必须在随后发送的涵盖其序列号范围的任何重叠报告中报告为已接收。

如果发送覆盖重叠序列号范围的反馈报告，则后面的反馈报告中的信息可以针对包括在两个反馈报告中的RTP分组更新在之前的报告中发送的任何数据。

如果相对于 RTP 数据包的数量而言，RTCP 拥塞控制反馈数据包的发送频率较低，则它们可能会很大。如果 RTCP 拥塞控制反馈数据包太大而无法容纳在路径 MTU 内，则其发送方应将其拆分为多个反馈数据包。 RTCP 报告间隔的选择应使得反馈数据包发送得足够频繁，以至于它们足够小以适合路径 MTU。（[RTCP-Multimedia-Feedback]讨论了如何选择报告间隔；RTP拥塞控制算法规范也可以提供指导。）

如果接收到特定 RTP 数据包的重复副本，则必须报告第一个到达副本的到达时间。如果复制数据包的任何副本都带有 ECN-CE 标记，则必须报告该数据包的 ECN-CE 标记；否则，报告第一个到达的副本的 ECN 标记。

如果在报告间隔内没有从 SSRC 接收到数据包，则可以发送报告块，其中 begin_seq 设置为先前从该 SSRC 接收到的最高序列号，并且 num_reports 设置为 0（或者可以简单地省略报告）。对应的发件人报告/接收器报告 (SR/RR) 数据包将具有非增加的扩展最高序列号接收字段，该字段将通知发送方尚未收到数据包，但可以简化处理以在拥塞控制反馈报告中也提供该信息。

指示某些 RTP 数据包丢失的报告块不应被解释为重传丢失数据包的请求。如果已协商重传有效负载格式，则此类报告的接收方可能会选择重传此类数据包，但不要求这样做。

4. 反馈频率和开销

在报告的速度和准确性以及报告的开销之间需要权衡。 [RTCP-多媒体反馈]讨论了这种权衡，提出了理想的 RTCP 反馈率，并提供了有关如何配置（例如，RTCP 带宽分数）以适当使用本备忘录中描述的报告块的指导。 RTP 拥塞控制算法规范也可以提供指导。

人们普遍认为，反馈越频繁，拥塞控制算法效果越好。然而，RTCP带宽和传输规则对RTCP反馈消息可以从RTP接收器发送到RTP发送器的频率设置了一些上限。

在许多情况下，在报告开销变得过多之前，每帧发送一次反馈是上限，尽管这取决于媒体速率，并且高速率媒体流可能需要更频繁的反馈[RTCP-多媒体反馈]。分析[反馈要求]还表明，一些候选拥塞控制算法可以使用 50-200 ms 的反馈间隔范围，以不太频繁的反馈进行操作。应用程序需要根据拥塞控制算法的选择、预期的媒体比特率和可接受的反馈开销，在会话建立时协商适当的拥塞控制反馈间隔。

5. 反馈包丢失的响应

与所有 RTCP 数据包一样，RTCP 拥塞控制反馈数据包可能会丢失。所有 RTP 拥塞控制算法必须指定它们如何响应反馈数据包的丢失。

RTCP 数据包不包含序列号，因此必须根据自上次反馈数据包以来的时间来推断反馈数据包的丢失。如果仅丢失一个拥塞控制反馈数据包，则适当的响应是假设拥塞水平与先前的报告大致保持相同。然而，如果多个连续的拥塞控制反馈数据包丢失，则媒体发送方应该快速降低其发送速率，因为这可能表明路径故障。 RTP断路器规范[RFC8083] 提供进一步的指导。

6.SDP信令

定义了一个新的“ack”反馈参数“ccfb”，与“a=rtcp-fb：”会话描述协议（SDP）扩展一起使用，以指示使用第 3 节中定义的 RTP 拥塞控制反馈数据包格式。该SDP参数扩展的ABNF定义[RFC5234]是：

rtcp-fb-ack-param = <参见 [RFC4585] 的第 4.2 节>

rtcp-fb-ack-param =/ccfb-parccfb-par = SP“ccfb”与“ccfb”反馈一起使用的有效负载类型必须是通配符类型（“*”）。这意味着拥塞控制反馈是针对会话中使用的所有有效负载类型发送的，包括任何前向纠错（FEC）和重传有效负载类型。生成的 SDP 属性的示例如下：

a=rtcp-fb:* ack ccfb

这些SDP反馈参数的提供/应答规则是 RTP/AVPF 配置文件 [RFC4585] 的第 4.2 节中指定。

SDP 提议可能表明支持本备忘录中指定的拥塞控制反馈机制以及提供基本相同语义的一个或多个替代拥塞控制反馈机制。在这种情况下，应答方应该包括其答案中仅提供一种拥塞控制反馈机制。如果收到包含同一组拥塞控制反馈机制的后续提议，则生成的答案应尽可能选择与原始答案中相同的拥塞控制反馈机制。

当SDP BUNDLE扩展[RFC8843]用于复用时，“a=rtcp-fb:”属性具有多路复用类别IDENTICAL-PER-PT[RFC8859]。

7. 与 RFC 6679 的关系

[RFC6679]中描述了显式拥塞通知（ECN）与 RTP 的使用，它指定了如何与 RTP 协商 ECN 的使用，并定义了 RTCP ECN 反馈数据包来携带 ECN 反馈报告。它使用 SDP“a=ecn-capable-rtp:”属性来协商 ECN 的使用，并使用“a=rtcp-fb:”属性和“nack”参数“ecn”来协商 RTCP ECN 的使用数据包。

当 ECN 与本备忘录中定义的 RTP 拥塞控制反馈数据包一起使用时，RTCP ECN 反馈数据包没有用处，因为它提供了重复的信息。当拥塞控制反馈与 RTP 和 ECN 一起使用时，生成的 SDP 提议必须包含用于协商 ECN 支持的“a=ecn-capable-rtp:”属性，以及与“ack”参数“ccfb”表示可以使用RTP拥塞控制反馈包。 “a=rtcp-fb:”属性还可以包括“nack”参数“ecn”以指示还支持 RTCP ECN 反馈数据包。如果SDP 为 RTP 拥塞控制反馈数据包和 RTCP ECN 反馈数据包提供信号支持，应答方应该在其 SDP 应答中信号支持一种格式，但不能同时支持两种格式，以避免发送重复的反馈。

当将 ECN 与 RTP 结合使用时，请遵循 [RFC6679] 第 7.2 节中的指南

必须遵循在 RTP 会话中启动 ECN 的使用。还必须遵循 [RFC6679] 第 7.3 节中关于在 RTP 会话中持续使用 ECN 的指南，但反馈是使用本备忘录中描述的 RTCP 拥塞控制反馈数据包而不是使用 RTP ECN 反馈数据包发送的。同样，[RFC6679]第 7.4 节中的指导相关必须遵循检测故障的方法，但必要的信息是从 RTCP 拥塞控制反馈数据包而不是从 RTP ECN 反馈数据包中检索的。

8. 设计原理

RTCP SR/RR 数据包的主要功能是报告 RTP 数据包接收的统计数据。这些数据包中发送的接收报告块包含有关观察到的抖动、部分数据包丢失和累积数据包丢失的信息。该信息的目的是可用于支持拥塞控制算法，但经验表明它不足以实现该目的。

高效的拥塞控制算法需要比 SR/RR 数据包提供的有关每个数据包接收质量的更细粒度的信息才能有效做出反应。本备忘录中定义的反馈格式提供了如此细粒度的反馈。

其他几个 RTCP 扩展也提供比 SR/RR 数据包更详细的反馈：

TMMBR：RTP/AVPF 配置文件 [RFC5104] 的编解码器控制消息包括临时最大媒体流比特率请求 (TMMBR) 消息。这用于从 RTP 数据包接收方向发送方传达临时最大比特率限制。尽管 TMMBR 并非旨在取代拥塞控制，但它已被用作进行基于接收器的拥塞控制的一种方法，其中会话带宽足够高，可以发送频繁的 TMMBR 消息，特别是与非复合 RTCP 数据包一起使用时 [RFC5506] 。这种方法要求 RTP 数据包的接收方监视其接收情况，确定拥塞程度，并推荐适合路径上当前可用带宽的最大比特率；它还假设 RTP 发送方可以/将会尊重该比特率。这与本备忘录中建议的基于发送者的拥塞控制方法相反，因此 TMMBR 不能用于传达基于发送者的拥塞控制所需的信息。然而，TMMBR 可以被视为一种补充机制，可以告知发送方接收方当前对可接受的最大比特率的看法。

传达接收器对最大可用比特率的估计的机制提供了类似的反馈。

RTCP 扩展报告 (XR)：定义了许多 RTCP XR 块来报告数据包丢失、到达时间 [RFC3611]、延迟 [RFC6843] 和 ECN 标记 [RFC6679] 的详细信息。可以将多个此类 XR 块组合成一个复合 RTCP 数据包，以报告有效的基于发送方的拥塞控制所需的详细丢失、到达时间和 ECN 标记信息。

然而，由于需要堆叠多个报告，结果在带宽和复杂性方面都有很高的开销。

传输范围的拥塞控制：本备忘录中定义的格式提供了每个 SSRC 的单独反馈。另一种方法是向每个 RTP 数据包添加标头扩展，其中包含单个传输范围的数据包序列号，然后让接收方发送 RTCP 报告，提供有关这些附加序列号的反馈 [RTP-Ext-for-CC]。由于报头扩展，这种方法将每个 RTP 数据包的大小增加了 8 个八位位组，但减少了 RTCP 反馈数据包的大小，并且如果它保持适用于所有数据包的单一速率限制，则可以简化发送方的速率计算。发送的 RTP 数据包，无论其类型如何 SSRC。同样，使用整个运输范围的反馈使其更加很难根据在每个 SSRC 上观察到的接收和/或丢失模式来调整发送速率或响应丢失的数据包（例如，执行差分速率控制和基于每个流丢失的数据包的知识来修复音频和视频流）。运输范围的反馈也不太适合更广泛的 RTP 框架，这使得广泛使用每个 SSRC 序列号和反馈。

考虑到这些问题，我们认为设计一种新的 RTCP 反馈机制来为基于发送者的拥塞控制算法传递信息是适当的。新的拥塞控制反馈第 3 节中描述的 RTCP 数据包提供了这样的机制。

9. IANA 考虑因素

IANA 在“RTPFB 有效负载类型的 FMT 值”表 [RFC4585] 中注册了一条新的 RTP/AVPF 传输层反馈消息，如第 3.1 节中所定义：

名称：CCFB

全名：RTP拥塞控制反馈

值：11

参考：RFC 8888

IANA 还注册了一项新的 SDP“rtcp-fb”属性“ack” SDP“ack”和“nack”属性值中的参数“ccfb”

注册表：

值名称：ccfb

长名称：拥塞控制反馈

可用于：ack

多路复用器：每个 PT 相同

参考：RFC 8888

10. 安全考虑

RTP 规范 [RFC3550]、适用的 RTP 配置文件（例如，[RFC3551]、[RFC3711] 或 [RFC4585]）的安全考虑，以及正在使用的 RTP 拥塞控制算法（例如，[RFC8698]， [RFC8298]、[Google-GCC] 或 [RFC8382]）适用。

故意生成不准确的 RTCP 拥塞控制反馈报告的接收方可能会欺骗发送方以高于路径可支持的速率进行发送，从而导致路径拥塞。这种情况将对该接收器的体验质量，可能会导致共享路径的其他流量拒绝服务以及媒体发送器的资源使用量过度增加。由于 RTP 是一种不可靠的传输，发送方可以故意丢弃数据包，在 RTP 序列号空间中留下间隙，而不会造成严重损害，以检查接收方是否正确报告丢失。（这需要小心完成，并对所发送的媒体数据有一定的了解，以限制对用户体验的影响。）

可以修改 RTCP 拥塞控制反馈数据包的路径攻击者可以更改报告以欺骗发送方以过高或过低的速率发送，从而导致拒绝服务。安全 RTCP 配置文件 [RFC3711] 可用于验证 RTCP 数据包以防止此类攻击。

可以欺骗 RTCP 拥塞控制反馈数据包的偏离路径攻击者同样可以欺骗发送方以不正确的速率发送，从而导致拒绝服务。这种攻击很困难，因为攻击者还需要猜测 SSRC 和序列号到目的地传输地址。与路径攻击一样，安全 RTCP 配置文件 [RFC3711] 可用于验证 RTCP数据包以防止此类攻击。