摘要

  • RFC 3738 将 WEBRC 的拥塞测量和速率决策放在各个接收端；接收端通过加入或离开组播信道调整接收，而不是向发送端发送逐个接收者的报告。
  • 发送端在多个信道上安排波形，使这些加入和离开动作对应不同接收速率；代价是接收端更复杂，而且该机制不提供可靠性或交付证明。

发送端保持安静，并不代表整个系统没有动作

组播有一种看似优雅的算术：发送端可以把同一会话发给一个组，而不必为每位接收者各开一条数据流。但拥塞并不会平均分布。位于狭窄或繁忙链路后的接收端可能遭遇丢包，而同一会话里的另一个接收端仍有余量。如果发送端必须先收集、处理每位接收者的报告才能调整发送，反馈本身就可能成为扩展性问题。

2004 年 4 月以 Experimental RFC 发布的 RFC 3738，探索了另一种分工。Wave and Equation Based Rate Control（WEBRC）是供组播协议采用的拥塞控制构件。它不要求接收端把拥塞报告发送给发送端。每个接收端测量自身路径状况，计算目标接收速率，再改变自己订阅的组播信道。因此，“没有向发送端反馈”不等于“没有信号”。信号是一个普通的网络动作：加入或离开信道。

这一区别细微，却改变了控制架构。发送端收不到每位接收者关于丢包、可用带宽或传输完成情况的状态报告；接收端也不必等待发送端为其协商个性化数据流。发送端发出一组共同信道，每个接收端则按自己的拥塞估计选择其中一部分。

把速率控制表达为信道成员关系

WEBRC 将一个会话分为低速基础信道和多个波形信道。基础信道帮助接收端确定自己在时间槽周期中的位置，并在参与期间持续接收。波形信道的速率随时间变化：每个波形先以较高速率启动，随后经过若干时间槽逐渐降速，进入静默期，再重复周期。

这种时间形状让接收端可以自行选择速率，而不用请求发送端为它另建数据流。要提高目标速率，接收端会在波形速率下降过程中更早加入另一层活动信道；要降低速率，它就不再加入新的层，并在波形进入静默期时离开相应信道。活动波形会随着周期推进而改变层次，因此接收端必须跟踪会话的时间槽索引和已加入的信道。

目标速率并非主观偏好。WEBRC 估算平均分组丢失概率和平均组播往返时间，再将这些测量值放入一个受 TFRC 启发、类似 TCP 的方程。计算结果决定是否可以再加入一层而不超过本地目标。RFC 描述了两项设计目标：与 TCP 竞争时保持合理公平，以及让吞吐量随时间变化得更平滑；相应代价是可用带宽变化时的反应慢于 TCP。这些是规范中的设计目标，不是证明某个部署已达到目标的现场测量。

复杂度与发送端认知的交换

发送端的工作有意保持简单。它需要会话总体发送速率上限、信道分配、时间参数，以及标识信道和时间槽的分组头部。更复杂的任务落在接收端：测量丢包、估算组播往返时间、更新平均值、跟踪不断变化的层次顺序，并决定何时加入或离开。不同接收端可以保持不同速率，而不必让最慢的一方拖低所有人的速度。

这种交换也限制了发送端所能知道的内容。某个接收端加入或离开信道，会改变网络向该接收端分发数据的路径；它不会变成一份通知，告诉发送端谁收到了哪些数据。RFC 3738 是拥塞控制组件，不是完成确认协议。它不提供重传或丢失恢复，也把会话描述、分组与会话的对应关系留给其他构件或带外分发。可靠性、接收端是否完成，以及应用是否接受内容，仍是彼此独立的问题。

RFC 3738 属于更广泛的 RMT 设计工作。RFC 3269 讨论可靠组播传输的模块化方法，RFC 3048 则提供组合构件的框架。因此，WEBRC 可以和可靠传输或对象交付机制配合，但组合并不会让每个构件的职责自动合并。拥塞控制器可以调节接收，却不能保证对象已经重建；修复层可以协助对象重建，却不一定通知发送端哪个接收者已经完成。

RFC 3738 的状态也是这段历史的一部分。作者明确将其作为 Experimental 机制发布，等待初步部署和实际经验检验有效性与可扩展性。工作组表示，如果之后认为方案足够成熟，打算重新提交为 Proposed Standard。这项意向本身并不能证明方案已经部署、后来经过标准化决策或得到运营采用。文档保存的是一项设计及其假设；要证明存在运行实现、具体行为测量或后续规范决定，都需要各自的证据。

来源