Summary

  • RFC 3738 put WEBRC's congestion measurements and rate decisions at each receiver, which joined or left multicast channels rather than sending per-receiver reports upstream.
  • The sender's layered waves made those membership choices translate into different reception rates, but shifted complexity to receivers and offered no reliability or proof of delivery.

The quiet sender was not the whole system

Multicast offered an appealing arithmetic: one sender could transmit a session to a group instead of opening an independent data stream for every recipient. But congestion does not arrive evenly. A receiver behind a narrow or busy link can experience loss while another receiver in the same session has room to receive more. If the sender had to collect and process a report from every receiver before adjusting its transmission, feedback itself could become a scaling problem.

RFC 3738, published as an Experimental RFC in April 2004, explored a different allocation of work. Wave and Equation Based Rate Control, or WEBRC, was a building block for multicast protocols. It did not require receivers to send congestion reports to the sender. Each receiver measured conditions on its own path, calculated a target reception rate, and changed the multicast channels to which it subscribed. “No feedback to the sender” therefore did not mean “no signal.” The signal was an ordinary network action: join or leave a channel.

The distinction is subtle but consequential. A sender did not receive a per-receiver account of loss, available bandwidth or completion. A receiver did not wait for the sender to negotiate a personalized stream. Instead, the sender emitted a common set of channels, while each receiver selected a portion of that set according to its own estimate of congestion.

Rate control expressed as membership

WEBRC divided a session into a low-rate base channel and multiple wave channels. The base channel helped a receiver orient itself in the session’s time-slot cycle and remained joined for the duration of participation. The wave channels carried rates that changed over time: after a high-rate beginning, a wave’s packet rate declined across successive time slots and eventually entered a quiet period before the cycle repeated.

This time shape let a receiver choose a rate without asking the sender to create a new stream for it. To raise its target rate, it joined another active wave layer earlier in that wave’s descent. To reduce its rate, it stopped joining additional layers and left a channel when that wave became quiescent. Since the active waves move between layers as the cycle advances, the receiver had to track the session’s time-slot index and the channels it already joined.

The receiver’s target was not an arbitrary preference. WEBRC estimated average packet-loss probability and average multicast round-trip time, then put those measurements into a TCP-like equation inspired by TFRC. The result guided whether another layer would keep the receiver at or below its target. The RFC described an intended balance: reasonably fair competition with TCP and smoother throughput over time, with the cost of slower response than TCP when available bandwidth changed. Those are design goals in the specification, not field measurements proving a particular deployment behaved that way.

A trade in complexity and knowledge

The sender’s work was deliberately simple in comparison. It needed a session-wide upper transmission bound, channel assignments, timing parameters and packet headers that identified the channel and time slot. The receiver carried the heavier burden: measuring loss, estimating multicast RTT, updating averages, tracking a changing layer order and deciding when to join or leave. Different receivers could settle at different rates without forcing the slowest one to set the rate for everyone.

That trade also limited what the sender could know. A receiver’s join or leave changed the network’s distribution path for that receiver; it did not become a report that the sender could use to identify who had received which data. RFC 3738 was a congestion-control component, not a completion protocol. It supplied no retransmission or loss-recovery mechanism. It also left session description and packet-to-session identification to other building blocks or out-of-band distribution. Reliability, receiver completion and application acceptance remained separate questions.

The experiment belongs in a broader RMT design effort. RFC 3269 described a modular approach to reliable multicast transport, and RFC 3048 defined a framework for assembling building blocks. WEBRC could therefore be paired with reliability or object-delivery mechanisms, but combining components did not erase their separate responsibilities. A congestion controller can regulate reception without guaranteeing that an object is reconstructed; a repair layer can help reconstruct an object without telling the sender which receiver finished.

RFC 3738’s status is part of the story. Its authors explicitly framed the specification as Experimental while waiting for initial deployment and experience to show whether the scheme was effective and scalable. The working group stated an intention to seek Proposed Standard status if the scheme was later judged adequate. That intention is not proof of deployment, a later standards decision or operational adoption. The document records a design and its assumptions; a live implementation, measured behavior and a later standards action would each require their own evidence.

Sources