diff options
Diffstat (limited to 'doc/rfc/rfc3738.txt')
-rw-r--r-- | doc/rfc/rfc3738.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc3738.txt b/doc/rfc/rfc3738.txt new file mode 100644 index 0000000..7c07f55 --- /dev/null +++ b/doc/rfc/rfc3738.txt @@ -0,0 +1,1795 @@ + + + + + + +Network Working Group M. Luby +Request for Comments: 3738 Digital Fountain +Category: Experimental V. Goyal + M.I.T. + April 2004 + + + Wave and Equation Based Rate Control (WEBRC) Building Block + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document specifies Wave and Equation Based Rate Control (WEBRC), + which provides rate and congestion control for data delivery. WEBRC + is specifically designed to support protocols using IP multicast. It + provides multiple-rate, congestion-controlled delivery to receivers, + i.e., different receivers joined to the same session may be receiving + packets at different rates depending on the bandwidths of their + individual connections to the sender and on competing traffic along + these connections. WEBRC requires no feedback from receivers to the + sender, i.e., it is a completely receiver-driven congestion control + protocol. Thus, it is designed to scale to potentially massive + numbers of receivers attached to a session from a single sender. + Furthermore, because each individual receiver adjusts to the + available bandwidth between the sender and that receiver, there is + the potential to deliver data to each individual receiver at the + fastest possible rate for that receiver, even in a highly + heterogeneous network architecture, using a single sender. + + + + + + + + + + + + + +Luby & Goyal Experimental [Page 1] + +RFC 3738 WEBRC Building Block April 2004 + + +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 + + + + + + + + + + + + +Luby & Goyal Experimental [Page 2] + +RFC 3738 WEBRC Building Block April 2004 + + +1. Introduction + + This document specifies Wave and Equation Based Rate Control (WEBRC). + WEBRC is a congestion control building block that is designed to be + massively scalable when used with the IP multicast network service. + WEBRC is also suitable as the basis for unicast congestion control, + but this is outside the scope of this document. WEBRC is designed to + compete fairly with TCP and similar congestion-controlled sessions. + WEBRC 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]. This means that all measurements and decisions to + raise or lower the reception rate are made by each individual + receiver, and these decisions are acted upon by sending join and + leave messages for channels to the network. A receiver using WEBRC + adjusts its reception rate without regard for other concerns such as + 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]. In + particular, each WEBRC receiver measures parameters that are plugged + into a TCP-like equation to compute the receiver target reception + rate and adjusts its reception rate up and down to closely + approximate the target reception rate. The sender sends packets to + multiple channels; one channel is called the base channel and the + remaining channels 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.) 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 wave channel. + + The wave channels are ordered at each point in time from a lowest + layer to a highest layer. At each point in time, the lowest layer is + the wave channel that among all active wave channels is nearest to + the end of its active period; the highest layer is the wave channel + that is furthest from the end of its active period. Because waves + are dynamically becoming active and quiescent over time, the + designation of which wave channel is at which layer changes + dynamically over time. In addition to being joined to the base + channel, at each point in time a receiver is joined to a consecutive + + + +Luby & Goyal Experimental [Page 3] + +RFC 3738 WEBRC Building Block April 2004 + + + set of layers starting at the lowest layer and proceeding towards the + highest. + + WEBRC introduces a natural notion of a multicast round-trip time + (MRTT). An MRTT is measured individually by each receiver and + averaged as a substitute for conventional unicast round-trip time + (RTT). Because the throughput of a TCP session depends strongly on + RTT, having some measure of RTT is essential in making the WEBRC + equation-based rate control protocol "TCP-friendly". The use of the + MRTT also helps to coordinate and equalize the reception rates of + proximate receivers joined to a session behind a bottleneck link. + This implies that packets for the session that flow through the + bottleneck link are on average sent to almost all downstream + receivers, and thus the efficiencies of multicast are realized. + Furthermore, WEBRC is designed to be massively scalable in the sense + that the sender is insensitive to the number of receivers 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. WEBRC + is designed to be reasonably fair when competing for bandwidth with + TCP flows, where a flow is "reasonably fair" if its reception rate is + generally within a factor of two of the reception rate of a TCP flow + under the same conditions. However WEBRC has a much lower variation + of throughput over time compared to TCP, which makes it more suitable + for applications such as telephony or streaming media where a + relatively smooth rate is of importance. The penalty of having + smoother throughput than TCP while competing fairly for bandwidth is + that WEBRC responds more slowly than TCP to changes in available + bandwidth. + + The receiver measures and performs the calculation of congestion + control parameters (e.g., the average loss probability, the average + MRTT) and makes decisions on how to increase or decrease its rate + based on these parameters. The receiver-based approach is well + suited to an application where the sender is handling many concurrent + connections and therefore WEBRC is suitable as a building block for + multicast congestion control. + + The paper [16] and technical report [15] provide much of the + rationale and intuition for the WEBRC design and describe some + preliminary simulations. + + This document describes a building block as defined in RFC 3048 [4]. + This document describes a congestion control building block that + conforms to RFC 2357 [3]. This document is a product of the IETF RMT + WG and follows the general guidelines provided in RFC 3269 [2]. The + key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + + + +Luby & Goyal Experimental [Page 4] + +RFC 3738 WEBRC Building Block April 2004 + + + "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 necessary to fully specify + a Reliable Multicast Transport protocol in accordance with RFC 2357. + As per RFC 2357, the use of any reliable multicast protocol in the + Internet requires an adequate congestion control scheme. This + document specifies an experimental congestion control scheme. While + waiting for initial deployment and experience to show this scheme to + be effective and scalable, the IETF publishes this scheme in the + "Experimental" category. + + It is the intent of the Reliable Multicast Transport (RMT) Working + Group to re-submit the specification as an IETF Proposed Standard as + soon as the scheme is deemed adequate. + +2. Rationale + + WEBRC provides congestion control for massively scalable protocols + using the IP multicast network service. The congestion control that + WEBRC provides is common to a variety of applications, including + reliable content delivery and streaming applications. + + WEBRC is designed to provide congestion control for all packets that + are sent to a session. A session comprises multiple channels + originating at a single sender that are used for some period of time + to carry packets pertaining to the transmission of one or more + objects that can be of interest to receivers. The logic behind + defining a session as originating from a single sender is that this + is the right granularity to regulate packet traffic via congestion + control. The rationale for providing congestion control that uses + multiple channels within the same session is that this allows the + data on the channels to be layered, which in turn allows each + receiver to control its reception rate by joining and leaving + channels during its participation in the session. There are + advantages to layered data for streaming, where the most important + data can be sent to the lower layers and incrementally valuable data + to the higher layers. For reliable content delivery, as described in + [13], an application can send in packets encoded data generated from + an object in such a way that the arrival of enough packets by a + receiver is sufficient to reliably reconstruct the original object. + A primary advantage of WEBRC is that each receiver controls it + reception rate independent of other receivers. Thus, for example, a + receiver with a slow connection to the sender does not slow down the + receivers with faster connections. + + + + +Luby & Goyal Experimental [Page 5] + +RFC 3738 WEBRC Building Block April 2004 + + + There are coding techniques that provide massively scalable + reliability and asynchronous delivery which are compatible with + WEBRC, e.g., as described in [11]. When combined the result is a + massively scalable, reliable, asynchronous content delivery protocol + that is network friendly. WEBRC also provides congestion control + that is suitable for streaming applications. + + WEBRC avoids using techniques that are not massively scalable. For + example, WEBRC does not provide any mechanisms for sending + information from receivers to senders, although this does not rule + out protocols that both use WEBRC and that send information from + receivers to senders. + + WEBRC provides congestion control that can be tuned for different + applications that may have differing application requirements. For + example, a content delivery protocol may aggressively strive to use + all available bandwidth between receivers and the sender, and thus to + maintain fairness it must drastically reduce its rate when there is + competing traffic. On the other hand, a streaming delivery protocol + may strive to maintain a constant rate instead of trying to use all + available bandwidth, and thus it may not reduce its rate as fast when + there is competing traffic. + + WEBRC does not provide any support beyond congestion control, and + thus WEBRC is to be combined with other building blocks to provide a + complete protocol instantiation. For example, WEBRC does not provide + any means that can be used to identify which session each received + packet belongs to. As another example, WEBRC does not provide + support for identifying which object each packet is carrying + information about. + +3. Functionality + + A WEBRC session comprises a logically related set of channels + originating from a single sender that are used for some period of + time to carry data packets with a header carrying WEBRC Congestion + Control Information. When packets are received, they are first + checked to see that they belong to the appropriate session before + WEBRC is applied. A session label defined by a protocol + instantiation may be carried in each packet to identify to which + session the packet belongs. For example, if LCT [12] is being used + with the session, then the sender IP address together with the + Transport Session Identifier supported by LCT would be used to + determine which session a received packet belongs to. The particular + details of how this filtering is performed is outside the scope of + this document. In the remainder of this document, references to + channels are always within the scope of a single session. + + + + +Luby & Goyal Experimental [Page 6] + +RFC 3738 WEBRC Building Block April 2004 + + + A channel can be uniquely identified at the network layer by a + (sender IP address, multicast group address) pair, and this is the + address to which the receiver sends messages 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 corresponds to the channel is carried in the + WEBRC Congestion Control Information. A WEBRC receiver uses the + channel number to determine which channel within a session a packet + is received from. + + At the sender, time is partitioned into time slots, each of duration + TSD seconds. There is a fixed number T of time slot indices + associated with a session. As time progresses, the current time slot + index increases by one modulo T each TSD seconds. The current time + slot index CTSI is carried in the WEBRC Congestion Control + Information. This allows receivers to perform very coarse-grained + synchronization within a session. + + WEBRC congestion control is achieved by having the sender send + packets associated with a given session to several different + channels. Individual receivers dynamically join and leave these + channels according to the network congestion they experience. These + congestion control adjustments are performed at each receiver + independently of all other receivers, without any impact on the + sender. A packet sequence number is carried in the WEBRC Congestion + Control Information. The packet sequence numbers are consecutively + numbered per channel and are used by receivers to measure packet + loss. + + The channels associated with a session consist of one base channel + and T wave channels. The packet rate for each channel varies over + time. For the base channel, packets are sent to the channel at a low + rate BCR_P at the beginning of a time slot and this rate gradually + decreases to P*BCR_P at the end of the time slot, where P < 1 is a + constant defined later. This pattern for the base channel repeats + over each time slot. For each wave channel i, packets are sent to + channel i at a rate that first increases very quickly to a high rate + and then decreases over time by a fixed fraction P per time slot + until a rate of BCR_P is reached at the end of time slot i. Then, + for a period of time called the quiescent period, no packets are sent + to wave channel i, and thereafter the whole cycle repeats itself, + where the duration of the cycle is T*TSD seconds. Thus, the wave + channels are going through the same cyclic pattern of packet rate + transmission spaced out evenly by TSD seconds. + + Before joining a session, the receivers MUST obtain enough of the + session description to start the session. This MUST include the + relevant session parameters needed by a receiver to participate in + + + +Luby & Goyal Experimental [Page 7] + +RFC 3738 WEBRC Building Block April 2004 + + + the session and perform WEBRC congestion control. The session + description is determined by the sender and is typically communicated + to the receivers out of band. How receivers obtain the session + description is outside the scope of this document. + + When a receiver initiates a session, it first joins the base channel. + The packets in the base channel help the receiver orient itself in + terms of what the current time slot index is, which in turn allows + the receiver to know the relative rates on the wave channels. The + receiver remains joined to the base channel for the duration of its + participation in the session. + + At each point in time the active (non-quiescent) wave channels are + ordered into layers, where 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 that the lowest layer has the + lowest rate and the highest layer has the highest rate. The possible + deviation from this is due to the optional non-exponential beginnings + of the waves as described in [8].) Each time a wave channel becomes + active, it is the highest layer. At the end of each time slot the + lowest-layer wave channel becomes quiescent, and thus all active wave + channels move down a layer at this point in time. At each point in + time a receiver is joined to the base channel and a consecutive set + of layers starting with the lowest. Each time a receiver joins a + wave channel it joins the lowest layer not yet joined. A receiver + always leaves the lowest layer when it becomes quiescent. + + After joining a session the receiver adjusts its rate upwards by + joining wave channels in sequence, starting with the lowest layer and + moving towards the highest. The rates on the active wave channels + are decreasing with time, so the receiver adjusts its rate downwards + simply by refraining from joining additional wave channels. Since + the layer ordering among the channels changes dynamically over time + depending on the current time slot index, it is important that the + receiver continually monitor the current time slot index contained in + received packets. The reception rate at the receiver is determined + by how early each wave channel is joined by the receiver: the earlier + the receiver joins a channel with respect to when its wave started, + the higher the reception rate. + + Once the receiver is joined to a wave channel, the receiver remains + joined to the wave channel until the channel goes quiescent, at which + point the receiver MUST leave the channel. + + The way the 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 + + + +Luby & Goyal Experimental [Page 8] + +RFC 3738 WEBRC Building Block April 2004 + + + after joining its anticipated reception rate from all the layers it + is joined to would be at most its target reception rate. The target + rate is continually updated based on a set of measured parameters. + The primary parameters 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 + + The primary input to the sender for the session is SR_b. SR_b is an + upper bound to the sender transmission rate in bits per second at any + point in time (with some reasonable granularity) in aggregate to all + channels. Naturally, this is then also the maximum rate in bits per + second that any receiver could receive data from the session at any + point in time. 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 to the sender are listed below. These inputs + are secondary because their values will generally be fixed to default + values that will not change, because they will be derived from SR_b, + or because they are chosen based on non-WEBRC considerations. + + o 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. + + o 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. + + o TSD is the time slot duration measured in seconds. The + RECOMMENDED value for TSD is 10. + + o QD is the minimum quiescent period duration measured in seconds. + The RECOMMENDED value for QD is 300. + + + +Luby & Goyal Experimental [Page 9] + +RFC 3738 WEBRC Building Block April 2004 + + + o P is the multiplicative drop in every channel rate over each time + slot. The default value for P is 0.75. + + o 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 as follows. + + o SR_P = SR_b/(8*LENP_B) is the sender transmission rate in packets + per second. + + o 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. + + o L = ceil(BCR_P*TSD*(P-1)/log(P)) is the number of base channel + packets sent in each time slot. + + o Q = ceil(QD/TSD) is the number of quiescent time slots per cycle + for a wave channel. + + o T = N + Q is the total number of time slots in a cycle. T is also + the total number of wave channels. + + o 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. + + o 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. + + + + + + +Luby & Goyal Experimental [Page 10] + +RFC 3738 WEBRC Building Block April 2004 + + + 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. + + 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]. + + + + + + + + +Luby & Goyal Experimental [Page 11] + +RFC 3738 WEBRC Building Block April 2004 + + +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 + + + +Luby & Goyal Experimental [Page 12] + +RFC 3738 WEBRC Building Block April 2004 + + + 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: + + o 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 + + The design of TFRC [9] reflects that, because the average packet loss + probability can vary by orders of magnitude, any estimate of the + average loss probability based on either a fixed number of packets or + on a fixed period of time with a fixed averaging fraction will be + poor. In TFRC the average is estimated from the numbers of packets + between beginnings of loss events, and the number of loss events used + is fixed. + + + +Luby & Goyal Experimental [Page 13] + +RFC 3738 WEBRC Building Block April 2004 + + + The estimate LOSSP of the average loss probability of the receiver is + maintained in a manner somewhat similar to that described in TFRC + [9]. The WEBRC receiver estimates the inverse of the average loss + probability by applying two EWMA filters to the packet reception + measurements, a time-based filter with smoothing constant 0 < Nu < 1 + and a loss-based filter with smoothing constant 0 < Delta < 1. The + recommended values for the smoothing constants are Nu = 0.3 and Delta + = 0.3. The reason for the time-based filter is that the loss events + in WEBRC are bursty; they typically occur just after a new wave has + been joined. To smooth out this burstiness, the time-based filter is + applied to the packet reception measurements at the end of each epoch + to smooth out the bursty loss events over a few time slot durations. + Intuitively, the time-based filter averages packet reception events + such that the events are smoothed out over an interval of time + proportional to TSD/Nu seconds. The loss-based filter, similar to + what is suggested in TFRC, is applied to the output of the time-based + filter to produce the estimate of the inverse of the average loss + probability. Intuitively, the loss-based filter averages loss events + such that each loss event is averaged in with weight Delta. + + As described later, LOSSP is initialized at the end of slow start and + occasionally reset due to 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 + the value of LOSSP is initialized or reset, the values of W, X, Y and + Z are also initialized or reset. + + Recall that TSD is the duration of a time slot. The epoch length EL + is the duration of time between decisions to adjust the reception + rate. Generally EL is much smaller than TSD, and the RECOMMENDED + values are EL = 0.5 seconds and TSD = 10 seconds. + + Define G = Nu*EL/TSD as the amount of time-based smoothing to perform + at the end of each epoch. The update rules for W, X, Y, Z, and LOSSP + are the following: + + o At the end of each epoch, adjust X, Y and Z and compute LOSSP as + follows: + + 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)) + + + +Luby & Goyal Experimental [Page 14] + +RFC 3738 WEBRC Building Block April 2004 + + + LOSSP = 1/max{Z1,Z2,1} + + o For each packet event (whether it is a received packet or a lost + packet), W = W + 1 + + o At the beginning of each loss event, update W, X, and Y as + follows: + + X = X + W + + W = 0 + + Y = Y + 1 + + The intuition behind these update rules is the following. If just + loss-filtering were used to update Z, then Z would be decreased by a + multiplicative amount 1 - Delta for each loss event and Z would be + increased by an additive amount Delta for each packet. To smooth out + loss events over more than one time slot, these adjustments are + filtered into Z over time, at the rate of a fraction G at the end of + each epoch. Thus, the variables X and Y are counts of the portions + of the packets and loss events, respectively, that have not yet been + filtered into the long-term memory Z. W is the count of packets + since the last loss event started. This explains why W is increased + by one for each packet and Y is increased by one for each loss event. + At the end of each epoch a fraction G of both X and Y are filtered + into Z according to the loss-filter rule described above, and then + the same fraction G is removed from both X and Y to account for the + fact that this portion has been filtered into Z. The LOSSP + calculation combines the short-term history (X,Y) with the long-term + history Z and also allows the arrivals since the last loss W to have + some influence. The value of Z2 is what Z1 would become were the + next packet to be lost. + + To reset the loss calculation to a value LOSSP = a, the state + variables are set as follows: + + W = 0 + + X = 0 + + Y = 0 + + Z = 1/a + + + + + + + +Luby & Goyal Experimental [Page 15] + +RFC 3738 WEBRC Building Block April 2004 + + +3.2.2.2. Average round-trip time + + The receiver maintains an average round-trip time, ARTT, as a + measurement-based filter of MRTT measurements using a smoothing + constant 0 < Alpha < 1. The RECOMMENDED value for Alpha is 0.25. + + Each time the receiver joins a channel (either the base channel upon + entering a session or wave channels continually), it makes a + measurement of the multicast round-trip time MRTT as follows. Let V + be an auxiliary variable that is used that 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 is received + from the channel the receiver records the current time FirstTime and + resets the value of JOINING to false. If it is the base channel that + has been joined, ARTT is set to FirstTime-JoinTime and V is set to + ARTT*ARTT. Otherwise, the value of MRTT is set to (FirstTime - + JoinTime) - log(1/P)/2/(1-P)/BCR_P * P^NWC. (Note that this value + can be negative.) Then, ARTT is updated as follows. Let Omega = + Alpha*ARTT*ARTT/V, and at the Kth MRTT measurement let Rho = + Omega/(1-(1-Omega)^(K+1)). (Note that as K grows Rho approaches + Omega.) Then, V is updated to (1-Rho)*V+Rho*MRTT*MRTT and ARTT is + updated to max{P*ARTT,(1-Rho)*ARTT+Rho*MRTT}. + + Usually ARTT is updated to the second term in the max, and in this + case ARTT is the EWMA of the previous value of ARTT and the new MRTT, + with a weighting on the new MRTT that as K grows is proportional to + the square of the previous ARTT divided by the previous average V of + the square of the MRTT. Thus, if there is not much variance in the + previous MRTTs relative to the square of their average then the new + MRTT will be filtered into ARTT with a high weight, whereas if there + is a lot of variance in the previous MRTTs relative to the square of + their average then the new MRTT will be filtered into ARTT with a low + weight. The intuitive rationale for this is that in general the + number of measurements needed to compute a meaningful average for a + random variable is proportional to its variance divided by the square + of its average; see, e.g., [6]. By making the weight factor depend on + previous measurements in this way, the appropriate weight to use to + average the new MRTT into the ARTT self-adjusts automatically to the + variability in the measurements. + +3.2.2.3. Rate Equation + + The receiver calculates the reception rate REQN based on the TCP + equation as follows: REQN = 1/(ARTT*sqrt{LOSSP}(0.816 + + 7.35*LOSSP*(1+32*LOSSP^2))). This equation comes from TFRC [9]. + + + + + +Luby & Goyal Experimental [Page 16] + +RFC 3738 WEBRC Building Block April 2004 + + +3.2.2.4. Epochs + + The receiver makes decisions on 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 be a small fraction of TSD, so + that decisions to join a channel can be made at a much finer + granularity than TSD. A standard setting is EL = TSD/20. Thus, with + the recommended setting of TSD = 10, it is RECOMMENDED that EL = 0.5. + +3.2.2.5. Average reception rate + + There are two averaged reception rates maintained by the receiver: + TRR_P, the true reception rate, and ARR_P, the anticipated reception + rate. These are used for different purposes and thus are calculated + quite differently. Recommended values for the filtering weights Beta + and Zeta are provided at the end of this subsection. + + In start-up mode, the true reception rate TRR_P is used to ensure + that the receiver does not increase its reception rate too quickly + above its current reception rate. In the transition from start-up + mode to normal operation and in normal operation, TRR_P is used in + setting the slow start rate. TRR_P is calculated based on the + measurement of RR_P, where RR_P is the receiver reception rate in + packets per second measured at the beginning of an epoch averaged + over the epoch that just ended. TRR_P is 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. TRR_P is + updated to (1-Zeta)*TRR_P + Zeta*RR_P at the beginning of each epoch + after RR_P is measured for the previous epoch. + + The anticipated reception rate ARR_P is the receiver's estimate of + the total instantaneous rate of the currently joined channels. It is + used to compare against the target rate to decide whether or not the + receiver should increase its reception rate by joining the next + higher unjoined layer. ARR_P is calculated based on a measurement + IRR_P and on the number of joined wave channels NWC. The ideal + reception rate IRR_P is the reception rate in packets per second + including both received and lost packets; like RR_P, it is measured + at the beginning of the epoch and averaged over the previous epoch. + ARR_P, IRR_P and NWC are updated as follows: + + o NWC is initialized to 0. + + o 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. + + + + + + +Luby & Goyal Experimental [Page 17] + +RFC 3738 WEBRC Building Block April 2004 + + + o 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. Then if ARR_P exceeds + ARR_P_max = ((1/P)^(NWC+1)-1)/((1/P)-1)*BCR_P, ARR_P is updated to + ARR_P_max. + + o 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; this adjustment is in addition to the adjustment + above.) + + o 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. In addition, the bottom layer in the previous time + slot has just gone quiescent and thus a message to leave this + layer has been sent, ARR_P is additively decreased by BCR_P and + NWC is decremented by 1. Thus, the combination of these effects + on ARR_P is that it is additively decreased by P*BCR_P. + + Consider for the moment 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 upon joining and leaving wave channels, with the + passage of epochs, and with the detection of time slot changes will + then cause ARR_P to remain an accurate estimate. In practice, Beta + MUST be positive; allowing an influence of IRR_P prevents ARR_P from + drifting away from being an accurate estimate of the total joined + rate. + + The motivation for separate estimates TRR_P and ARR_P is as follows. + ARR_P is needed for comparison with the TFRC-inspired target rate + because there is no lag before it reflects the potential rate + increase resulting from joining the next higher layer and because it + measures the total possible impact on the network since it also + includes lost packets. TRR_P is needed because it reflects the rate + of data arriving at the receiver and this is used to ensure that + there is not 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). + + + + + + + +Luby & Goyal Experimental [Page 18] + +RFC 3738 WEBRC Building Block April 2004 + + +3.2.2.6. Slow start + + WEBRC uses a slow start mechanism to quickly ramp up its rate at both + the beginning of the session and in the middle of a session when the + rate drops precipitously. To enact this, the receiver maintains the + following parameters: + + o 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). + + o SSR_P is the slow start threshold rate in packets per second. It + is 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 cannot compute a + meaningful target rate from its measurements. Thus, it uses SSR_P = + infinity until one of the following events causes an end to this + start-up mode: + + o A packet loss is detected. In this case the value of SSR_P is + updated to max{SSMINR_P, P*TRR_P} as with the beginning of any + other loss event. + + o 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. + + o 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}. + + o TRR_P is not increasing 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 the 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). + + + +Luby & Goyal Experimental [Page 19] + +RFC 3738 WEBRC Building Block April 2004 + + + In any of these four cases, the variables associated with LOSSP are + reset to make REQN, calculated as in Section 3.2.2.3 with the current + value of ARTT, equal 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 various receiver events, some of which are triggered by the + passing of time on the receiver, and others by events such as 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 require the receiver to merely register + the reception for later calculation of RR_P and IRR_P (see Section + 3.2.2.5) and increment W for later calculation of LOSSP (see Section + 3.2.2.1). + + Additional actions, described in the following three subsections, are + required if the packet is the first packet received in response to a + join operation, the CTSI of the packet indicates a time slot change, + or 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, the reception of a packet with PSN = i is a + special event because it is the first packet received in response to + the most recent join. MRTT is calculated and 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 furthermore necessitates + initialization of ARR_P and TRR_P as described in Section 3.2.2.5. + +3.2.3.3. Time slot change + + This is an event that is triggered by the reception of a packet with + a CTSI value that is one larger modulo T than the previous CTSI + value. When a packet with a new CTSI = i is received, a leave is + sent for the lowest layer in the previous time slot, i.e., wave + channel i-1 modulo T, NWC is updated to NWC-1, and ARR_P is updated + + + + + +Luby & Goyal Experimental [Page 20] + +RFC 3738 WEBRC Building Block April 2004 + + + to ARR_P - P*BCR_P as described in Section 3.2.2.5. If the channel + for which the leave is sent is also the most recently joined wave + channel and JOINING is true, then JOINING is set to false. + + It is possible due to packet reordering for some packets from the + previous time slot to be received 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 is as follows: + 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. In + addition, a very large difference, for example a difference 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), the receiver + records the start of a new loss event and sets a Boolean variable + LOSS_EVENT to true that will automatically reset to false after ARTT + seconds. All subsequent packet loss for a period of ARTT seconds is + considered as part of the same loss event. When a 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 that is triggered by the passage of time at the + receiver, which occurs each EL seconds. When this happens, TRR_P and + ARR_P are computed as described in Section 3.2.2.5. Immediately after + these updates, a decision is 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 + + At the beginning of each epoch, after updating the values of ARR_P + and TRR_P as described in Section 3.2.2.5, the receiver decides + whether or not to join the next higher layer as follows: + + o If the first base channel packet has not yet arrived the receiver + MUST not join. + + o If there is a loss event in progress (LOSS_EVENT = true) the + receiver MUST not join. + + + +Luby & Goyal Experimental [Page 21] + +RFC 3738 WEBRC Building Block April 2004 + + + o If a join of a channel is in progress (JOINING = true) the + receiver MUST not join. + + o If NWC = N the receiver MUST not join. + + o 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. + + o 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. + + o The receiver calculates REQN as described in Section 3.2.2.3. + + o The receiver calculates TRATE as described in Section 3.2.2.7. + + o 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. + + o 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. + + o Otherwise, the receiver MAY join the next higher layer. + + + + +Luby & Goyal Experimental [Page 22] + +RFC 3738 WEBRC Building Block April 2004 + + + 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 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 when the packet reception behavior is far from + what it should be and these MUST trigger the receiver to leave the + session. Exceptional timeouts include + + o No packets are received for a long period. A RECOMMENDED + threshold is max{10,TSD} seconds. + + o 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 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 + + + +Luby & Goyal Experimental [Page 23] + +RFC 3738 WEBRC Building Block April 2004 + + + 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, 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 must uniquely chose 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. + + + +Luby & Goyal Experimental [Page 24] + +RFC 3738 WEBRC Building Block April 2004 + + + 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 then 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 is 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 + + + +Luby & Goyal Experimental [Page 25] + +RFC 3738 WEBRC Building Block April 2004 + + + 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 + + The short format for the Congestion Control Information is shown in + Fig. 1. The total length of the short format is 32-bits. + + 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 + + The function of each field in the Congestion Control Information is + the following. + + Current Time Slot Index (CTSI): 8 bits + + CTSI indicates the index of the current time slot. This must + be sent in each packet within the session. The Current Time + Slot Index increases by one modulo T each TSD seconds at the + sender, where T is the number of time slots associated with the + session and TSD is the time slot duration. Note that T is also + the number of wave channels associated with the session, and + thus T MUST be at most 255. + + Channel Number (CN): 8 bits + + CN is the channel number that this packet belongs to. CN for + the base channel is T, and the CNs for the wave channels are 0 + through T-1. Thus, T+1 channels in total are used, and thus T + MUST be at most 255. + + Packet Sequence Number (PSN): 16 bits + + The PSN of each packet is scoped by its CN value. The sequence + numbers of consecutive packets sent to the base channel are + + + +Luby & Goyal Experimental [Page 26] + +RFC 3738 WEBRC Building Block April 2004 + + + numbered consecutively modulo 2^16. The same sequence of PSNs + are used for each wave channel in each cycle. The sequence + numbers of consecutive packets sent to a wave channel are + numbered consecutively modulo 2^16 within each cycle, ending + with the last packet sent to the channel before the channel + goes quiescent with PSN = 2^16-1. + +5.2. Long Format Congestion Control Information + + The long format for the Congestion Control Information is shown in + Fig. 2. The total length of the long format is 64-bits. + + 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 for the long format is the same as for the + short format, the only difference is that each field is twice as + long. + + Current Time Slot Index (CTSI): 16 bits + + CTSI indicates the index of the current time slot. This must + be sent in each packet within the session. The Current Time + Slot Index increases by one modulo T each TSD seconds at the + sender, where T is the number of time slots associated with the + session and TSD is the time slot duration. Note that T is also + the number of wave channels associated with the session, and + thus T MUST be at most 65,535. + + Channel Number (CN): 16 bits + + CN is the channel number that this packet belongs to. CN for + the base channel is T, and the CNs for the wave channels are 0 + through T-1. Thus, T+1 channels in total are used, and thus T + MUST be at most 65,535. + + Packet Sequence Number (PSN): 32 bits + + The PSN of each packet is scoped by its CN value. The sequence + numbers of consecutive packets sent to the base channel are + numbered consecutively modulo 2^32. The same sequence of PSNs + + + +Luby & Goyal Experimental [Page 27] + +RFC 3738 WEBRC Building Block April 2004 + + + are used for each wave channel in each cycle. The sequence + numbers of consecutive packets sent to a wave channel are + numbered consecutively modulo 2^32 within each cycle, ending + with the last packet sent to the channel before the channel + goes quiescent with PSN = 2^32-1. + +6. Requirements From Other Building Blocks + + As described in RFC 3048 [4], WEBRC is a building block that is + intended to be used, in conjunction with other building blocks, to + help specify a protocol instantiation. + + WEBRC does not provide higher level session support, e.g., how + receivers obtain the necessary session description and how the + receivers demultiplex received packets based on their session. There + is support provided by other building blocks that can be used in + conjunction with WEBRC to provide some of this support. For example, + LCT [12] can provide some of the higher level in-band session support + that may be needed by receivers, and the WEBRC Congestion Control + Information (CCI) required in each packet can be carried in the CCI + field of the LCT header [12]. + + WEBRC does not provide any type of reliability, and in particular + does not provide support for retransmission of loss packets. + Reliability can be added by independent means, such as by the use of + FEC codes as described in [13] and specified in the FEC building + block [14]. + +7. Security Considerations + + WEBRC can be subject to denial-of-service attacks by attackers that + try to confuse the congestion control mechanism for receivers by + injecting forged packets into the multicast stream. This attack most + adversely affects network elements and receivers downstream of the + attack, and much less significantly the rest of the network and other + receivers. Because of this and because of the potential attacks due + to the use of 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 to limit the possibility + of a bad agent injecting forged packets into the multicast tree data + path. + + It is also RECOMMENDED that packet authentication be used to + authenticate each packet immediately upon receipt before the receiver + performs any WEBRC actions based upon its receipt. Unfortunately, + there are currently no practical multicast packet authentication + schemes that offer instant packet authentication upon receipt. + However, TESLA [17] can be used to authenticate each packet a few + + + +Luby & Goyal Experimental [Page 28] + +RFC 3738 WEBRC Building Block April 2004 + + + seconds after receipt. Thus, TESLA could be used in conjunction with + WEBRC to authenticate packets and for example terminate the session + upon detection of a forged packet. However, it is RECOMMENDED that + the normal WEBRC receiver responses to received packets occur + immediately -- not delayed by the TESLA authentication process. This + is because the overall WEBRC performance would be greatly degraded if + the receiver delayed its WEBRC response to packet receipt for several + seconds. + + A receiver with an incorrect or corrupted implementation of WEBRC may + affect health of the network in the path between the sender and the + receiver, and may also affect the reception rates of other receivers + joined to the session. 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 of WEBRC is the potential of receivers + obtaining an incorrect session description for the session. The + consequences of this could be that legitimate receivers with the + wrong session description are unable to correctly receive the session + content, or that receivers inadvertently try to receive at a much + higher rate than they are capable of, thereby disrupting traffic in + portions of the network. To avoid these problems, it is RECOMMENDED + that measures be taken to prevent receivers from accepting incorrect + session descriptions, e.g., by using source authentication to ensure + that 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. + + + + + +Luby & Goyal Experimental [Page 29] + +RFC 3738 WEBRC Building Block April 2004 + + +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/. + + + + +Luby & Goyal Experimental [Page 30] + +RFC 3738 WEBRC Building Block April 2004 + + + [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 + + 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 + + + + + + + + + + + + + + + + + + + + + +Luby & Goyal Experimental [Page 31] + +RFC 3738 WEBRC Building Block April 2004 + + +10. Full Copyright Statement + + 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 therein, the authors retain all their rights. + + This document and the information contained herein 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, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Luby & Goyal Experimental [Page 32] + |