RFC 3738

Wave and Equation Based Rate Control (WEBRC) Building Block

📅 published April 2004, from ietf

RFC 3738: Wave and Equation Based Rate Control (WEBRC) Building Block 🦋

okay bestie, here's the header info 💖

  • RFC number: 3738
  • Title: Wave and Equation Based Rate Control (WEBRC) Building Block
  • Authors: M. Luby (Digital Fountain) and V. Goyal (M.I.T.)
  • Category: Experimental
  • Date: April 2004
  • Obsoletes / Updates: the header doesn't list either one 🌸

Status of This Memo ✨

so this memo defines an Experimental Protocol for the Internet community 🧪. it does NOT specify an Internet standard of any kind, so don't go treating it like one 🙈. they're asking for discussion and suggestions for improvement, and distribution of this memo is unlimited 💜.

Copyright (C) The Internet Society (2004). All Rights Reserved. 💅

Abstract 🌈

okay so this doc specifies Wave and Equation Based Rate Control (WEBRC) 🌊, which handles rate and congestion control for data delivery. WEBRC is built specifically to support protocols that use IP multicast 📡.

here's the iconic part: it gives multiple-rate, congestion-controlled delivery to receivers 👑. that means different receivers in the same session can be getting packets at different rates. it depends on how much bandwidth each one has on its own connection to the sender, plus whatever other traffic is competing along those connections. not me receivers having the same experience 💀.

WEBRC needs no feedback from receivers to the sender. it's a completely receiver-driven congestion control protocol 🫶. because of that it's designed to scale to potentially massive numbers of receivers attached to a session from one sender 🚀.

and the potential is wild: since every receiver adjusts to the bandwidth between the sender and itself, data can reach each receiver at the fastest rate possible for that receiver. this works even in a highly heterogeneous network architecture, still with just a single sender ✨🔥.

Table of Contents 📖

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Functionality . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1. Sender Operation . . . . . . . . . . . . . . . . . . . .   9
            3.1.1. Sender inputs and initialization. . . . . . . . .   9
            3.1.2. Sending packets to the session. . . . . . . . . .  10
       3.2. Receiver Operation . . . . . . . . . . . . . . . . . . .  12
            3.2.1. Receiver inputs and initialization. . . . . . . .  12
            3.2.2. Receiver measurements and calculations. . . . . .  13
                   3.2.2.1. Average loss probability . . . . . . . .  13
                   3.2.2.2. Average round-trip time. . . . . . . . .  16
                   3.2.2.3. Rate Equation. . . . . . . . . . . . . .  16
                   3.2.2.4. Epochs . . . . . . . . . . . . . . . . .  17
                   3.2.2.5. Average reception rate . . . . . . . . .  17
                   3.2.2.6. Slow start . . . . . . . . . . . . . . .  19
                   3.2.2.7. Target rate. . . . . . . . . . . . . . .  20
            3.2.3. Receiver events . . . . . . . . . . . . . . . . .  20
                   3.2.3.1. Packet reception . . . . . . . . . . . .  20
                   3.2.3.2. First packet after join. . . . . . . . .  20
                   3.2.3.3. Time slot change . . . . . . . . . . . .  20
                   3.2.3.4. Loss event . . . . . . . . . . . . . . .  21
                   3.2.3.5. Epoch change . . . . . . . . . . . . . .  21
                   3.2.3.6. Join the next higher layer . . . . . . .  21
                   3.2.3.7. Join timeout . . . . . . . . . . . . . .  23
                   3.2.3.8. Exceptional timeouts . . . . . . . . . .  23
   4.  Applicability Statement . . . . . . . . . . . . . . . . . . .  23
       4.1. Environmental Requirements and Considerations. . . . . .  23
   5.  Packet Header Fields. . . . . . . . . . . . . . . . . . . . .  25
       5.1. Short Format Congestion Control Information. . . . . . .  26
       5.2. Long Format Congestion Control Information . . . . . . .  27
   6.  Requirements From Other Building Blocks . . . . . . . . . . .  28
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
   8.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  29
       8.1. Normative References . . . . . . . . . . . . . . . . . .  29
       8.2. Informative References . . . . . . . . . . . . . . . . .  30
   9.  Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  31
   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  32

1. Introduction 🧚

okay so this doc specifies Wave and Equation Based Rate Control (WEBRC) 🦋. WEBRC is a congestion control building block designed to be massively scalable when it's used with the IP multicast network service 📡. it's also a good base for unicast congestion control, but that's outside the scope of this document 🙈. WEBRC is designed to compete fairly with TCP and similar congestion-controlled sessions ⚖️. and it can be used as a congestion control protocol for any type of data delivery, including reliable content delivery and streaming delivery 💜.

WEBRC is a receiver-driven congestion control protocol in the spirit of [5] and [18] 🫶. so all the measurements and the decisions to raise or lower the reception rate are made by each individual receiver. those decisions get acted on by sending join and leave messages for channels to the network 📨. a WEBRC receiver adjusts its reception rate without regard for other concerns, like reliability. this is different from TCP, where the congestion control protocol and the reliability protocol are intricately interwoven 🧶.

WEBRC takes the same basic equation-based approach as TFRC [9] 🧮. specifically, each WEBRC receiver measures parameters that get plugged into a TCP-like equation. that computes the receiver's target reception rate, and then the receiver adjusts its reception rate up and down to closely approximate that target 🎯. the sender sends packets to multiple channels. one channel is called the base channel, and the rest are called wave channels 🌊. each wave channel follows the same pattern of packet rate transmission, spread out over equally-spaced intervals of time. the pattern of each wave is that it starts at a high rate, and the rate decreases gradually and continually over a long period of time. (picture an infinite sequence of waves 🌊🌊🌊.)

here's how the moves work 💅. the receiver increases its reception rate by joining the next wave channel earlier in the descent of the wave than it joined the previous wave channel. and the receiver decreases its reception rate by joining the next wave channel later in the descent of the wave than it joined the previous one ✨.

the wave channels are ordered at each point in time from a lowest layer to a highest layer 📶. at any moment, the lowest layer is the wave channel that is nearest to the end of its active period among all the active wave channels. the highest layer is the wave channel that is furthest from the end of its active period 🌅. waves keep becoming active and quiescent over time, so which wave channel sits at which layer changes dynamically too 🔄. on top of being joined to the base channel, at each point in time a receiver is joined to a consecutive set of layers. it starts at the lowest layer and works its way towards the highest 🪜.

WEBRC introduces a natural notion of a multicast round-trip time (MRTT) 🕰️. each receiver measures an MRTT individually, and those get averaged as a substitute for the conventional unicast round-trip time (RTT). this matters a lot because the throughput of a TCP session depends strongly on RTT. so having some measure of RTT is essential for making the WEBRC equation-based rate control protocol "TCP-friendly" 🤝. the MRTT also helps coordinate and equalize the reception rates of nearby receivers joined to a session behind a bottleneck link 🚧. packets for the session that flow through that bottleneck link are, on average, sent to almost all downstream receivers, so the efficiencies of multicast are realized 🍓. and WEBRC is designed to be massively scalable in the sense that the sender doesn't care how many receivers are joined to a multicast session 📈.

WEBRC is designed for applications that use a fixed packet size and vary their packet reception rates in response to congestion 📦. it's meant to be reasonably fair when competing for bandwidth with TCP flows. here "reasonably fair" means a flow's reception rate is generally within a factor of two of the reception rate of a TCP flow under the same conditions ⚖️. the lowdown is that WEBRC has a much lower variation of throughput over time than TCP 😌. that makes it better for things like telephony or streaming media, where a relatively smooth rate matters 🎧. the tradeoff for being smoother than TCP while still competing fairly is that WEBRC responds more slowly than TCP to changes in available bandwidth 🐢.

the receiver does the measuring and calculating for congestion control parameters, like the average loss probability and the average MRTT 🧠. then it makes its decisions about how to increase or decrease its rate based on those parameters 🎛️. the receiver-based approach is a great fit for applications where the sender is handling many concurrent connections. that's why WEBRC works as a building block for multicast congestion control 💪.

the paper [16] and the technical report [15] give most of the rationale and intuition behind the WEBRC design, and they describe some preliminary simulations 📚.

this document describes a building block as defined in RFC 3048 [4] 🧱. it also describes a congestion control building block that conforms to RFC 2357 [3] ✅. and it's a product of the IETF RMT WG, following the general guidelines in RFC 3269 [2] 🎀. the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1] 🔑.

Statement of Intent 🎯

this memo contains part of the definitions needed to fully specify a Reliable Multicast Transport protocol under RFC 2357 🧩. as RFC 2357 says, using any reliable multicast protocol on the Internet requires an adequate congestion control scheme 🚦. this document specifies an experimental congestion control scheme. while the scheme waits for initial deployment and experience to show it's effective and scalable, the IETF publishes it in the "Experimental" category 🧪.

the RMT Working Group intends to re-submit this specification as an IETF Proposed Standard once the scheme is deemed adequate 👑.

2. Rationale ✨

okay so WEBRC gives you congestion control for massively scalable protocols that run over the IP multicast network service 🌸. The congestion control it provides is the same kind of thing lots of different apps need, including reliable content delivery and streaming apps. no cap, it's giving versatile 💅

WEBRC is built to do congestion control for all the packets sent to a session. A session is a bunch of channels coming from one single sender, used for some period of time to carry packets about one or more objects that receivers might be into 🎀. Why one sender? Because that's the right granularity to regulate packet traffic with congestion control. Why multiple channels inside the same session? Because it lets the data be layered, which means each receiver can control its reception rate by joining and leaving channels while it's in the session 🦋. Layered data is lowkey perfect for streaming, since the most important stuff goes on the lower layers and the incrementally valuable stuff goes on the higher ones 🎬.

For reliable content delivery, as described in [13], an app can send packets with encoded data made from an object, so that once a receiver gets enough packets it can reliably rebuild the original object 🧩. A big win is that each receiver controls its reception rate independently of every other receiver. So, for example, a receiver with a slow connection to the sender doesn't slow down the receivers with faster connections 🚀.

There are coding techniques that give you massively scalable reliability and asynchronous delivery and that work with WEBRC, e.g., as described in [11]. Put them together and you get a massively scalable, reliable, asynchronous content delivery protocol that's network friendly 🫶. WEBRC also gives you congestion control that's suitable for streaming apps ✨.

WEBRC avoids anything that isn't massively scalable 🙈. For example, WEBRC doesn't provide any mechanisms for sending information from receivers to senders. That said, it doesn't rule out protocols that use WEBRC and also send information from receivers to senders 💜.

WEBRC's congestion control can be tuned for different apps with different needs 🎀. A content delivery protocol might aggressively try to use all the available bandwidth between receivers and the sender, so to stay fair it has to drastically reduce its rate when there's competing traffic 😭. A streaming protocol might instead aim to hold a constant rate rather than grab all the bandwidth, so it may not reduce its rate as fast when there's competing traffic 🌊.

WEBRC doesn't do anything beyond congestion control, so it has to be combined with other building blocks to make a complete protocol instantiation 🧱. For example, WEBRC doesn't provide any means to identify which session each received packet belongs to. And it doesn't support identifying which object each packet is carrying info about 🙅‍♀️.

3. Functionality 👑

A WEBRC session is a logically related set of channels from one single sender, used for some period of time to carry data packets with a header holding WEBRC Congestion Control Information 📦. When packets come in, they're first checked to make sure they belong to the right session before WEBRC gets applied 💅. A session label defined by the protocol instantiation can be carried in each packet to say which session it belongs to. For example, if LCT [12] is being used with the session, then the sender IP address together with the Transport Session Identifier that LCT supports would decide which session a received packet belongs to 🔍. How that filtering works is outside the scope of this document. From here on, references to channels are always within the scope of a single session 🫶.

A channel can be uniquely identified at the network layer by a (sender IP address, multicast group address) pair, and that's the address receivers send messages to in order to join and leave the channel 🦋. The channels used by a WEBRC session are mapped uniquely to consecutive channel numbers. In each packet sent to a channel, the channel number that matches that channel is carried in WEBRC Congestion Control Information. A WEBRC receiver uses that channel number to figure out which channel in a session a packet came from 🧭.

At the sender, time is split into time slots, each one TSD seconds long ⏰. There's a fixed number T of time slot indices for a session. As time goes on, the current time slot index goes up by one modulo T every TSD seconds. The current time slot index CTSI is carried in WEBRC Congestion Control Information, which lets receivers do very coarse-grained synchronization within a session 🌈.

WEBRC congestion control works by having the sender send packets for a given session to several different channels 🌊. Individual receivers dynamically join and leave these channels according to the network congestion they experience. Those adjustments are made at each receiver independently of all the other receivers, with no impact on the sender 🙌. A packet sequence number is carried in WEBRC Congestion Control Information. The packet sequence numbers are numbered consecutively per channel, and receivers use them to measure packet loss 📊.

The channels associated with a session are one base channel and T wave channels. The packet rate for each channel changes over time 🎢. For the base channel, packets are sent at a low rate BCR_P at the beginning of a time slot, and that rate gradually drops to P*BCR_P by the end of the slot, where P < 1 is a constant defined later on. This base channel pattern repeats every time slot 🔁. For each wave channel i, packets go to channel i at a rate that first shoots up very quickly to a high rate, then falls over time by a fixed fraction P per time slot until it hits BCR_P at the end of time slot i. After that comes a stretch called the quiescent period, where no packets go to wave channel i. Then the whole cycle starts over, and the cycle lasts T*TSD seconds. The wave channels all go through the same cyclic rate pattern, spaced out evenly by TSD seconds 💫.

Before joining a session, receivers MUST obtain enough of the session description to start the session. This MUST include the relevant session parameters a receiver needs to take part in the session and do WEBRC congestion control 📝. The sender decides the session description, and it's typically communicated to receivers out of band. How receivers get it is outside the scope of this document 🕵️‍♀️.

When a receiver starts a session, it first joins the base channel 🏠. The packets on the base channel help the receiver orient itself in terms of what the current time slot index is, and that in turn lets it know the relative rates on the wave channels 🧭. The receiver stays joined to the base channel for the whole time it's in the session.

At each point in time, the active (non-quiescent) wave channels are sorted into layers 🪜. The lowest layer is the active wave channel whose wave is nearest to completion, and the highest layer is the active wave channel whose wave is furthest from completion. (This is almost the same as saying the lowest layer has the lowest rate and the highest layer has the highest rate. The small possible deviation comes from the optional non-exponential beginnings of the waves described in [8].) Each time a wave channel becomes active, it becomes the highest layer. At the end of each time slot, the lowest-layer wave channel goes quiescent, so all the active wave channels slide down a layer at that moment 🛝. At any point in time, a receiver is joined to the base channel and to a consecutive set of layers starting with the lowest. Each time a receiver joins a wave channel, it joins the lowest layer it hasn't joined yet. A receiver always leaves the lowest layer when it becomes quiescent 👋.

After joining a session, the receiver ramps its rate up by joining wave channels in sequence, starting with the lowest layer and moving toward the highest 📈. The rates on the active wave channels decrease with time, so the receiver ramps its rate down simply by not joining any additional wave channels 📉. Because the layer ordering changes dynamically depending on the current time slot index, it's important for the receiver to keep monitoring the current time slot index in received packets 👀. The reception rate at a receiver is decided by how early it joins each wave channel. The earlier the receiver joins a channel with respect to when its wave started, the higher the reception rate 🏎️.

Once a receiver is joined to a wave channel, it stays joined until that channel goes quiescent, and at that point the receiver MUST leave the channel 🚪.

The way the receiver adjusts its reception rate is inspired by TFRC [9] 🦋. At all points in time, the receiver keeps a target reception rate, and it's allowed to join the next wave channel if, after joining, its anticipated reception rate from all the layers it's joined to would be at most its target reception rate 🎯. The target rate gets continually updated based on a set of measured parameters. The primary ones are an estimate LOSSP of the average loss probability and an estimate ARTT of the average multicast round-trip time 🧮.

In the remainder of this document, log(X) denotes the natural logarithm of X, i.e., the logarithm base 2.71828459... of X 🤓.

3.1. Sender Operation 🎤

The sender operation is by design much simpler than the receiver operation 💖.

3.1.1. Sender inputs and initialization

okay so the main input the sender gets for a session is SR_b 💖. SR_b is an upper bound on the sender transmission rate in bits per second at any point in time (with some reasonable granularity), added up across all the channels 🎀. Naturally, that also makes it the max rate in bits per second that any receiver could receive data from the session at any moment 👑. It is RECOMMENDED that the sender transmission rate in aggregate to all channels be made constant as described in [8]. It is also RECOMMENDED that the session description indicate whether the aggregate transmission rate is constant, unless there is no ambiguity ✨.

The secondary inputs are the supporting cast 🧚. They're secondary because their values will usually be fixed to default values that never change, because they get derived from SR_b, or because they're picked based on non-WEBRC considerations. Here they are:

  • LENP_B is the length of packets in bytes sent to the session. The value of LENP_B depends on the complete protocol, but in general this SHOULD be set to as high a value as possible without exceeding the MTU size for the network that would cause fragmentation 📦.
  • BCR_P is the transmission rate on the base channel at the beginning of a time slot in packets per second. The default value for BCR_P is 1 🍓.
  • TSD is the time slot duration measured in seconds. The RECOMMENDED value for TSD is 10 ⏰.
  • QD is the minimum quiescent period duration measured in seconds. The RECOMMENDED value for QD is 300 💤.
  • P is the multiplicative drop in every channel rate over each time slot. The default value for P is 0.75 📉.
  • N is the duration in time slots for each wave. N is also the number of wave channels active at any time. (A wave channel is called active when it is not quiescent.) A sender may choose any value that allows it to produce waves that substantially follow the required exponential shape described in Section 3.1.2. A RECOMMENDED mechanism for relating N to SR_b, BCR_P and P is described in [8] 🌊.

From these inputs, the following fixed sender parameters can be derived. Bestie, these are the math-y ones, so hold on tight 🤓:

  • SR_P = SR_b/(8*LENP_B) is the sender transmission rate in packets per second.
  • BCR_b = 8*LENP_B*BCR_P is the rate of the base channel at the beginning of a time slot in bits per second.
  • L = ceil(BCR_P*TSD*(P-1)/log(P)) is the number of base channel packets sent in each time slot.
  • Q = ceil(QD/TSD) is the number of quiescent time slots per cycle for a wave channel.
  • T = N + Q is the total number of time slots in a cycle. T is also the total number of wave channels.
  • For the base channel CN = T, and for the wave channels CN = 0,1,...,T-1. The sender has the description of the channels assigned to the session and the mapping between the channels and the CNs.
  • C = TSD*T is the total duration of a cycle in seconds.

3.1.2. Sending packets to the session

The sender keeps track of the current time slot index CTSI 🕰️. The value of CTSI is incremented by 1 modulo T each TSD seconds. The value of CTSI is placed into each packet in the format described in Section 5. For each packet sent to the session, the sender also places the channel number CN of the channel into the packets in the format described in Section 5. Recall that CN = T for the base channel and CN = 0,1,...,T-1 for the wave channels.

For each packet sent to the session, the sender calculates a packet sequence number PSN and places it into the packet 🔢. The value of PSN is scoped by CN, and the value of PSN is consecutively increasing within each channel. Furthermore, for each wave channel, the last packet sent before the channel becomes quiescent must have the maximum possible PSN value. When the short format for Congestion Control Information is used (see Section 5.1), this implies that for any wave channel the last PSN value sent to the channel just before the channel becomes quiescent is 2^16-1 = 65,535. Similarly, when the long format for Congestion Control Information is used (see Section 5.2), the PSN for the final packet of any wave is 2^32-1 = 4,294,967,295. The PSN of the initial packet of a wave thus depends on TSD, P, BCR_P and SR_P.

For the base channel, the first packet of each time slot has a PSN congruent to zero modulo L. Hence, instead of 2^16 - 1 or 2^32 - 1 being the highest PSN used (depending on the choice of short format or long format Congestion Control Information), the highest PSN is one less than the largest multiple of L that does not exceed 2^16 (short format) or 2^32 (long format). The format for the PSN within packets is described in Section 5. It's a whole thing, but it's giving very precise 💅.

The rate at which packets are sent to the base channel starts at BCR_P packets per second at the beginning of each time slot and decreases exponentially to P*BCR_P at the end of that time slot 📉.

The packet rate for the wave channels is more complicated 😤. Each wave channel carries a sequence of waves separated by quiescent periods. On each wave channel, each wave is active during N time slots followed by a quiescent period of Q time slots. The waves on wave channel i end at the ends of time slots with CTSI i. Therefore, wave channel i is active during time slots i-N+1 modulo T, i-N+2 modulo T, ..., i, and is quiescent for time slots i+1 modulo T, i+2 modulo T, ..., i+Q modulo T. Wave channel i first becomes active within time slot i-N+1 modulo T at a point in time that may depend on the value of SR_b.

Except for at most the first two time slots after a wave becomes active, the packet rate of the wave MUST decrease exponentially by a factor of P per TSD seconds, down to a rate of BCR_P at the end of the last active time slot. At the beginning of each wave, i.e., for at most the first two time slots when the wave becomes active, the rate MAY deviate from this exponential form so that the total sending rate in aggregate to all of the channels is constant. A RECOMMENDED design for the beginnings of waves to achieve this goal is described in [8] 🌈.

3.2. Receiver Operation

The bulk of the complexity in WEBRC is in the receiver operation 🧠. For ease of explanation, suppose for the moment that during the reception there is no packet loss and packets are arriving at exactly the rate at which they were sent. The sender transmission rate to the channels is designed so that the receiver reception rate behaves as follows.

Upon entering a session, the receiver immediately joins the base channel 🚪. When the receiver wants to increase its rate, it joins consecutive layers starting with the lowest and moving towards the highest. (Recall that the designations of lowest to highest change as waves become active and quiescent.) When the receiver wants to maintain its current reception rate and it is already joined to the lowest NWC layers, if the receiver joins channel i-1+NWC modulo T sometime during time slot i, then the receiver joins channel i+NWC modulo T TSD seconds later in time slot i+1. When the lowest layer becomes quiescent, the receiver leaves the channel 👋.

Suppose the receiver wants to decrease its rate till it is joined to just the base channel. Assume that a receiver is joined to the lowest NWC < N-2 layers at the beginning of time slot i, i.e., wave channels i, i+1 modulo T, ..., i+NWC-1 modulo T. Then, the aggregate packet reception rate of the receiver over the next NWC time slots will behave as follows if the receiver does not join any wave channels during this time. At the beginning of time slot i, the receiver reception rate is BCR_P*(1 + (1/P) + (1/P)^2 + ... + (1/P)^NWC). Then the receiver reception rate decreases by a factor of P over the duration of each time slot, and at the end of each time slot the reception rate decreases by an additive amount of P*BCR_P. At the end of time slot i+NWC-1 mod T, the receiver reception rate is BCR_P*(1+P), and at the beginning of time slot i+NWC mod T the receiver is joined only to the base channel and its reception rate is BCR_P 📊.

3.2.1. Receiver inputs and initialization

Before joining a session, the receiver MUST know the mapping between the CNs and the channels 🗺️. Upon joining the session or shortly thereafter, it SHOULD have the values of LENP_B, BCR_P, TSD, P, N, L, Q and T. Some of these values may be computed or measured once the receiver has joined the session. For example, the receiver MAY obtain LENP_B and T from the first packet received from the base channel, and the receiver MAY measure BCR_P once it is joined to the base channel. The values of P, Q and TSD MAY be fixed to default values built into the receiver that do not change from session to session, and the value of N MAY be computed as T-Q. The receiver SHOULD know whether the sender is employing a technique to produce constant aggregate rate as described in [8] 🧐.

When a receiver first joins a session, it MUST first join just the base channel and start receiving packets to determine the current time slot index 🔍. If during the course of the session the receiver continually loses a high fraction of the packets from the base channel, even when the receiver is only joined to the base channel, the receiver SHOULD leave the session 🚫.

The receiver MAY also have other individually set parameters that may be used to determine its behavior ⚙️. One such parameter is MRR_b:

  • MRR_b is the maximum receiver reception rate in bits per second. This may be used to determine the maximum reception rate this receiver is willing to reach. Thus, the maximum reception rate that the receiver can possibly achieve in the session is the minimum of SR_b and MRR_b. A recommended value of MRR_b for a receiver is the bandwidth capacity of the last link to the receiver. MRR_P is the maximum receiver reception rate in packets per second, i.e., MRR_P = MRR_b/(8*LENP_B) 💫.

3.2.2. Receiver measurements and calculations

As outlined in the introduction, the way a receiver adjusts its reception rate is inspired by TFRC [9] 🦋. The receiver at all points in time maintains a target reception rate, and the receiver is allowed to join the next wave channel if joining would increase its reception rate to at most its target reception rate. The target rate is continually updated based on a set of measured parameters 🎯.

Two primary parameters are the estimate LOSSP of the average loss probability and the estimate ARTT of the average MRTT. Both LOSSP and ARTT are moving averages of measurements based on discrete events 📈. For many of the other estimates calculated by WEBRC, using an exponentially weighted moving average (EWMA) with a fixed averaging fraction is sufficient. However, the calculations of LOSSP and ARTT require a more general and sophisticated filtering approach 🤯.

3.2.2.1. Average loss probability

okay bestie, the TFRC crew [9] figured out that the average packet loss probability can swing by orders of magnitude 😭 so guessing it from a fixed number of packets, or from a fixed chunk of time with a fixed averaging fraction, is gonna be a mess 💀. In TFRC the average gets estimated from the number of packets between the beginnings of loss events, and the number of loss events used is fixed. iconic logic 🧠✨

The estimate LOSSP of the receiver's average loss probability is kept up in a way that's kinda similar to TFRC [9] 🎀. The WEBRC receiver estimates the inverse of the average loss probability by running two EWMA filters on the packet reception measurements. One is a time-based filter with smoothing constant 0 < Nu < 1, and the other is a loss-based filter with smoothing constant 0 < Delta < 1. The recommended values are Nu = 0.3 and Delta = 0.3 🌸.

Why the time-based filter? Because the loss events in WEBRC are bursty. They tend to happen right after a new wave has been joined 🌊. To smooth out that burstiness, the time-based filter gets applied to the packet reception measurements at the end of each epoch, so the bursty loss events get spread out over a few time slot durations. Intuitively, it averages reception events so they're smoothed over an interval of time proportional to TSD/Nu seconds 🦋. The loss-based filter (similar to what TFRC suggests) then runs on the output of the time-based filter to produce the estimate of the inverse of the average loss probability. Intuitively, each loss event gets averaged in with weight Delta 💜.

LOSSP gets initialized at the end of slow start, and it gets occasionally reset because of other events 🔄. Let W and X be counts of packets, let Y be a count of loss events, and let Z be the long-term estimate of the inverse of the average loss probability. Whenever LOSSP is initialized or reset, W, X, Y and Z get initialized or reset too. no exceptions, bestie 🫶

Quick reminder: TSD is the duration of a time slot. The epoch length EL is the amount of time between decisions to adjust the reception rate. EL is usually way smaller than TSD, and the RECOMMENDED values are EL = 0.5 seconds and TSD = 10 seconds ⏱️.

Now define G = Nu*EL/TSD as the amount of time-based smoothing to do at the end of each epoch 🧁. The update rules for W, X, Y, Z and LOSSP are:

  • At the end of each epoch, adjust X, Y and Z, then compute LOSSP like this:
Z = Z*(1-Delta)^(G*Y) + G*X/(G*Y+1)*(1-(1-Delta)^(G*Y+1))

X = X*(1-G)

Y = Y*(1-G)

Z1 = Z*(1-Delta)^Y + X/(Y+1)*(1-(1-Delta)^(Y+1))

Z2 = Z*(1-Delta)^(Y+1) + (X+W+1)/(Y+2)*(1-(1-Delta)^(Y+2))
LOSSP = 1/max{Z1,Z2,1}
  • For each packet event (whether it's a received packet or a lost packet), do W = W + 1 📦
  • At the beginning of each loss event, update W, X and Y like so:
X = X + W

W = 0

Y = Y + 1

So here's the intuition 🤓. If we only used loss-filtering to update Z, then Z would get decreased by a multiplicative amount of 1 - Delta for each loss event, and increased by an additive amount of Delta for each packet. To spread loss events over more than one time slot, those adjustments get filtered into Z over time, at a rate of a fraction G at the end of each epoch 🌈. So X and Y are counts of the packets and loss events (respectively) that haven't been filtered into the long-term memory Z yet. W is the count of packets since the last loss started, which is why W goes up by one for each packet and Y goes up by one for each loss event ✨. At the end of each epoch, a fraction G of both X and Y gets filtered into Z using the loss-filter rule above, and then that same fraction G gets removed from X and Y, since that portion has now made it into Z. The LOSSP calculation mixes the short-term history (X, Y) with the long-term history Z, and it also lets the arrivals since the last loss, W, have some say 🍓. And Z2 is what Z1 would become if the next packet were lost 👀.

To reset the loss calculation to a value LOSSP = a, set the state variables like this:

W = 0

X = 0

Y = 0

Z = 1/a

3.2.2.2. Average round-trip time

The receiver keeps track of an average round-trip time, ARTT 🏃‍♀️💨. It's a measurement-based filter over MRTT measurements, using a smoothing constant 0 < Alpha < 1. The RECOMMENDED value for Alpha is 0.25 💖.

Every time the receiver joins a channel (either the base channel when it enters a session, or wave channels continually), it takes a measurement of the multicast round-trip time MRTT. Here's the tea 🫖. V is an auxiliary variable used to keep track of the average of the square of the MRTT measurements. When the receiver sends the join for the channel, it records the current time JoinTime and sets a Boolean variable JOINING to true. When the first packet arrives from that channel, the receiver records the current time FirstTime and sets JOINING back to false 🙌. If it was the base channel that got joined, then:

ARTT = FirstTime-JoinTime

V = ARTT*ARTT

Otherwise, MRTT gets set to:

MRTT = (FirstTime - JoinTime) - log(1/P)/2/(1-P)/BCR_P * P^NWC

(heads up, this value can be negative 🙃)

Then ARTT gets updated like this. Let Omega = Alpha*ARTT*ARTT/V. At the Kth MRTT measurement, let Rho = Omega/(1-(1-Omega)^(K+1)). (Note that as K grows, Rho approaches Omega 📈.) Then:

V = (1-Rho)*V+Rho*MRTT*MRTT

ARTT = max{P*ARTT,(1-Rho)*ARTT+Rho*MRTT}

Usually ARTT gets updated to the second term in the max. In that case, ARTT is an EWMA of the previous ARTT and the new MRTT 💅. The weight on the new MRTT, as K grows, is proportional to the square of the previous ARTT divided by the previous average V of the square of the MRTT measurements. So if the previous MRTTs don't vary much compared to the square of their average, the new MRTT gets filtered into ARTT with a high weight 🔥. But if the previous MRTTs vary a lot relative to the square of their average, the new MRTT gets a low weight 🥀. The reasoning is that, in general, the number of measurements you need for a meaningful average of a random variable is proportional to its variance divided by the square of its average (see, e.g., [6]) 📚. Since the weight depends on previous measurements like this, the weight used to average the new MRTT into ARTT automatically adjusts to how variable the measurements are 🦋.

3.2.2.3. Rate Equation

The receiver works out its reception rate REQN using the TCP equation, like this 🧮:

REQN = 1/(ARTT*sqrt{LOSSP}(0.816 + 7.35*LOSSP*(1+32*LOSSP^2)))

This equation comes from TFRC [9] 🎀.

3.2.2.4. Epochs

The receiver decides whether or not to join another wave channel at equally-spaced units of time called epochs ⏰. The duration of an epoch in seconds, EL, is set to a small fraction of TSD, so that decisions to join a channel can happen at a much finer granularity than TSD 🔍. A standard setting is:

EL = TSD/20

So with the recommended setting of TSD = 10, it is RECOMMENDED that EL = 0.5 ✨💜

3.2.2.5. Average reception rate ✨

okay so the receiver keeps two averaged reception rates 🎀: TRR_P (the true reception rate) and ARR_P (the anticipated reception rate). they do different jobs, so they get calculated super differently 💅. the recommended values for the filtering weights Beta and Zeta are at the end of this subsection 🦋.

in start-up mode, TRR_P keeps the receiver from ramping its reception rate up too fast above what it's currently getting 🐢. when we move from start-up mode into normal operation (and then in normal operation), TRR_P is what sets the slow start rate 🌸. TRR_P is built from RR_P, the receiver reception rate in packets per second measured at the beginning of an epoch and averaged over the epoch that just ended 📊. TRR_P gets initialized to BCR_P + k*log(P)/TSD when the first base channel packet of the session arrives, where k is the PSN of the packet reduced modulo L 🧚. then at the beginning of each epoch, after RR_P is measured for the previous epoch, TRR_P is updated to (1-Zeta)*TRR_P + Zeta*RR_P 💖.

ARR_P is the receiver's estimate of the total instantaneous rate of the channels it's currently joined to 👑. it gets compared against the target rate to decide whether the receiver should bump its reception rate by joining the next higher unjoined layer 🔥. ARR_P is calculated from a measurement called IRR_P and from NWC, the number of joined wave channels 💜. IRR_P is the reception rate in packets per second counting both received and lost packets. like RR_P, it's measured at the beginning of the epoch and averaged over the previous one 🌈. here's how ARR_P, IRR_P and NWC get updated:

  • NWC is initialized to 0 🍓.
  • when the first base channel packet arrives, ARR_P is set to BCR_P + k*log(P)/TSD, where k is the PSN of the packet reduced modulo L 🫶.
  • at the beginning of each epoch, IRR_P is measured over the previous epoch, and then ARR_P is updated to P^(EL/TSD)*(1-Beta)*ARR_P + Beta*IRR_P. after that, if ARR_P is bigger than ARR_P_max = ((1/P)^(NWC+1)-1)/((1/P)-1)*BCR_P, then ARR_P is updated to ARR_P_max 🙅‍♀️.
  • when a join is made to the next higher unjoined layer, NWC is updated to NWC+1, and then ARR_P is multiplicatively increased by the factor ((1/P)^(NWC+1)-1)/((1/P)^NWC-1). (joins happen at epoch boundaries, and this adjustment is in addition to the one above 📍)
  • each time a next time slot index is detected, ARR_P is additively increased by (1-P)*BCR_P to account for the change in rate on the base channel. the bottom layer in the previous time slot has also just gone quiescent, so a message to leave that layer has been sent. that means ARR_P is additively decreased by BCR_P and NWC is decremented by 1. put together, these effects make ARR_P additively decreased by P*BCR_P 😭.

let's think about what happens if Beta = 0 and ARR_P is an accurate estimate of the total rate of the joined channels. the adjustments to ARR_P from joining and leaving wave channels, from the passing of epochs, and from detecting time slot changes will keep ARR_P accurate. but in practice, Beta MUST be positive. letting IRR_P have some influence stops ARR_P from drifting away from being an accurate estimate of the total joined rate 🚨.

why do we need two separate estimates? ARR_P is needed for comparison with the TFRC-inspired target rate because it reflects a potential rate increase from joining the next higher layer with no lag at all. it also measures the total possible impact on the network, since it includes lost packets too. TRR_P is needed because it reflects the rate of data actually arriving at the receiver, and that's how we make sure there isn't a large gap between the joined rate and the receiving rate 🫧.

the recommended values for Beta and Zeta depend on whether the receiver is in start-up mode (SSR_P = infinity). in start-up mode, it is RECOMMENDED that Beta = (1 - P^(0.25))/2 and Zeta = sqrt(P)/(1 + sqrt(P)). in normal operation, it is RECOMMENDED that Beta = 1 - (P/(1+P))^(EL/TSD) and Zeta = 2*EL/(4+TSD) 🎀.

3.2.2.6. Slow start ⚡

WEBRC uses a slow start mechanism to quickly ramp up its rate at the beginning of a session and in the middle of a session when the rate drops precipitously 📉. to make this happen, the receiver keeps track of these parameters:

  • SSMINR_P is the minimum allowed slow start threshold rate in packets per second. the recommended value for SSMINR_P is BCR_P*(1+1/P+1/P^2) 🌷.
  • SSR_P is the slow start threshold rate in packets per second. it gets adjusted at the beginning of loss events, as described in Section 3.2.3.4. SSR_P is initialized to infinity and is first set to a finite value when the receiver leaves the initial start-up period, as described below 🍑.

at the beginning of a session, the receiver can't compute a meaningful target rate from its measurements yet. so it uses SSR_P = infinity until one of the following events ends this start-up mode 🛑:

  • a packet loss is detected. in this case the value of SSR_P is updated to max{SSMINR_P, P*TRR_P}, just like at the beginning of any other loss event 💥.
  • a sharp increase in MRTT is detected. while SSR_P = infinity, the receiver MUST compute, in the notation of Section 3.2.2.2, differences in successive measurements of (FirstTime-JoinTime) from successive waves, and MUST set SSR_P to max{SSMINR_P, P*TRR_P} when a large increase in (FirstTime-JoinTime) is observed 👀. it is RECOMMENDED that an increase in (FirstTime-JoinTime) be considered large if it exceeds (P^(NWC+1)-1)/(P*log(P)) / ARR_P 🔍.
  • the maximum reception rate is reached. when SSR_P = infinity, if (P^(-NWC-2)-1)/(P^(-NWC-1)-1)*ARR_P exceeds MRR_P or SR_P, the receiver MUST set SSR_P to max{SSMINR_P, TRR_P} 🏁.
  • TRR_P is not increasing in a way that's consistent with the last join of a wave channel. while SSR_P = infinity, it is RECOMMENDED that the receiver wait at least one full epoch after the first packet of a wave is received before joining the next wave ⏳. if TRR_P after that full epoch is greatly below ARR_P, the receiver SHOULD NOT join, and SHOULD then set SSR_P to max{SSMINR_P, TRR_P} 🙅. it is RECOMMENDED that TRR_P be considered greatly below ARR_P if TRR_P < c * ARR_P - 2/EL, where c = Zeta + (1-Zeta)*(P^(-EL/TSD))*(Zeta + (1-Zeta)*sqrt(P)*(P^(-EL/TSD)))/g with g = (P^(-NWC-1)-1)/(P^(-NWC)-1) 🧮.

in any of these four cases, the variables associated with LOSSP are reset, so that REQN (calculated as in Section 3.2.2.3 with the current value of ARTT) equals TRR_P 🔄.

3.2.2.7. Target rate 🎯

in typical operation, SSR_P has a finite value, and the target rate TRATE is computed as TRATE = min{max{SSR_P, REQN}, MRR_P}. when SSR_P = infinity, TRATE is computed as TRATE = min{4*TRR_P, MRR_P} 💫.

3.2.3. Receiver events 🦋

there are a bunch of receiver events 🎀. some are triggered by time passing at the receiver, and others by things like packet reception, detection of packet loss, reception of a first packet from a channel, and exceptional time-outs ⏰.

3.2.3.1. Packet reception 📦

most packet reception events just require the receiver to register the reception, so it can later calculate RR_P and IRR_P (see Section 3.2.2.5), and increment W so it can later calculate LOSSP (see Section 3.2.2.1) 📝.

extra actions, described in the following three subsections, are needed if the packet is the first one received in response to a join operation, if the CTSI of the packet indicates a time slot change, or if the CN and PSN of the packet indicate a packet loss 🚨.

3.2.3.2. First packet after join 🚀

when channel i is the most recently joined channel and the Boolean variable JOINING is true, receiving a packet with PSN = i is a special event, because it's the first packet received in response to the most recent join ✨. MRTT is calculated, ARTT and V are updated as described in Section 3.2.2.2, and JOINING is set to false. the first received packet of the session also means ARR_P and TRR_P need to be initialized, as described in Section 3.2.2.5 🌱.

3.2.3.3. Time slot change 🕰️

this is an event triggered by receiving a packet whose CTSI value is one larger, modulo T, than the previous CTSI value 💅. when a packet with a new CTSI = i arrives, a leave is sent for the lowest layer in the previous time slot (that's wave channel i-1 modulo T), NWC is updated to NWC-1, and ARR_P is updated to ARR_P - P*BCR_P as described in Section 3.2.2.5 👋. if the channel that the leave was sent for is also the most recently joined wave channel and JOINING is true, then JOINING is set to false 🫶.

because of packet reordering, some packets from the previous time slot might show up after packets from the current time slot 🌀. it is RECOMMENDED that measures be put into place to handle this situation appropriately, i.e., to not trigger a time slot change in this situation 🛡️. one simple mechanism for this: compute the difference i-j modulo T, where i is the CTSI of the received packet and j is the current CTSI of the receiver. a difference of zero is, of course, not a time slot change 🙄. and a very large difference, for example one larger than T-Q/2, should also not trigger a time slot change 🌙.

3.2.3.4. Loss event 💥

each time the receiver detects a lost packet (based on the sequence numbers in the packets, scoped by the channel number), it records the start of a new loss event and sets the Boolean variable LOSS_EVENT to true. that variable automatically resets to false after ARTT seconds 🕐. all subsequent packet loss within that ARTT-second window counts as part of the same loss event 🧃. when the start of a loss event is detected, the value of SSR_P is updated to max{SSMINR_P, P*TRR_P} 📉.

it is RECOMMENDED that the receiver account for simple misordering of packets without inferring a loss 🤓.

3.2.3.5. Epoch change ⏱️

this is an event triggered by the passage of time at the receiver, and it happens every EL seconds 🕒. when it happens, TRR_P and ARR_P are computed as described in Section 3.2.2.5. right after those updates, a decision gets made about whether to join the next higher layer, as described in Section 3.2.3.6 🪜.

3.2.3.6. Join the next higher layer ✨

okay so at the start of every epoch, right after ARR_P and TRR_P get updated (see Section 3.2.2.5), the receiver decides whether it joins the next higher layer. here's the checklist 💅

  • If the first base channel packet has not yet arrived the receiver MUST not join. 🙈
  • If there is a loss event in progress (LOSS_EVENT = true) the receiver MUST not join. 💀
  • If a join of a channel is in progress (JOINING = true) the receiver MUST not join. ⏳
  • If NWC = N the receiver MUST not join. 🫶
  • If the receiver is employing the OPTIONAL rule described in Section 3.2.2.6, SSR_P = infinity, and a full epoch has not passed since the first packet arrival on the most recently joined wave channel, then the receiver MUST not join. 🌸
  • If the receiver is employing the OPTIONAL rule described in Section 3.2.2.6, SSR_P = infinity, and a full epoch has passed since the first packet arrival on the most recently joined wave channel, then the receiver checks if TRR_P is greatly below ARR_P as described in Section 3.2.2.6. If TRR_P is greatly below ARR_P the receiver MUST not join. 👀
  • The receiver calculates REQN as described in Section 3.2.2.3. 🧮
  • The receiver calculates TRATE as described in Section 3.2.2.7. 🧮
  • If the sender is not sending at constant aggregate rate and TRATE < ARR_P*((1/P)^{NWC+2}-1)/((1/P)^{NWC+1}-1), the receiver MUST not join. If the sender is sending at constant aggregate rate and TRATE < ARR_P*((1/P)^{NWC+2}-1)/((1/P)^{NWC+1}-1) and TRATE < SR_P, the receiver MUST not join. 🚫
  • If SSR_P is finite and the sender is not sending at constant aggregate rate, or SSR_P is finite and the sender is sending at constant aggregate rate and TRATE < SR_P, then the receiver MAY apply one additional OPTIONAL check before deciding to join. ✨

It is RECOMMENDED that the receiver not join if the value of RR_P is not sufficiently lower than the maximum value of RR_P observed since the last join. It is RECOMMENDED that RR_P is sufficiently low to allow a join if RR_P <= max{RRmax-2/EL,P*RRmax}, where RRmax is the maximum measured RR_P since the last join. 💖

If the receiver does not join because RR_P is not sufficiently small, then a value of LOSSP is calculated so as to make the value of the REQN equation given in Section 3.2.2.3 evaluate to ARR_P*((1/P)^(NWC+2)-1)/((1/P)^(NWC+1)-1) with respect to the current value of ARR_P. Then, the variables associated with LOSSP are reset based on this calculated value of LOSSP as described at the end of Section 3.2.2.1. 🔄

  • Otherwise, the receiver MAY join the next higher layer. 🎉

Suppose the receiver has decided to join and CTSI = i. The receiver joins the next higher wave channel, i.e., the wave channel with CN = i+NWC modulo T, increments NWC by 1, and then updates ARR_P to ARR_P*((1/P)^{NWC+1}-1)/((1/P)^NWC-1) as described in Section 3.2.2.5. The time of the join is recorded for use in updating ARTT as described in Section 3.2.2.2. 📝

3.2.3.7. Join timeout 🕰️

when no packet arrives in response to the join of a channel for a long period of time, the join times out. the receiver sets JOINING to false, updates ARR_P to ARR_P*((1/P)^NWC-1)/((1/P)^{NWC+1}-1), and then decrements NWC by 1. 😮‍💨

The RECOMMENDED threshold for a join timeout is max{2*V/ARTT,10*ARTT} seconds. 💅

3.2.3.8. Exceptional timeouts 🚨

these are timeouts where packet reception behavior is way off from what it should be, and these MUST trigger the receiver to leave the session. Exceptional timeouts include:

  • No packets are received for a long period. A RECOMMENDED threshold is max{10,TSD} seconds. 🥀
  • There is no change in time slot index for a long period. A RECOMMENDED threshold is max{20,2*TSD} seconds. 🫠

4. Applicability Statement ✨

WEBRC is intended to be a congestion control scheme that can be used in a complete protocol instantiation that delivers objects and streams (both reliable content delivery and streaming of multimedia information). WEBRC is most applicable for delivery of objects or streams of substantial length, i.e., objects or streams that range in length from hundreds of kilobytes to many gigabytes, and whose transfer time is on the order of tens of seconds or more. 🎬

4.1. Environmental Requirements and Considerations 🌍

WEBRC can be used with both multicast and unicast networks. However, the scope of this document is limited to multicast. WEBRC requires connectivity between a sender and receivers, but it does not require connectivity from receivers to the sender. 📡

WEBRC inherently works with all types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. Thus, the inherent raw scalability of WEBRC is unlimited. However, in some network environments varying reception rates to receivers may not be advantageous. For example, the network may have dedicated a fixed amount of bandwidth to the session, or there may be no effective way for receivers to dynamically vary the set of channels they are joined to, as in a satellite network. 🛰️

Receivers join and leave channels using the appropriate multicast join and leave messages. For IPv4 multicast, IGMP messages are used by receivers to join and leave channels. For IPv6, MLDv2 messages are used by receivers to join and leave channels. This is the only dependency of WEBRC on the IP version. 🔁

WEBRC requires receivers to be able to uniquely identify and demultiplex packets associated with a session in order to effectively perform congestion control over all packets associated with the session. How receivers achieve this is outside the scope of this document. 🔍

WEBRC is presumed to be used with an underlying network or transport service that is a "best effort" service that does not guarantee packet reception or packet reception order, and which does not have any support for flow or congestion control. For example, the Any-Source Multicast (ASM) model of IP multicast as defined in RFC 1112 [7] is such a best effort network service. While the basic service provided by RFC 1112 is largely scalable, providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially in the presence of heterogeneous sets of receivers. ⚖️

There are currently two models of multicast delivery: the Any-Source Multicast (ASM) model as defined in RFC 1112 [7] and the Source-Specific Multicast (SSM) model as defined in [10]. WEBRC works with both multicast models, but in a slightly different way with somewhat different environmental concerns. When using ASM, a sender S sends packets to a multicast group G, and the WEBRC channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and the WEBRC channel address coincides with the SSM channel address. 🧩

A sender can locally allocate unique SSM channel addresses, and this makes allocation of channel addresses easy with SSM. To allocate channel addresses using ASM, the sender has to uniquely choose the ASM multicast group address across the scope of the group, and this makes allocation of WEBRC channel addresses more difficult with ASM. This is an issue for WEBRC because several channels are used per session. 🗂️

WEBRC channels and SSM channels coincide, and thus the receiver will only receive packets sent to the requested WEBRC channel. With ASM, the receiver joins a channel by joining a multicast group G, and all packets sent to G, regardless of the sender, may be received by the receiver. Thus, SSM has compelling security advantages over ASM for prevention of denial of service attacks. In either case, receivers SHOULD use mechanisms to filter out packets from unwanted sources. 🛡️😤

WEBRC assumes that the packet route between the sender and a particular receiver is the same for all channels associated with a session. For SSM this assumption is true because the multicast tree is a shortest path tree from each receiver to the sender, and generally this path changes infrequently. For ASM there are some issues that, if not properly considered, may invalidate this assumption. With ASM, the packet route between the sender and receivers may initially be through the Rendezvous Point (RP) and then switch over to the shortest path to the sender as packets start flowing in a channel. The first issue is that the RP may not be the same for all channels associated with a session, and thus the first packets sent to the channels may follow a route that depends on the RP of the channel. This depends on the RP configuration for the sender. If the sender registers all channels associated with the session with the same RP, then the assumption is true, but if the sender registers different channels with different RPs, then the assumption may not be true. Thus, it is RECOMMENDED that the sender register all channels associated with a session with the same RP. 🧭

Another issue is that when the channel switches over from the RP to the sender-based tree, the route to the receivers may vary within a channel. Furthermore, this may cause either the receipt of duplicate packets at receivers or loss of packets, depending on the smoothness of the switchover. Thus, it is RECOMMENDED that the RP be placed as close as possible to the sender. The best location for the RP is that it be the first-hop router closest to the sender, in which case the path to the sender and the path to the RP are the same for each receiver and the problems mentioned above are eliminated. 🌟

The consequences of this assumption not being true are that the receiver reaction to congestion may not be appropriate. Generally, the WEBRC receiver will act conservatively and reduce its reception rate too much if this assumption is not true, but there can be cases where the receivers will act inappropriately. 😬

5. Packet Header Fields 🎀

Packets sent to a session using WEBRC MUST include Congestion Control Information fields as specified in this section. This document specifies short and long formats for the Congestion Control Information, and it is RECOMMENDED that protocol instantiations use one of these two formats. Other formats for the Congestion Control Information fields MAY be used by protocol instantiations, but all protocol instantiations are REQUIRED to use these fields in a format that is compatible with the interpretations of these fields. Thus, if a protocol does use a different format for the fields in the Congestion Control Information, then it MUST specify the lengths and positions of these fields within the packet header. 🧾

All integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. All constants, unless otherwise specified, are expressed in base ten. 🔢✨

5.1. Short Format Congestion Control Information ✨

okay so the short format is the compact version of the Congestion Control Information, and it's giving tiny but mighty 💅 It's only 32 bits total, and here's how it's laid out 🎀

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      CTSI     | Channel Number|    Packet Sequence Number     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fig. 1 - Short format for Congestion Control Information

each field has its own job, so let's go through them 🦋

Current Time Slot Index (CTSI): 8 bits

CTSI tells you which time slot we're in right now 🕰️ it must be sent in each packet within the session. The index goes up by one modulo T every TSD seconds at the sender, where T is the number of time slots for the session and TSD is the length of a time slot. Also, T is the number of wave channels for the session too, so T MUST be at most 255 💖

Channel Number (CN): 8 bits

CN says which channel this packet belongs to 🌈 the base channel is T, and the wave channels are numbered 0 through T-1. so in total there are T+1 channels being used, which means T MUST be at most 255 again. bestie, this is the same rule, just said twice 🙈

Packet Sequence Number (PSN): 16 bits

the PSN is scoped by its CN value, which is a very main character way of saying each channel keeps its own count ✨ packets sent to the base channel are numbered one after another, modulo 2^16. every wave channel uses the same sequence of PSNs in each cycle. for a wave channel, the numbers count up modulo 2^16 within each cycle, and the last packet sent before the channel goes quiescent gets PSN = 2^16-1 🌸

5.2. Long Format Congestion Control Information 🌷

the long format is the big sister 👑 it's 64 bits total, and every field is basically twice as long:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             CTSI              |        Channel Number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Packet Sequence Number                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fig. 2 - Long format for Congestion Control Information

the meaning of each field is exactly the same as the short format, just with double the bits 🫶

Current Time Slot Index (CTSI): 16 bits

same energy as before 🕰️ CTSI tells you the current time slot, and it must be sent in each packet within the session. it goes up by one modulo T every TSD seconds at the sender, with T being the number of time slots and also the number of wave channels for the session. so T MUST be at most 65,535 ✨

Channel Number (CN): 16 bits

CN is the channel this packet belongs to 🌈 base channel is T, wave channels are 0 through T-1, and that's T+1 channels in total. so T MUST be at most 65,535, and yes, it's the same rule again 💅

Packet Sequence Number (PSN): 32 bits

PSN is still scoped by CN, so each channel keeps its own count 💜 base channel packets are numbered consecutively modulo 2^32. wave channels use the same PSN sequence in each cycle, counting modulo 2^32 within each cycle and ending with PSN = 2^32-1 on the last packet before the channel goes quiescent 🦋

6. Requirements From Other Building Blocks 🧚

okay so WEBRC is a building block 🧱 which means it's meant to be used together with other building blocks to help specify a protocol instantiation. that's the plan from RFC 3048 [4], and it's giving teamwork 🫶

WEBRC doesn't handle higher level session stuff on its own. it doesn't tell receivers how to get the session description they need, and it doesn't tell them how to demultiplex received packets based on their session. but good news, other building blocks can help out 💖 for example, LCT [12] can provide some of the higher level in-band session support that receivers might need, and the WEBRC Congestion Control Information (CCI) that every packet needs can be carried in the CCI field of the LCT header [12] ✨

WEBRC also doesn't do reliability 🙅‍♀️ it doesn't support retransmission of lost packets. if you want reliability, you can add it by other means, like using FEC codes as described in [13] and specified in the FEC building block [14] 🌸

7. Security Considerations 🔒

bestie, this section is serious business, so let's go 😭

WEBRC can be hit by denial-of-service attacks. attackers can try to confuse the congestion control mechanism that receivers use, by injecting forged packets into the multicast stream. the hit is worst for network elements and receivers downstream of the attack, and way less dramatic for the rest of the network and other receivers. because of this, and because of the potential attacks from using FEC (described above), it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers. that helps limit the chance that a bad agent injects forged packets into the multicast tree data path 🚫

it is also RECOMMENDED that packet authentication be used, so each packet gets authenticated right when it's received, before the receiver does any WEBRC actions based on it 🔐 the tea is that there aren't currently any practical multicast packet authentication schemes that give instant authentication on receipt 💀 however, TESLA [17] can authenticate each packet a few seconds after receipt. so TESLA could be used alongside WEBRC to authenticate packets and, for example, terminate the session when a forged packet is detected. but it is RECOMMENDED that the normal WEBRC receiver responses to received packets happen immediately -- not delayed by the TESLA authentication process. why? because WEBRC performance would be greatly degraded if the receiver waited several seconds before responding to a packet 😭

a receiver with an incorrect or corrupted WEBRC implementation may affect the health of the network on the path between the sender and that receiver. it may also affect the reception rates of other receivers joined to the session. so it is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the session description needed to join the session 🪪

another vulnerability is receivers getting an incorrect session description for the session 🙈 the consequences could be that legitimate receivers with the wrong session description can't correctly receive the session content, or that receivers accidentally try to receive at a much higher rate than they can handle, which disrupts traffic in parts of the network. to avoid these problems, it is RECOMMENDED that measures be taken to stop receivers from accepting incorrect session descriptions. for example, use source authentication so receivers only accept legitimate session descriptions from authorized senders 🦋

8. References 📚

8.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.

[3] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.

[4] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.

8.2. Informative References

[5] Byers, J., Horn, G., Luby, M., Mitzenmacher, M. and W. Shaver. "FLID-DL: Congestion control for layered multicast," IEEE J. on Selected Areas in Communications, Special Issue on Network Support for Multicast Communication, Vol. 20, No. 8, October 2002, pp. 1558-1570.

[6] Dagum, P., Karp, R., Luby, M. and S. Ross, "An optimal algorithm for Monte Carlo estimation," SIAM J. Comput., 29(5):1484-1496, April 2000.

[7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.

[8] Goyal, V., "On WEBRC Wave Design and Server Implementation", Digital Fountain Technical Report no. DF2002-09-001, September 2002, available at http://www.digitalfountain.com/technology/.

[9] Handley, M., Floyd, S., Padhye, J. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.

[10] Holbrook, H., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.

[11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.

[12] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.

[13] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.

[14] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.

[15] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control Using Multicast Round Trip Time: Extended Report", Digital Fountain Technical Report no. DF2002-07-001, September 2002, available at http://www.digitalfountain.com/technology/.

[16] Luby, M., Goyal, V., Skaria, S. and G. Horn, "Wave and Equation Based Rate Control Using Multicast Round Trip Time", Proc. ACM SIGCOMM 2002, Pittsburgh, PA, August 2002, pp. 191-214.

[17] Perrig, A., Canetti, R., Song, D. and J. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.

[18] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", Proc. IEEE Infocom '98, San Francisco, CA, March-April 1998, pp. 996-1003.

9. Authors' Addresses ✨

Okay bestie, here are the people who wrote it! 🦋 Michael Luby and Vivek K Goyal, with their addresses and emails so you can reach out if you have questions 💌

Michael Luby
Digital Fountain
39141 Civic Center Drive, Suite 300
Fremont, CA, USA, 94538

EMail: luby@digitalfountain.com


Vivek K Goyal
Massachusetts Institute of Technology
Room 36-690
77 Massachusetts Avenue
Cambridge, MA, USA, 02139

EMail: v.goyal@ieee.org

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth there, the authors keep all their rights. 🎀

This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. 🙈 Read that part carefully, it's serious!

Intellectual Property 🌈

The IETF takes no position on whether any Intellectual Property Rights, or other rights that someone might claim over the technology in this document, are valid or in scope. It also doesn't say whether any license under those rights might be available. ngl, it also hasn't tried to independently hunt for those rights either. 🧐 You can find info about how RFC rights work in BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of an attempt to get a general license or permission for implementers or users to use these proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔗

The IETF also invites anyone who's interested to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💅

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, you're the real MVP! 👑

📦 where this page comes from