第 十 章.拥塞控制

  • 拥塞控制的必要性
  • Internet的拥塞控制
  • 对多媒体的影响
  • 多媒体的拥塞控制

到目前为止，我们可以得出结论：以自然码率发送媒体流，如果试图超过自然码率，可能会导致数据包丢失。我们需要隐藏并纠正这些错误。然而，在现实世界中，媒体流很可能与其他流量共享网络。我们必须考虑发送码率对整体流量的影响，以及如何成为负责任的网络使用者。

拥塞控制的必要性

在讨论网络拥塞控制及其对媒体传输的影响之前，我们有必要了解下什么是拥塞控制，为什么需要拥塞控制以及忽视拥塞控制的影响。

正如我们在第2章《通过分组网络进行语音和视频通信》中所讨论的，IP网络提供了一种尽力而为的分组交换服务的功能。IP网络的一个基本特征是没有准入控制。网络层接收所有数据包，并尽最大努力将其交付。然而，网络层不能保证数据包的可靠送达，如果链路拥塞，多余的数据包将会丢失。上层协议关注丢包情况，并在拥塞发生时降低发送码率，这样就完成了拥塞控制过程。否则，可能会导致网络拥塞崩溃。

我们称网络负载的增加导致网络有效传输的数据包数量减少的情况叫做拥塞崩溃。图 10.1 ，当超过拥塞崩溃阈值时，到达率会突然下降。网络数据包在到达目的地之前就被丢弃(例如，由于中间节点的拥塞)而导致带宽浪费时，拥塞崩溃就发生了。

图 10.1. 拥塞崩溃

Figure10.1.CongestionCollapse.jpg

考虑这样一种情况: 数据源因为网络拥塞而丢弃了数据包,然后重新发送该数据包,但该数据包又被丢弃，周而复始。其他网络流量保持不变,网络的带宽完全被占用,却没有任何实际数据传输。这就是网络异常中的一种：拥塞崩溃。如果数据源能够检测到拥塞情况并相应降低发送码率,那么就可以缓解网络拥塞,避免上述情况出现。

拥塞崩溃不仅是一个理论模型。早期Internet中,TCP协议没有有效地控制拥塞,导致1980年代中期多次出现大规模的网络拥塞崩溃。为了防止此类事件的发生,Van Jacobson 开发了一种拥塞控制机制来优化TCP协议,详细内容我们将在下一部分“网络拥塞控制”中介绍。

随着非拥塞控制的多媒体流量的增加，人们再次开始关注拥塞崩溃的可能性。针对这个问题，人们提出了各种各样的机制。例如，路由器可以检测那些对拥塞事件没有响应的流，并对丢包率高于响应流的流进行惩罚。尽管这些机制目前尚未得到广泛应用，但未来可能会更积极地监督多媒体网络是否遵守拥塞控制的原则。

除了防止拥塞崩溃,拥塞控制还有另一个重要原因,就是实现公平的网络资源分配。不同流之间共享网络容量的策略不由IP层定义，而是由在其上运行的传输协议的拥塞控制算法定义。TCP采用基本平均分配带宽的模型。使用不同的拥塞控制算法会扰乱公平共享,结果通常降低TCP流的性能,因为它可能被更具侵占性的多媒体流挤占网络资源。

多媒体流量是否总应该比TCP流量得到优先受理,以及是否应始终分配更多网络带宽予多媒体流量,这仍待讨论。差异化服务和集成服务(RSVP)之类的机制,比如优先级队列(Priority Queue)等,允许根据应用需求,以可控制的方式为某些流赋予优先级。但是,目前这些服务优先机制在公共Internet还未全面部署。

Internet上的拥塞控制

互联网上的拥塞控制是通过运行在IP协议之上的传输协议层来实现的。简单来说，UDP并没有自带的拥塞控制功能，除非在UDP之上的应用程序层实现了相应的控制。相比之下，TCP则拥有一整套复杂的拥塞控制算法。

TCP是滑动窗口协议的一个典型案例。在发送数据包时，源端会为每个数据包附上序列号，并在接收方的ACK（肯定确认）数据包中回传这些序列号。最简单的滑动窗口协议要求每个数据包在发送后立即得到确认，然后才能发送下一个数据包，如图 10.2 所示。这就是所谓的“停止-等待”协议，因为发送端必须等待确认后才能发送下一个数据包。显然，“停止-等待”协议提供了流控制，防止发送数据量超出接收能力，但这也影响了传输性能，特别是当 RTT 比较大的时候。

图 10.2. 简单的停止等待协议

Figure10.2.ASimpleStopandWaitProtocol

通过使用较大的窗口，可以在接收到确认之前发送多个数据包。每个TCP的ACK数据包都包含一个接收窗口，它告诉源端当前可以接收多少字节的数据，以及来自数据包的最高连续序列号。 允许源在接收到 ACK 之前发送足够的数据包以填充接收窗口。 随着 ACK 的出现，接收窗口随之滑动，从而允许发送更多数据。 此过程如图 10.3 所示，其中的窗口允许三个未完成的数据包。 与简单的停止等待协议相比，更大的接收窗口提高了性能。

图 10.3. 使用滑动接收端窗口

除了接收窗口之外，TCP 发送端还实现拥塞窗口。 通过估算网络容量来确定拥塞窗口的大小，并防止发送端使网络超载（即拥塞控制）。 发送端可以随时发送足够的数据包，来填满拥塞窗口和接收窗口中较小的那个。

拥塞窗口从一个数据包的大小开始。只要不发生丢包，它就会根据慢启动（slow start）算法或拥塞避免（congestion avoidance）算法增加拥塞窗口的数据包。新建连接最初使用慢启动算法，然后过渡到拥塞避免算法。

在慢启动模式下，每收到一个ACK，拥塞窗口的大小就增加一个数据包的大小。因此，发送端逐渐增加发送速率，直到达到网络能够承载的最大速率，如图 10.4 所示。慢启动模式会一直持续，直到发生数据包丢失，或者超过了慢启动阈值。

图 10.4. TCP 慢启动

在拥塞避免模式中，拥塞窗口每往返时间增加一个数据包的大小（而不是每个 ACK 的大小）。 结果是拥塞窗口呈线性增长，从而增加了发送码率。

TCP 连接根据这两种算法之一提高其发送码率，直到发生丢包为止。 丢包表示网络已达到容量上限，并且发生了短暂的拥塞。 发送端可以通过两种方式判断拥塞：超时或接收三个重复 ACK。

如果在发送数据之后很长一段时间内未收到 ACK，则假定数据已丢失。这是一种超时情况：当接收窗口中的最后一个数据包丢失时，或者当出现阻止数据包到达其目的地的（临时）故障时，会发生这种情况。当超时发生时，发送端将慢启动阈值设置为正在传输的数据包数的一半或两个数据包，以较大者为准。然后，它将拥塞窗口设置为一个数据包的大小，并进入慢启动。当发送端进入拥塞避免模式时，慢启动过程继续，直到超过慢启动阈值。长时间超时将导致发送端放弃，从而断开连接。

发送端可以检测到拥塞的另一种方法是通过存在重复的 ACK 数据包，当数据包丢失或重新排序时就会发生（见图 10.5）。 ACK 数据包包含接收到的最高连续序列号，因此，如果数据包丢失，则后续的 ACK 数据包将包含丢失之前的序列号，直到重新传输丢失的数据包为止。 如果对数据包进行重新排序，也会生成重复的 ACK，但是在这种情况下，当重新排序的数据包最终到达时，ACK 序列将恢复正常。

** 图 10.5. 生成重复的 ACK 包 **

如果发送端收到三个重复的 ACK 数据包，那我们可以推测，这是由于拥塞而丢了一个数据包。发送端通过将拥塞窗口和慢启动阈值设置为，发出去的数据包个数的一半或 2（以较大者为准）来作出响应。然后，发送端重新传输丢失的数据包, 并进入拥塞避免模式。

算法的组合给出了 TCP 连接吞吐量，如图 10.6 中所示。特性是线性增加、乘性降低（AIMD，备注:当 TCP 发送端收到 ACK，并且没有检测到丢包事件时，拥塞窗口加 1；当 TCP 发送端检测到丢包事件后，拥塞窗口除以 2。）锯齿模式，在短时间间隔内吞吐量的变化较大。

图 10.6. TCP 发送码率的变化

实际上,TCP系统的稳定性关键在于快速调整吞吐量。乘数降低可以确保快速响应网络拥塞,防止拥塞崩溃事件发生。加性增加能够探测最大可能的吞吐量,从而更充分地利用网络资源。

已经有许多研究对TCP吞吐量的变化和竞争TCP流的行为进行了深入研究。这些研究表明，竞争流在平均情况下获得了大致相等的带宽份额，尽管由于吞吐量的波动，它们在瞬时的带宽分配上可能不公平。

TCP 中存在一种系统的不公平性：因为该算法响应反馈，所以往返时间较短的连接可以更快地返回反馈，效果更好。 因此，具有较长 RTT 的连接只能获得较低的平均份额。

对多媒体的影响

如第 2 章所述，通过分组网络进行语音和视频通信,大部分流量(超过95%)采用TCP作为传输协议。为了维持多媒体流与网络上其他流量的和平共处,多媒体流量也应采用与TCP协议一致公平的拥塞控制算法。

TCP能够在非常短时间内响应网络拥塞,会给RTT较小的链接分配略高的带宽。TCP发展过程中涉及多种拥塞控制变体,每个变体之间行为又有细微差异。这就给TCP定义公平性带来麻烦:公平性应用瞬时带宽还是长期平均带宽来衡量? 大RTT链接获得带宽低于小RTT链接是否成问题?如何看待影响某些特定条件下TCP行为的协议变更?

研究越深入，TCP 不完全公平这一点就越明显。在短期内，一个流总是会战胜另一个流。从长期来看，这种不平衡又是趋于平均的，但是有一种情况除外，就是具有较大RTT的连接通常有较低的平均吞吐量。TCP 的不同变体也有一定的影响，例如，SACK-TCP 在特定的丢包模式下会获得更好的吞吐量，从长期来看，相比其他TCP控制协议吞吐量最多可以相差 2 或 3 倍。

作为多媒体应用拥塞控制的设计者，TCP 多样性实际上使我们的工作变得更容易。我们不必担心对任何特定类型的 TCP 完全公平，因为 TCP 本身并不完全公平。我们必须实施某种形式的拥塞控制--以避免拥塞崩溃的危险--但只要这对 TCP 大约是公平的，这就是可以预期的最佳结果。

有些人认为，多媒体应用不需要对 TCP 公平，而且这种业务占用的带宽超过其份额是可以接受的。毕竟，多媒体流量有严格的时序要求，而不像更具弹性的 TCP 流。在某种程度上，这一论点是有价值的，但重要的是要理解这种不公平可能产生的问题。

例如,一个用户同时收听网络音频和浏览网页。在这种情况下,使音频流比TCP流更具侵略性是可以理解的,从而从网络下载中抢占带宽。结果就是,音乐不会出現跳帧,但网页响应速度会变慢。在许多情况下,这可能是期望的运行模式。类似地,用户通话期间发送邮件,更希望邮件传输速度降低,而不是音频通话中断。

但是，我们不能保证多媒体流量的优先级总是高于 TCP 通信。也许用户提交的网页是网上拍卖中的出价，或者是股票交易请求，这些操作的响应速度非常重要。在这种情况下，如果在线电台是TCP延迟变大，用户可能会不高兴。

如果你的应用需要比正常通信更高的优先级，则应将此要求通知网络，而不是由特定的传输协议暗示。这种通信允许网络根据可用容量和用户的偏好在允许或拒绝更高优先级之间做出智能选择。RSVP/Integrated Services 和 differential Services 等协议为此提供信令。在撰写本文时，对这些服务的支持非常有限；它们可以在一些专用网络上使用，但不能在公共Internet上使用。面向公共Internet的应用应考虑某种形式的 TCP 友好拥塞控制。

多媒体拥塞控制

在撰写本文时，还没有因特网上音频/视频流的拥塞控制标准。可以直接使用 TCP 拥塞控制标准，也可以模拟它，正如下一节“类 TCP 码率控制”中所讨论的，尽管模拟 TCP 在实践中存在各种问题。IETF 内部做一些定义一个 TCP 友好码率控制标准（参见标题为 TCP 友好码率控制的章节）的工作，该标准可能更适合单播多媒体应用。多播拥塞控制的最新技术还不太清楚，但是本章后面讨论的分层编码技术可能是最有希望的。

类 TCP 码率控制

音视频应用中最简单的拥塞控制技术是使用 TCP 或模拟 TCP 拥塞控制算法。

正如在第 2 章<分组网络上的语音和视频通信>中所讨论的那样，TCP 具有一些不适合实时应用的特性，尤其是强调可靠性而不是及时性。然而，一些多媒体应用也确实在使用 TCP，并且定义了一个 RTP over TCP 封装，以便与 RTSP（实时流协议）一起使用。

除了直接使用 TCP，还可以在没有可靠性机制的情况下模拟 TCP 的拥塞控制算法。 尽管尚无标准，但人们已经进行了多次尝试来实现这样的协议，其中最完整的是 Rejaie 等人的码率自适应协议（RAP）。 与 TCP 非常相似，RAP 源发送包含序列号的数据包，这些数据包被接收端确认。发送端可以使用来自接收端的确认反馈，检测丢包，来保持RTT在平均上是平滑的。

RAP 发送端使用加法递增乘法递减（AIMD）算法来调整其传输码率，其方式与 TCP 发送端几乎相同，尽管由于它是基于码率的，因此它显示出比 TCP 更平滑的变化。与 TCP 不同，RAP 中的拥塞控制与可靠性机制是分离的。当检测到丢包时，RAP 发送端必须降低其传输码率，但没有重新发送丢失的包的义务。实际上，最可能的响应是调整编解码器输出以匹配新的码率，并在不恢复丢包数据的情况下继续保存原有码率。

像 RAP 这样的协议，在某种程度上模拟 TCP 拥塞控制的行为，表现出了对现有流量最公平的行为。 与标准 TCP 相比，它们还为应用提供了更大的灵活性，从而使它能够以所需的任何顺序或格式发送数据，而不会因为 TCP 所提供的可靠的顺序传递而受阻。

使用 TCP 或类似 TCP 的协议的缺点是，应用必须快速调整其发送码率，以匹配 TCP 流量的调整码率。它还必须遵循 TCP 的 AIMD 模型，这意味着码率的突变。对于大多数音频/视频应用来说，这是个难题，因为很少有编解码器能够在如此大的范围内快速适应，而且人们发现图像或声音质量的快速变化会干扰观看者。

这些问题并不一定意味着 TCP 或类似 TCP 的行为不适合所有音频/视频应用，当我们只需要关注其适用性。这些拥塞控制算法的主要问题是隐含的码率快速变化。在某种程度上，你可以通过缓冲输出、隐藏码率的短期变化并将平滑的平均码率反馈给编解码器，使应用不受这些更改的影响。这对于非交互应用可以很好地工作，这些应用可以容忍缓冲所隐含的端到端延迟的增加，但不适合交互使用。

正在进行的协议研究将类似 TCP 的拥塞控制与不可靠的传输结合起来。如果发现其中一个适合与 RTP 一起使用，则可以扩展 RTP 以支持必要的反馈（例如，使用第 9 章“纠错”中描述的 RTCP 扩展）。设计合适的拥塞控制算法仍然是一个难点。

在撰写本文时，这些新协议都不完整。希望使用类似 TCP 的拥塞控制的应用可能最适合直接使用 TCP。

TCP 友好码率控制

TCP 或类 TCP 的拥塞控制不适合交互式音频/视频传输的主要问题是：在短时间内的剧烈码率变化。许多音频编解码器是非自适应的，并且以单一固定码率（例如，GSM，G.711）工作，或者只能在固定码率集（例如，AMR）之间进行自适应。视频编解码器通常具有更大的码率适应范围，因为帧速率和压缩比都可以调整，但它们适应的码率通常较低。即使媒体编解码器能够快速适应，也不清楚这样做是否一定合适：研究表明，用户更喜欢稳定的质量，即使可变质量流具有更高的平均质量。

设计了各种 TCP 友好的码率控制算法，试图平滑发送码率的短期变化，从而使算法更适合音频/视频应用。这些算法在几秒的平均间隔内实现 TCP 的公平性，但在短期内可能不公平。它们在单播音频/视频应用中具有相当大的潜力，IETF 正在定义一种标准机制。

TCP 友好的码率控制是基于对由 Padhye 等人导出的 TCP 稳态响应函数的仿真。响应函数是 TCP 连接吞吐量的数学模型，是给定网络丢包率和往返时间的平均吞吐量的预测。响应函数的推导有点复杂，但 Padhye 已经表明，在稳定条件下，TCP 连接的平均吞吐量 T 可以通过以下方式建模：

在这个公式中，s 是以八位元为单位的数据包大小，R 是发送端和接收端之间的往返时间(以秒为单位)，p 是丢包事件率(与丢失数据包的分数不完全相同；参见下面的讨论)，而 Trto是 TCP 重传超时时间(以秒为单位)。

这个方程看起来很复杂，但参数的测量相对简单。基于 RTP 的应用知道其发送的数据包的大小，可以从 RTCP SR 和 RR 包中的信息获得往返时间，并且在 RTCP RR 包中报告丢包事件率的近似。这只剩下 TCP 重传超时，Trto，令人满意的近似是往返时间的四倍，Trto＝ 4R。

在测量了这些参数之后，发送端可以计算在稳定状态下，即在假定丢包率恒定的情况下，TCP 连接在类似网络路径上将达到的平均吞吐量（在几秒钟内的平均）。然后，这些数据可以用作拥塞控制方案的一部分。如果应用以高于 TCP 计算出的码率发送，则应降低传输码率以匹配计算值，否则可能会造成网络拥塞。如果它以较低的码率发送，它可以增加其码率以匹配 TCP 将达到的码率。应用运行一个反馈回路：改变传输码率、测量丢包事件码率、改变传输码率匹配、测量丢包事件码率，重复。对于使用 RTP 的应用，这个反馈循环可以由 RTCP 接收报告包的到达来驱动。这些报告导致应用重新评估并可能更改其发送码率，这将在下一个接收报告中测量效果。

例如，如果报告的往返时间为 100 毫秒，则应用正在发送带有 20 毫秒数据包（s = 200，包括 RTP / UDP / IP 标头）的 PCM µ-law 音频，丢包事件率为 1％ （p = 0.01），TCP 等效吞吐量将为 T = 22,466 个八位位组每秒（21.9 Kbps）。

因为这低于 64kbit PCM 音频流的实际数据码率，所以发送端知道这引起了拥塞，因此必须降低其传输码率。 它可以通过切换到较低码率的编解码器（例如 GSM）来实现。 这似乎是一件简单的事情，但在实践中有一些问题需要解决。最关键的问题是如何测量平均丢包率，但在包大小、慢启动和非连续传输方面存在相对没那么关键的问题：

  • 最重要的问题是计算要反馈给发送端的丢包事件率的算法。RTP 应用不直接测量丢包事件率，而是计算每个 RTCP 报告间隔中丢包的数量，并将该数量包含在 RTCP 接收报告包中作为丢包部分。对于 TCP 友好的码率控制算法来说，这是否是正确的度量还不清楚。

    丢包率可能不是一个足够的度量，原因有二：首先，TCP 主要响应丢包事件，而不是实际丢失的数据包数量，大多数实现仅对一次往返时间内任何数量的丢包的响应定为将其拥塞窗口减半。将往返时间内连续丢失的多个数据包视为单个事件的丢包事件的度量，而不是将单个丢失的数据包计算在内，以与 TCP 更平等地竞争。丢包事件率可以通过 RTCP 接收端报告的扩展来报告，但目前还没有标准的解决方案。

    第二个原因是，在任何特定时间间隔内报告的丢包率不一定是潜在丢包率的反映，因为丢包率可能会因不具代表性的丢包突发而突然变化。这是一个问题，因为如果发送端使用丢包分数直接计算其发送码率，可能会导致振荡行为。在某种程度上，这种行为是不可避免的，AIMD 算法本身是振荡的，但振荡应该尽可能减少。

    用于减少振荡的解决方案是在特定时间段内的平均丢包报告，但是研究人员对正确的平均算法没有明确的共识。SiSalem 和 Schulzrinne 建议使用指数加权移动平均丢包分数，其优于原始丢包率，但在某些情况下仍可引起振荡。Handley 等人建议使用丢包事件率的加权平均值，修改以排除最近的丢包事件，除非这将增加平均丢包事件率。该修改的加权平均值防止了孤立的、无代表性的丢包破坏了丢包估计，并因此减少了振荡的机会。

    虽然它不是最优的，但使用 RTCP 接收报告中所报告的丢包分数的指数加权移动平均来近似丢包事件率可能是足够的。其目标不是对 TCP 连接完全公平，而是在某种程度上公平，不造成拥塞，并且仍然可以用于音频/视频应用。一个更完整的实现将扩展 RTCP 接收报告，以直接返回丢包事件率。

  • TCP 友好的码率控制算法假设包大小 s 是固定的，而传输码率 R 是可变的。固定的 s 和可变的 R 在某些编解码器中很容易实现，但在其他编解码器中很难实现。编解码器变化对公平性的影响是一个正在进行的研究课题，它会影响包的大小和码率。

    同样，应用可能正在使用具有有限适应范围的编解码器，并且可能无法以 TCP 友好算法指定的码率发送。安全的解决方案是以下一个可能较低的码率发送；如果不可能降低码率，则可能必须停止传输。

  • 如前所述，TCP 在开始传输时实现一个慢启动算法。这种缓慢的启动允许发送端以渐进的方式探测网络容量，而不是从可能导致拥塞的突发开始。慢启动对于 TCP 来说实现起来很简单，因为在发生丢包时会有立即的反馈，但是对于以较长时间间隔发送反馈的基于码率的协议来说则更为困难。

    适用于 TCP 友好码率控制的解决方案是，在慢启动期间，接收端每往返一次就对接收码率发送反馈。发送端以低码率启动（建议每秒一个包），每次反馈包到达时将其传输码率加倍，直到检测到第一个丢失。丢包发生后，系统开始正常运行，从丢包发生前使用的码率开始。这会逐渐增加到一个“合理”的值，此时码率控制算法将接管该值。

    该解决方案适合于与 RTP 一起使用，其中接收端根据扩展的 RTCP 反馈配置文件发送确认(参见第 9 章《错误恢复》以及 OTT 等人 2003)，并且发送端每往返时间将其码率加倍，直到发生丢包为止。然后，接收端回复到正常的 RTCP 操作，发送端遵循 TCP 友好的码率。

    一些应用可能无法执行此倍率算法，因为它们支持的编解码器集受到限制。此类应用可能会考虑先发送虚拟数据，然后在知道可持续传输码率后切换到最合适的编解码器。

  • 最后一个问题是不连续传输。如果源停止发送一段时间，则不会收到有关正确码率的反馈。在暂停期间，可用容量可能会发生变化，可能是因为启动了另一个源，所以当发送端恢复时，上次使用的传输码率可能不合适。对于这个问题，除了可能从零开始或从另一个慢启动算法降低的码率开始，直到确定正确的码率为止，几乎没有办法解决这个问题。

    如果能够解决这些问题，TCP 友好的码率控制就有可能成为单播音频/视频应用拥塞控制的标准方法。强烈建议所有单播 RTP 实现包括某种形式的 TCP 友好拥塞控制。

    实现至少应该观察 RTCP RR 包报告的丢包率，并将其发送码率与从该丢包率导出的 TCP 友好码率进行比较。如果实现发现其发送速度明显快于 TCP 友好码率，则应切换到较低码率的编解码器，或者在无法实现较低码率的情况下停止传输。这些措施可防止拥塞崩溃，并确保网络正常运行。

    实现 TCP 友好的码率控制算法将使应用优化其传输以匹配网络，给用户最好的质量。在此过程中，它还将公平对待其他流量，以免干扰用户正在运行的其他应用。如果应用有一个合适的编解码器或一组编解码器，强烈建议不仅使用码率控制来降低网络拥塞时的码率，而且要允许应用在网络负载较少时提高其质量。

分层编码

多播大大增加了拥塞控制的难度:发送端需要调整其传输以同时适应多个接收端，这个要求乍一看似乎是不可能的。多播的优点是，它允许发送端有效地向一组接收端传输相同的数据，而拥塞控制要求每个接收端获得适应其特定网络环境的媒体流。这两个要求似乎从根本上是互相矛盾的。

解决方案来自分层编码，在分层编码中，发送端将其传输分成多个多播组，而接收端只加入可用组的一个子集。拥塞控制的负担从无法满足每个接收端的冲突需求的源头转移到能够适应其具体情况的接收端身上。

分层编码需要一个媒体编解码器，能够将一个信号编码成多个层，这些层可以增量组合以提供逐渐提高的质量。一个只接收基本层的接收端将得到一个低保真度信号，一个接收基本层和一个附加层的接收端将得到更高的质量，每个附加层增加接收信号的保真度。除了基本层之外，层本身是不可用的：它们只是细化由较低层之和提供的信号。

分层编码的最简单用法是给每个接收端一个或多个层的静态订阅。例如，发送端可以生成如图 10.7 所示排列的层，其中基本层对应于 14.4-Kbps 调制解调器的容量，基本层和第一增强层的组合匹配于 28.8-Kbps 调制解调器的容量，基本层和前两个增强层的组合匹配于 33.6-Kbps 调制解调器，等等。每一层都是在一个单独的多播组上发送的，接收端加入适当的组集合，以便他们只接收感兴趣的层。网络中支持多播的路由器确保流量仅在指向感兴趣的接收端的链路上流动，从而将适应的负担放在接收端和网络上。

图 10.7. 分层编码

相关解决方案涉及使用 simulcast，其中发送端生成适合于不同码率的多个完整媒体流，接收端加入单个最适当的组。此解决方案在发送端使用了更多的带宽-可能的码率的和，而不是最高的可能码率，但实现更简单。它不能解决瞬时拥塞引起的问题，但对码率选择问题提供了良好的解决方案。

虽然层的静态分配通过调整媒体流以服务于多个接收端来解决码率选择问题，但它不响应由于交叉业务引起的瞬时拥塞。不过，很明显，允许接收端根据拥塞情况动态更改其层订阅可能为多播拥塞控制提供了一种解决方案。基本思想是让每个接收端运行一个简单的控制回路：

  • 如果出现拥挤，则丢弃一层或多层。

  • 如果有备用容量，则添加一层。

如果适当地选择了层，则接收端将搜索最优的层订阅，以与 TCP 源在慢启动阶段探测网络容量相同的方式更改其接收带宽。接收端连接层直到观察到拥塞，然后返回到较低的订阅级别。

要驱动自适应，接收端必须确定它们的订阅级别是太高还是太低。很容易检测到超额订阅，因为会发生拥塞，并且接收端会看到数据包丢失。订阅不足很难检测，因为没有信号表明网络可以支持更高的码率。相反，接收端必须尝试加入一个附加层，如果该层导致拥塞，则必须立即丢弃该层，这是一个称为连接实验的过程，结果如图 10.8 所示，订阅级别订阅级别根据网络拥塞而变化。

图 10.8. 通过改变订阅级别进行适配

加入实验的困难在于试图实现共享学习。 考虑图 10.9 所示的网络，其中接收端 R1 执行加入实验，但 R2 和 R3 不执行。 如果源和 R1 之间的瓶颈链接是链接 A，则一切将正常工作。 但是，如果瓶颈是链接 B，则 R1 执行的连接实验将导致 R2 和 R3 出现拥塞，因为它们共享瓶颈链接的容量。 如果 R2 和 R3 不知道 R1 正在执行连接实验，则将拥塞视为丢弃层的信号-这不是期望的结果！

图 10.9. 加入实验的难点

还有第二个问题。如果链路 C 是瓶颈，而 R2 丢弃一层，则除非 R3 也丢弃一层，否则通过瓶颈的流量不会受到影响。因为 R2 仍然看到拥塞，它将丢弃另一层，这个过程将重复，直到 R2 厌恶地离开会话，或者 R3 也丢弃一层。

解决这两个问题的方法是同步接收端连接实验。如果每个接收端通知所有其他接收端它将加入或丢弃一个层，则可以实现此同步，但这样的通知很难实现。一个更好的解决方案是，发送端在数据流中包含同步点（特别标记的数据包），告知接收端何时执行连接实验。

其他问题与多播路由的操作有关。尽管多播连接速度很快，但处理丢弃请求通常需要一些时间。接收端必须留出处理丢弃请求的时间，然后才能将拥塞的持续存在视为丢弃附加层的信号。此外，快速连接或丢弃会导致大量的路由控制通信量，这可能是有问题的。

如果这些问题能够得到解决，并且为每一层选择适当的带宽，就有可能通过分层编码来实现 TCP 友好的拥塞控制。将这种拥塞控制应用于音频/视频应用的困难在于找到一种能够生成具有适当带宽的累积层的编解码器。

分层编码是最有前途的多播拥塞控制方案，它允许每个接收端选择合适的码率，而不必给发送端增加负担。IETF 中的可靠多播传输工作组正在开发一个分层拥塞控制标准，这项工作很可能将成为未来多播音频/视频拥塞控制标准的基础。

总结

拥塞控制是必要的。作为一个应用设计人员，如果忽略拥塞控制，可能会导致你的应用看起来运行的更好，但却可能对网络上的其他流量产生负面影响，甚至影响你自己应用的其他实例。因此，为了避免拥塞崩溃的风险，应用程序应该实现某种形式的拥塞控制。同时，我们希望所选择的算法能够近似公平地处理TCP流量，并允许以控制的方式在网络中引入不公平的优先级。

拥塞控制的标准仍在发展中，因此很难为实现者提供详细的规范。尽管如此，强烈建议单播应用实现一个TCP友好的码率控制算法，这些算法算是最佳开发实践。对于多播应用，拥塞控制的选择不太明确，但目前分层编码似乎是最佳选择。