idnits 2.17.1 draft-ietf-rmt-bb-webrc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 371 has weird spacing: '...hat any recei...' == Line 699 has weird spacing: '...whereas if th...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (9 December 2002) is 7771 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1306, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 3269 (ref. '9') ** Downref: Normative reference to an Experimental draft: draft-ietf-rmt-pi-alc (ref. '10') ** Downref: Normative reference to an Experimental draft: draft-ietf-rmt-bb-lct (ref. '11') ** Downref: Normative reference to an Informational draft: draft-ietf-rmt-info-fec (ref. '12') ** Downref: Normative reference to an Experimental draft: draft-ietf-rmt-bb-fec (ref. '13') -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Downref: Normative reference to an Informational RFC: RFC 2357 (ref. '16') -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' ** Downref: Normative reference to an Informational RFC: RFC 3048 (ref. '19') Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force RMT WG 2 INTERNET-DRAFT M. Luby/Digital Fountain 3 draft-ietf-rmt-bb-webrc-04.txt V. K Goyal/Digital Fountain 4 9 December 2002 5 Expires: June 2003 7 Wave and Equation Based Rate Control building block 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as a "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 This document is a product of the IETF RMT WG. Comments should be 30 addressed to the authors, or the WG's mailing list at rmt@lbl.gov. 32 Abstract 34 Wave and Equation Based Rate Control provides rate and 35 congestion control for data delivery. Wave and Equation Based 36 Rate Control is specifically designed to support protocols 37 using IP multicast. It provides multiple-rate, congestion- 38 controlled delivery to receivers, i.e., different receivers 39 joined to the same session may be receiving packets at 40 different rates depending on the bandwidths of their 41 individual connections to the sender and on competing traffic 42 along these connections. Wave and Equation Based Rate Control 43 requires no feedback from receivers to the sender, i.e., it is 44 a completely receiver-driven congestion control protocol. 45 Thus, it is designed to scale to potentially massive numbers 46 of receivers attached to a session from a single sender. 47 Furthermore, because each individual receiver adjusts to the 48 available bandwidth between the sender and that receiver, 49 there is the potential to deliver data to each individual 50 receiver at the fastest possible rate for that receiver, even 51 in a highly heterogeneous network architecture, using a single 52 sender. 54 Table of Contents 56 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 57 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Functionality . . . . . . . . . . . . . . . . . . . . . 7 59 3.1. Sender Operation . . . . . . . . . . . . . . . . . . 9 60 3.1.1. Sender inputs and initialization. . . . . . . . . 9 61 3.1.2. Sending packets to the session. . . . . . . . . . 11 62 3.2. Receiver Operation . . . . . . . . . . . . . . . . . 12 63 3.2.1. Receiver inputs and initialization. . . . . . . . 13 64 3.2.2. Receiver measurements and calculations. . . . . . 14 65 3.2.2.1. Average loss probability . . . . . . . . . . . 14 66 3.2.2.2. Average round-trip time. . . . . . . . . . . . 16 67 3.2.2.3. Rate Equation. . . . . . . . . . . . . . . . . 17 68 3.2.2.4. Epochs . . . . . . . . . . . . . . . . . . . . 17 69 3.2.2.5. Average reception rate . . . . . . . . . . . . 17 70 3.2.2.6. Slow start . . . . . . . . . . . . . . . . . . 19 71 3.2.2.7. Target rate. . . . . . . . . . . . . . . . . . 20 72 3.2.3. Receiver events . . . . . . . . . . . . . . . . . 20 73 3.2.3.1. Packet reception . . . . . . . . . . . . . . . 21 74 3.2.3.2. First packet after join. . . . . . . . . . . . 21 75 3.2.3.3. Time slot change . . . . . . . . . . . . . . . 21 76 3.2.3.4. Loss event . . . . . . . . . . . . . . . . . . 22 77 3.2.3.5. Epoch change . . . . . . . . . . . . . . . . . 22 78 3.2.3.6. Join the next higher layer . . . . . . . . . . 22 79 3.2.3.7. Join timeout . . . . . . . . . . . . . . . . . 23 80 3.2.3.8. Exceptional timeouts . . . . . . . . . . . . . 24 81 4. Applicability Statement . . . . . . . . . . . . . . . . 24 82 4.1. Environmental Requirements and 83 Considerations. . . . . . . . . . . . . . . . . . . . . . 24 84 5. Packet Header Fields. . . . . . . . . . . . . . . . . . 26 85 5.1. Short Format Congestion Control Information. . . . . 27 86 5.2. Long Format Congestion Control Information . . . . . 28 87 6. Requirements From Other Building Blocks . . . . . . . . 29 88 7. Security Considerations . . . . . . . . . . . . . . . . 29 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . 30 90 9. Intellectual Property Issues. . . . . . . . . . . . . . 30 91 10. References . . . . . . . . . . . . . . . . . . . . . . 31 92 11. Authors' Addresses . . . . . . . . . . . . . . . . . . 32 93 12. Full Copyright Statement . . . . . . . . . . . . . . . 33 95 1. Introduction 97 This document specifies Wave and Equation Based Rate Control (WEBRC). 98 WEBRC is a congestion control building block that is designed to be 99 massively scalable when used with the IP multicast network service. 100 WEBRC is also suitable as the basis for unicast congestion control, but 101 this is outside the scope of this document. WEBRC is designed to 102 compete fairly with TCP and similar congestion-controlled sessions. 103 WEBRC can be used as a congestion control protocol for any type of data 104 delivery, including reliable content delivery and streaming delivery. 106 WEBRC is a receiver-driven congestion control protocol in the spirit of 107 [3] and [18]. This means that all measurements and decisions to raise or 108 lower the reception rate are made by each individual receiver, and these 109 decisions are acted upon by sending join and leave messages for channels 110 to the network. A receiver using WEBRC adjusts its reception rate 111 without regard for other concerns such as reliability. This is 112 different from TCP, where the congestion control protocol and the 113 reliability protocol are intricately interwoven. 115 WEBRC takes the same basic equation-based approach as TFRC [7]. In 116 particular, each WEBRC receiver measures parameters that are plugged 117 into a TCP-like equation to compute the receiver target reception rate, 118 and adjusts its reception rate up and down to closely approximate the 119 target reception rate. The sender sends packets to multiple channels; 120 one channel is called the base channel and the remaining channels are 121 called wave channels. Each wave channel follows the same pattern of 122 packet rate transmission spread out over equally spaced intervals of 123 time. The pattern of each wave is that it starts at a high rate that 124 decreases gradually and continually over a long interval of time. 125 (Picture an infinite sequence of waves.) The receiver increases its 126 reception rate by joining the next wave channel earlier in the descent 127 of the wave than it joined the previous wave channel, and the receiver 128 decreases its reception rate by joining the next wave channel later in 129 the descent of the wave than it joined the previous wave channel. 131 The wave channels are ordered at each point in time from a lowest layer 132 to a highest layer. At each point in time, the lowest layer is the wave 133 channel that has the smallest rate among all active wave channels and 134 the highest layer is the wave channel that has the highest rate. 135 Because waves are dynamically becoming active and quiescent over time, 136 the designation of which wave channel is at which layer changes 137 dynamically over time. In addition to being joined to the base channel, 138 at each point in time a receiver is joined to a consecutive set of 139 layers starting at the lowest layer and proceeding towards the highest. 141 WEBRC introduces a natural notion of a multicast round-trip time (MRTT). 142 An MRTT is measured individually by each receiver and averaged as a 143 substitute for conventional unicast round-trip time (RTT). Because the 144 throughput of a TCP session depends strongly on RTT, having some measure 145 of RTT is essential in making the WEBRC equation-based rate control 146 protocol ``TCP-friendly.'' The use of the MRTT also helps to coordinate 147 and equalize the reception rates of proximate receivers joined to a 148 session behind a bottleneck link. This implies that packets for the 149 session that flow through the bottleneck link are on average sent to 150 almost all downstream receivers, and thus the efficiencies of multicast 151 are realized. Furthermore, WEBRC is designed to be massively scalable 152 in the sense that the sender is insensitive to the number of receivers 153 joined to a multicast session. 155 WEBRC is designed for applications that use a fixed packet size and vary 156 their packet reception rates in response to congestion. WEBRC is 157 designed to be reasonably fair when competing for bandwidth with TCP 158 flows, where a flow is ``reasonably fair'' if its reception rate is 159 generally within a factor of two of the reception rate of a TCP flow 160 under the same conditions. However WEBRC has a much lower variation of 161 throughput over time compared to TCP, which makes it more suitable for 162 applications such as telephony or streaming media where a relatively 163 smooth rate is of importance. The penalty of having smoother throughput 164 than TCP while competing fairly for bandwidth is that WEBRC responds 165 more slowly than TCP to changes in available bandwidth. 167 The receiver measures and performs the calculation of congestion control 168 parameters (e.g., the average loss probability, the average MRTT) and 169 makes decisions on how to increase or decrease its rate based on these 170 parameters. The receiver-based approach is well suited to an 171 application where the sender is handling many concurrent connections and 172 therefore WEBRC is suitable as a building block for multicast congestion 173 control. 175 The paper [15] and technical report [14] provide much of the rationale 176 and intuition for the WEBRC design and describe some preliminary 177 simulations. 179 This document describes a building block as defined in RFC3048 [19]. 180 This document describes a congestion control building block that 181 conforms to RFC2357 [16]. This document is a product of the IETF RMT WG 182 and follows the general guidelines provided in RFC3269 [9]. The key 183 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 184 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are 185 to be interpreted as described in RFC2119 [2]. 187 2. Rationale 189 WEBRC provides congestion control for massively scalable protocols using 190 the IP multicast network service. The congestion control that WEBRC 191 provides is common to a variety of applications, including reliable 192 content delivery and streaming applications. 194 WEBRC is designed to provide congestion control for all packets that are 195 sent to a session. A session comprises multiple channels originating at 196 a single sender that are used for some period of time to carry packets 197 pertaining to the transmission of one or more objects that can be of 198 interest to receivers. The logic behind defining a session as 199 originating from a single sender is that this is the right granularity 200 to regulate packet traffic via congestion control. The rationale for 201 providing congestion control that uses multiple channels within the same 202 session is that this allows the data on the channels to be layered, 203 which in turn allows each receiver to control its reception rate by 204 joining and leaving channels during its participation in the session. 205 There are advantages to layered data for streaming, where the most 206 important data can be sent to the lower layers and incrementally 207 valuable data to the higher layers. For reliable content delivery, as 208 described in [12], an application can send in packets encoded data 209 generated from an object in such a way that the arrival of enough 210 packets by a receiver is sufficient to reliably reconstruct the original 211 object. A primary advantage of WEBRC is that each receiver controls it 212 reception rate independent of other receivers. Thus, for example, a 213 receiver with a slow connection to the sender does not slow down the 214 receivers with faster connections. 216 There are coding techniques that provide massively scalable reliability 217 and asynchronous delivery which are compatible with WEBRC, e.g., as 218 described in [10]. When combined the result is a massively scalable, 219 reliable, asynchronous content delivery protocol that is network 220 friendly. WEBRC also provides congestion control that is suitable for 221 streaming applications. 223 WEBRC avoids using techniques that are not massively scalable. For 224 example, WEBRC does not provide any mechanisms for sending information 225 from receivers to senders, although this does not rule out protocols 226 that both use WEBRC and that send information from receivers to senders. 228 WEBRC provides congestion control that can be tuned for different 229 applications that may have differing application requirements. For 230 example, a content delivery protocol may aggressively strive to use all 231 available bandwidth between receivers and the sender, and thus to 232 maintain fairness it must drastically reduce its rate when there is 233 competing traffic. On the other hand, a streaming delivery protocol may 234 strive to maintain a constant rate instead of trying to use all 235 available bandwidth, and thus it may not reduce its rate as fast when 236 there is competing traffic. 238 WEBRC does not provide any support beyond congestion control, and thus 239 WEBRC is to be combined with other building blocks to provide a complete 240 protocol instantiation. For example, WEBRC does not provide any means 241 that can be used to identify which session each received packet belongs 242 to. As another example, WEBRC does not provide support for identifying 243 which object each packet is carrying information about. 245 3. Functionality 247 A WEBRC session comprises a logically related set of channels 248 originating from a single sender that are used for some period of time 249 to carry data packets with a header carrying WEBRC Congestion Control 250 Information. When packets are received, they are first checked to see 251 that they belong to the appropriate session before WEBRC is applied. A 252 session label defined by a protocol instantiation may be carried in each 253 packet to identify to which session the packet belongs. For example, if 254 LCT [11] is being used with the session, then the sender IP address 255 together with the Transport Session Identifier supported by LCT would be 256 used to determine which session a received packet belongs to. The 257 particular details of how this filtering is performed it outside the 258 scope of this document. In the remainder of this document, references 259 to channels are always within the scope of a single session. 261 A channel can be uniquely identified at the network layer by a (sender 262 IP address, multicast group address) pair, and this is the address to 263 which the receiver sends messages to join and leave the channel. The 264 channels used by a WEBRC session are mapped uniquely to consecutive 265 channel numbers. In each packet sent to a channel, the channel number 266 that corresponds to the channel is carried in the WEBRC Congestion 267 Control Information. A WEBRC receiver uses the channel number to 268 determine which channel within a session a packet is received from. 270 At the sender, time is partitioned into time slots, each of duration TSD 271 seconds. There are a fixed number T of time slot indices associated 272 with a session. As time progresses, the current time slot index 273 increases by one modulo T each TSD seconds. The current time slot index 274 CTSI is carried in the WEBRC Congestion Control Information. This 275 allows receivers to perform very coarse-grained synchronization within a 276 session. 278 WEBRC congestion control is achieved by having the sender send packets 279 associated with a given session to several different channels. 280 Individual receivers dynamically join and leave these channels according 281 to the network congestion they experience. These congestion control 282 adjustments are performed at each receiver independently of all other 283 receivers, without any impact on the sender. A packet sequence number 284 is carried in the WEBRC Congestion Control Information. The packet 285 sequence numbers are consecutively numbered per channel and are used by 286 receivers to measure packet loss. 288 The channels associated with a session consist of one base channel and T 289 wave channels. The packet rate for each channel varies over time. For 290 the base channel, packets are sent to the channel at a low rate BCR_P at 291 the beginning of a time slot and this rate gradually decreases to 292 P*BCR_P at the end of the time slot, where P < 1 is a constant defined 293 later. This pattern for the base channel repeats over each time slot. 294 For each wave channel i, packets are sent to channel i at a rate that 295 first increases very quickly to a high rate and then decreases over time 296 by a fixed fraction P per time slot until a rate of BCR_P is reached at 297 the end of time slot i. Then, for a period of time called the quiescent 298 period, no packets are sent to wave channel i, and thereafter the whole 299 cycle repeats itself, where the duration of the cycle is T*TSD seconds. 300 Thus, the wave channels are going through the same cyclic pattern of 301 packet rate transmission spaced out evenly by TSD seconds. 303 Before joining a session, the receivers MUST obtain enough of the 304 session description to start the session. This MUST include the 305 relevant session parameters needed by a receiver to participate in the 306 session and perform WEBRC congestion control. The session description 307 is determined by the sender and is typically communicated to the 308 receivers out of band. How receivers obtain the session description is 309 outside the scope of this document. 311 When a receiver initiates a session, it first joins the base channel. 312 The packets in the base channel help the receiver orient itself in terms 313 of what the current time slot index is, which in turn allows the 314 receiver to know the relative rates on the wave channels. The receiver 315 remains joined to the base channel for the duration of its participation 316 in the session. 318 At each point in time the active (non-quiescent) wave channels are 319 ordered into layers, where the lowest layer is the active wave channel 320 whose wave is nearest to completion and the highest layer is the active 321 wave channel whose wave is furthest from completion. (This is almost 322 the same as saying that the lowest layer has the lowest rate and the 323 highest layer has the highest rate. The possible deviation from this is 324 due to the optional non-exponential beginnings of the waves as described 325 in [6].) Each time a wave channel becomes active, it is the highest 326 layer. At the end of each time slot the lowest layer wave channel 327 becomes quiescent, and thus all active wave channels move down a layer 328 at this point in time. At each point in time a receiver is joined to 329 the base channel and a consecutive set of layers starting with the 330 lowest. Each time a receiver joins a wave channel it joins the lowest 331 layer not yet joined. A receiver always leaves the lowest layer when it 332 becomes quiescent. 334 After joining a session the receiver adjusts its rate upwards by joining 335 wave channels in sequence, starting with the lowest layer and moving 336 towards the highest. The rates on the active wave channels are 337 decreasing with time, so the receiver adjusts its rate downwards simply 338 by refraining from joining additional wave channels. Since the layer 339 ordering among the channels changes dynamically over time depending on 340 the current time slot index, it is important that the receiver 341 continually monitor the current time slot index contained in received 342 packets. The reception rate at the receiver is determined by how early 343 each wave channel is joined by the receiver: the earlier the receiver 344 joins a channel with respect to when its wave started, the higher the 345 reception rate. 347 Once the receiver is joined to a wave channel, the receiver remains 348 joined to the wave channel until the channel goes quiescent, at which 349 point the receiver MUST leave the channel. 351 The way the receiver adjusts its reception rate is inspired by TFRC [7]. 352 The receiver at all points in time maintains a target reception rate, 353 and the receiver is allowed to join the next wave channel if after 354 joining its anticipated reception rate from all the layers it is joined 355 to would be at most its target reception rate. The target rate is 356 continually updated based on a set of measured parameters. The primary 357 parameters are an estimate LOSSP of the average loss probability and an 358 estimate ARTT of the average multicast round-trip time. 360 3.1. Sender Operation 362 The sender operation is by design much simpler than the receiver 363 operation. 365 3.1.1. Sender inputs and initialization 367 The primary input to the sender for the session is SR_b. SR_b is an 368 upper bound to the sender transmission rate in bits per second at any 369 point in time (with some reasonable granularity) in aggregate to all 370 channels. Naturally, this is then also the maximum rate in bits per 371 second that any receiver could receive data from the session at any 372 point in time. It is RECOMMENDED that the sender transmission rate in 373 aggregate to all channels be made constant as described in [6]. It is 374 also RECOMMENDED that the session description indicate whether the 375 aggregate transmission rate is constant, unless there is no ambiguity. 377 The secondary inputs to the sender are listed below. These inputs are 378 secondary because their values will generally be fixed to default values 379 that will not change, because they will be derived from SR_b, or because 380 they are chosen based on non-WEBRC considerations. 382 o LENP_B is the length of packets in bytes sent to the session. The 383 value of LENP_B depends on the complete protocol, but in general 384 this SHOULD be set to as high a value as possible without exceeding 385 the MTU size for the network that would cause fragmentation. 387 o BCR_P is the transmission rate on the base channel at the beginning 388 of a time slot in packets per second. The default value for BCR_P 389 is 1. 391 o TSD is the time slot duration measured in seconds. The RECOMMENDED 392 value for TSD is 10. 394 o QD is the minimum quiescent period duration measured in seconds. 395 The RECOMMENDED value for QD is 300. 397 o P is the multiplicative drop in every channel rate over each time 398 slot. The default value for P is 0.75. 400 o N is the duration in time slots for each wave. N is also the number 401 of wave channels active at any time. (A wave channel is called 402 active when it is not quiescent.) A sender may choose any value 403 that allows it to produce waves that substantially follow the 404 required exponential shape described in Section 3.1.2. A RECOMMENDED 405 mechanism for relating N to SR_b, BCR_P and P is described in [6]. 407 >From these inputs the following fixed sender parameters can be derived 408 as follows. 410 o SR_P = SR_b/(8*LENP_B) is the sender transmission rate in packets 411 per second. 413 o BCR_b = 8*LENP_B*BCR_P is the rate of the base channel at the 414 beginning of a time slot in bits per second. 416 o L = ceil(BCR_P*TSD*(P-1)/log(P)) is the number of base channel 417 packets sent in each time slot. 419 o Q = ceil(QD/TSD) is the number of quiescent time slots per cycle for 420 a wave channel. 422 o T = N + Q is the total number of time slots in a cycle. T is also 423 the total number of wave channels. 425 o For the base channel CN = T and for the wave channels CN = 426 0,1,...,T-1. The sender has the description of the channels 427 assigned to the session and the mapping between the channels and the 428 CNs. 430 o C = TSD*T is the total duration of a cycle in seconds. 432 3.1.2. Sending packets to the session 434 The sender keeps track of the current time slot index CTSI. The value 435 of CTSI is incremented by 1 modulo T each TSD seconds. The value of 436 CTSI is placed into each packet in the format described in Section 5. 437 For each packet sent to the session, the sender also places the channel 438 number CN of the channel into the packets in the format described in 439 Section 5. Recall that CN = T for the base channel and CN = 0,1,...,T-1 440 for the wave channels. 442 For each packet sent to the session, the sender calculates a packet 443 sequence number PSN and places it into the packet. The value of PSN is 444 scoped by CN, and the value of PSN is consecutively increasing within 445 each channel. Furthermore, for each wave channel, the last packet sent 446 before the channel becomes quiescent must have the maximum possible PSN 447 value. When the short format for Congestion Control Information is used 448 (see Section 5.1), this implies that for any wave channel the last PSN 449 value sent to the channel just before the channel becomes quiescent is 450 2^16-1 = 65 535. Similarly, when the long format for Congestion Control 451 Information is used (see Section 5.2), the PSN for the final packet of 452 any wave is 2^32-1 = 4 294 967 295. The PSN of the initial packet of a 453 wave thus depends on TSD, P, BCR_P and SR_P. For the base channel, the 454 first packet of each time slot has a PSN congruent to zero modulo L. 455 Hence, instead of 2^16 - 1 or 2^32 - 1 being the highest PSN used 456 (depending on the choice of short format or long format Congestion 457 Control Information), the highest PSN is one less than the largest 458 multiple of L that does not exceed 2^16 (short format) or 2^32 (long 459 format). The format for the PSN within packets is described in Section 460 5. 462 The rate at which packets are sent to the base channel starts at BCR_P 463 packets per second at the beginning of each time slot and decreases 464 exponentially to P*BCR_P at the end of that time slot. 466 The packet rate for the wave channels is more complicated. Each wave 467 channel carries a sequence of waves separated by quiescent periods. On 468 each wave channel each wave is active during N time slots followed by a 469 quiescent period of Q time slots. The waves on wave channel i end at 470 the ends of time slots with CTSI i. Therefore wave channel i is active 471 during time slots i-N+1 modulo T, i-N+2 modulo T, ..., i and is 472 quiescent for time slots i+1 modulo T, i+2 modulo T, ..., i+Q modulo T. 473 Wave channel i first becomes active within time slot i-N+1 modulo T at a 474 point in time that may depend on the value of SR_b. 476 For a substantial fraction of the duration of a wave ending at the end 477 of a wave, the packet rate MUST decrease exponentially by a factor of P 478 per TSD seconds, with a rate of BCR_P at the end of the last active time 479 slot. At the beginning of each wave, the rate MAY deviate from this 480 exponential form so that the total sending rate in aggregate to all of 481 the channels is constant. A RECOMMENDED design for the beginnings of 482 waves to achieve this goal is described in [6]. 484 3.2. Receiver Operation 486 The bulk of the complexity in WEBRC is in the receiver operation. For 487 ease of explanation, suppose for the moment that during the reception 488 there is no packet loss and packets are arriving at exactly the rate at 489 which they were sent. The sender transmission rate to the channels is 490 designed so that the receiver reception rate behaves as follows. 492 Upon entering a session, the receiver immediately joins the base 493 channel. When the receiver wants to increase its rate, it joins 494 consecutive layers starting with the lowest and moving towards the 495 highest. (Recall that the designations of lowest to highest change as 496 waves become active and quiescent.) When the receiver wants to maintain 497 its current reception rate and it is already joined to the lowest NWC 498 layers, if the receiver joins channel i-1+NWC modulo T sometime during 499 time slot i then the receiver joins channel i+NWC modulo T TSD seconds 500 later in time slot i+1. When the lowest layer becomes quiescent the 501 receiver leaves the channel. 503 Suppose the receiver wants to decrease its rate till it is joined to 504 just the base channel. Assume that a receiver is joined to the lowest 505 NWC < N-2 layers at the beginning of time slot i, i.e., wave channels i, 506 i+1 modulo T,..., i+NWC-1 modulo T. Then, the aggregate packet 507 reception rate of the receiver over the next NWC time slots will behave 508 as follows if the receiver does not join any wave channels during this 509 time. At the beginning of time slot i the receiver reception rate is 510 BCR_P*(1 + (1/P) + (1/P)^2 + ... + (1/P)^NWC). Then the receiver 511 reception rate decreases by a factor of P over the duration of each time 512 slot, and at the end of each time slot the reception rate decreases by 513 an additive amount of P*BCR_P. At the end of time slot i+NWC-1 mod T, 514 the receiver reception rate is BCR_P*(1+P), and at the beginning of time 515 slot i+NWC mod T the receiver is joined only to the base channel and its 516 reception rate is BCR_P. 518 3.2.1. Receiver inputs and initialization 520 Before joining a session the receiver MUST know the mapping between the 521 CNs and the channels. Upon joining the session or shortly thereafter, 522 it SHOULD have the values of LENP_B, BCR_P, TSD, P, N, L, Q and T. Some 523 of these values may be computed or measured once the receiver has joined 524 the session. For example, the receiver MAY obtain LENP_B and T from the 525 first packet received from the base channel, and the receiver MAY 526 measure BCR_P once it is joined to the base channel. The values of P, Q 527 and TSD MAY be fixed to default values built into the receiver that do 528 not change from session to session, and the value of N MAY be computed 529 as T-Q. The receiver SHOULD know whether the sender is employing a 530 technique to produce constant aggregate rate as described in [6]. 532 When a receiver first joins a session, it MUST first join just the base 533 channel and start receiving packets to determine the current time slot 534 index. If during the course of the session the receiver continually 535 loses a high fraction of the packets from the base channel even when the 536 receiver is only joined to the base channel, the receiver SHOULD leave 537 the session. 539 The receiver MAY also have other individually set parameters that may be 540 used to determine its behavior. One such parameter is MRR_b: 542 o MRR_b is the maximum receiver reception rate in bits per second. 543 This may be used to determine the maximum reception rate this 544 receiver is willing to reach. Thus, the maximum reception rate that 545 the receiver can possibly achieve in the session is the minimum of 546 SR_b and MRR_b. A recommended value of MRR_b for a receiver is the 547 bandwidth capacity of the last link to the receiver. MRR_P is the 548 maximum receiver reception rate in packets per second, i.e., MRR_P = 549 MRR_b/(8*LENP_B). 551 3.2.2. Receiver measurements and calculations 553 As outlined in the introduction, the way a receiver adjusts its 554 reception rate is inspired by TFRC [7]. The receiver at all points in 555 time maintains a target reception rate, and the receiver is allowed to 556 join the next wave channel if joining would increase its reception rate 557 to at most its target reception rate. The target rate is continually 558 updated based on a set of measured parameters. 560 Two primary parameters are the estimate LOSSP of the average loss 561 probability and the estimate ARTT of the average MRTT. Both LOSSP and 562 ARTT are moving averages of measurements based on discrete events. For 563 many of the other estimates calculated by WEBRC, using an exponentially 564 weighted moving average (EWMA) with a fixed averaging fraction is 565 sufficient. However, the calculations of LOSSP and ARTT require a more 566 general and sophisticated filtering approach. 568 3.2.2.1. Average loss probability 570 The design of TFRC [7] reflects that, because the average packet loss 571 probability can vary by orders of magnitude, any estimate of the average 572 loss probability based on either a fixed number of packets or on a fixed 573 period of time with a fixed averaging fraction will be poor. In TFRC 574 the average is estimated from the numbers of packets between beginnings 575 of loss events, and the number of loss events used is fixed. 577 The estimate LOSSP of the average loss probability of the receiver is 578 maintained in a manner somewhat similar to that described in TFRC [7]. 579 The WEBRC receiver estimates the inverse of the average loss probability 580 by applying two EWMA filters to the packet reception measurements, a 581 time-based filter with smoothing constant 0 < Nu < 1 and a loss-based 582 filter with smoothing constant 0 < Delta < 1. The recommended values 583 for the smoothing constants are Nu = 0.3 and Delta = 0.3. The reason 584 for the time-based filter is that the loss events in WEBRC are bursty; 585 they typically occur just after a new wave has been joined. To smooth 586 out this burstiness, the time-based filter is applied to the packet 587 reception measurements at the end of each epoch to smooth out the bursty 588 loss events over a few time slot durations. Intuitively, the time-based 589 filter averages packet reception events such that the events are 590 smoothed out over an interval of time proportional to TSD/Nu seconds. 591 The loss-based filter, similar to what is suggested in TFRC, is applied 592 to the output of the time-based filter to produce the estimate of the 593 inverse of the average loss probability. Intuitively, the loss-based 594 filter averages loss events such that each loss event is averaged in 595 with weight Delta. 597 As described later, LOSSP is initialized at the end of slow start and 598 occasionally reset due to other events. Let W and X be counts of 599 packets, let Y be a count of loss events and let Z be the long-term 600 estimate of the inverse of the average loss probability. Whenever the 601 value of LOSSP is initialized or reset, the values of W, X, Y and Z are 602 also initialized or reset. 604 Recall that TSD is the duration of a time slot. The epoch length EL is 605 the duration of time between decisions to adjust the reception rate. 606 Generally EL is much smaller than TSD, and the RECOMMENDED values are EL 607 = 0.5 seconds and TSD = 10 seconds. 609 Define G = Nu*EL/TSD as the amount of time-based smoothing to perform at 610 the end of each epoch. The update rules for W, Y, Z and LOSSP are the 611 following: 613 o At the end of each epoch, adjust X, Y and Z and compute LOSSP as 614 follows: 616 Z = Z*(1-Delta)^(G*Y) + X/(Y+1)*(1-(1-Delta)^(Y+1)) 618 X = X*(1-G) 620 Y = Y*(1-G) 622 Z1 = Z*(1-Delta)^Y + X/(Y+1)*(1-(1-Delta)^(Y+1)) 624 Z2 = Z*(1-Delta)^(Y+1) + (X+W+1)/(Y+2)*(1-(1-Delta)^(Y+2)) 626 LOSSP = 1/max{Z1,Z2,1} 628 o For each packet event (whether it is a received packet or a lost 629 packet), W = W + 1 631 o At the beginning of each loss event, update X, Y and Z as follows: 633 X = X + W 635 W = 0 637 Y = Y + 1 639 The intuition behind these update rules is the following. If just loss- 640 filtering were used to update Z, then Z would be decreased by a 641 multiplicative amount 1 - Delta for each loss event and Z would be 642 increased by an additive amount Delta for each packet. To smooth out 643 loss events over more than one time slot, these adjustments are filtered 644 into Z over time, at the rate of a fraction G at the end of each epoch. 645 Thus, the variables X and Y are counts of the portions of the packets 646 and loss events, respectively, that have not yet been filtered into the 647 long-term memory Z. W is the count of packets since the last loss event 648 started. This explains why W is increased by one for each packet and Y 649 is increased by one for each loss event. At the end of each epoch a 650 fraction G of both X and Y are filtered into Z according to the loss- 651 filter rule described above, and then the same fraction G is removed 652 from both X and Y to account for the fact that this portion has been 653 filtered into Z. The LOSSP calculation combines the short-term history 654 (X,Y) with the long-term history Z and also allows the arrivals since 655 the last loss W to have some influence. The value of Z2 is what Z1 656 would become were the next packet to be lost. 658 To reset the loss calculation to a value LOSSP = a, the state variables 659 are set as follows: 661 W = 0 663 X = 0 665 Y = 0 667 Z = 1/a 669 3.2.2.2. Average round-trip time 671 The receiver maintains an average round-trip time, ARTT, as a 672 measurement-based filter of MRTT measurements using a smoothing constant 673 0 < Alpha < 1. The RECOMMENDED value for Alpha is 0.25. 675 Each time the receiver joins a channel (either the base channel upon 676 entering a session or wave channels continually), it makes a measurement 677 of the multicast round-trip time MRTT as follows. Let V be an auxiliary 678 variable that is used that keep track of the average of the square of 679 the MRTT measurements. When the receiver sends the join for the channel 680 it records the current time JoinTime and sets a Boolean variable JOINING 681 to true. When the first packet is received from the channel the 682 receiver records the current time FirstTime and resets the value of 683 JOINING to false. If it is the base channel that has been joined, ARTT 684 is set to FirstTime-JoinTime and V is set to ARTT*ARTT. Otherwise, the 685 value of MRTT is set to (FirstTime - JoinTime) - log(1/P)/2/(1-P)/BCR_P 686 * P^NWC. (Note that this value can be negative.) Then, ARTT is updated 687 as follows. Let Omega = Alpha*ARTT*ARTT/V, and at the Kth MRTT 688 measurement let Rho = Omega/(Omega+(1-Omega)*(1-(1-Omega)^K)). (Note 689 that as K grows Rho approaches Omega.) Then, V is updated to 690 (1-Rho)*V+Rho*MRTT*MRTT and ARTT is updated to 691 max{P*ARTT,(1-Rho)*ARTT+Rho*MRTT}. 693 Usually ARTT is updated to the second term in the max, and in this case 694 ARTT is the EWMA of the previous value of ARTT and the new MRTT, with a 695 weighting on the new MRTT that as K grows is proportional to the square 696 of the previous ARTT divided by the previous average V of the square of 697 the MRTT. Thus, if there is not much variance in the previous MRTTs 698 relative to the square of their average then the new MRTT will be 699 filtered into ARTT with a high weight, whereas if there is a lot of 700 variance in the previous MRTTs relative to the square of their average 701 then the new MRTT will be filtered into ARTT with a low weight. The 702 intuitive rationale for this is that in general the number of 703 measurements needed to compute a meaningful average for a random 704 variable is proportional to its variance divided by the square of its 705 average; see, e.g., [4]. By making the weight factor depend on previous 706 measurements in this way, the appropriate weight to use to average the 707 new MRTT into the ARTT self-adjusts automatically to the variability in 708 the measurements. 710 3.2.2.3. Rate Equation 712 The receiver calculates the reception rate REQN based on the TCP 713 equation as follows: REQN = 1/(ARTT*sqrt{LOSSP}(0.816 + 714 7.35*LOSSP*(1+32*LOSSP^2))). This equation comes from TFRC [7]. 716 3.2.2.4. Epochs 718 The receiver makes decisions on whether or not to join another wave 719 channel at equally spaced units of time called epochs. The duration of 720 an epoch in seconds, EL, is set to be a small fraction of TSD, so that 721 decisions to join a channel can be made at a much finer granularity than 722 TSD. A standard setting is EL = TSD/20. Thus, with the recommended 723 setting of TSD = 10, it is RECOMMENDED that EL = 0.5. 725 3.2.2.5. Average reception rate 727 There are two averaged reception rates maintained by the receiver: 728 TRR_P, the true reception rate, and ARR_P, the anticipated reception 729 rate. These are used for different purposes and thus are calculated 730 quite differently. Recommended values for the filtering weights Beta 731 and Zeta are provided at the end of this subsection. 733 In start-up mode, the true reception rate TRR_P is used to ensure that 734 the receiver does not increase its reception rate too quickly above its 735 current reception rate. In the transition from start-up mode to normal 736 operation and in normal operation, TRR_P is used in setting the slow 737 start rate. TRR_P is calculated based on the measurement of RR_P, where 738 RR_P is the receiver reception rate in packets per second measured at 739 the beginning of an epoch averaged over the epoch that just ended. 740 TRR_P is initialized to BCR_P + k*log(P)/TSD when the first base channel 741 packet of the session arrives, where k is the PSN of the packet reduced 742 modulo L. TRR_P is updated to (1-Zeta)*TRR_P + Zeta*RR_P at the 743 beginning of each epoch after RR_P is measured for the previous epoch. 745 The anticipated reception rate ARR_P is the receiver's estimate of the 746 total instantaneous rate of the currently joined channels. It is used 747 to compare against the target rate to decide whether or not the receiver 748 should increase its reception rate by joining the next higher unjoined 749 layer. ARR_P is calculated based on a measurement IRR_P and on the 750 number of joined wave channels NWC. The ideal reception rate IRR_P is 751 the reception rate in packets per second including both received and 752 lost packets; like RR_P, it is measured at the beginning of the epoch 753 and averaged over the previous epoch. ARR_P, IRR_P and NWC are updated 754 as follows: 756 o NWC is initialized to 0. 758 o When the first base channel packet arrives, ARR_P is set to BCR_P + 759 k*log(P)/TSD, where k is the PSN of the packet reduced modulo L. 761 o At the beginning of each epoch, IRR_P is measured over the previous 762 epoch and then ARR_P is updated to P^(EL/TSD)*(1-Beta)*ARR_P + 763 Beta*IRR_P. 765 o When a join is made to the next higher unjoined layer, NWC is 766 updated to NWC+1 and then ARR_P is multiplicatively increased by the 767 factor ((1/P)^(NWC+1)-1)/((1/P)^NWC-1). (Joins happen at epoch 768 boundaries; this adjustment is in addition to the adjustment above.) 770 o Each time a next time slot index is detected, ARR_P is additively 771 increased by (1-P)*BCR_P to account for the change in rate on the 772 base channel. In addition, the bottom layer in the previous time 773 slot has just gone quiescent and thus a message to leave this layer 774 has been sent, ARR_P is additively decreased by BCR_P and NWC is 775 decremented by 1. 777 Consider for the moment what happens if Beta = 0 and ARR_P is an 778 accurate estimate of the total rate of the joined channels. The 779 adjustments to ARR_P upon joining and leaving wave channels, with the 780 passage of epochs, and with the detection of time slot changes will then 781 cause ARR_P to remain an accurate estimate. In practice, Beta MUST be 782 positive; allowing an influence of IRR_P prevents ARR_P from drifting 783 away from being an accurate estimate of the total joined rate. 785 The motivation for separate estimates TRR_P and ARR_P is as follows. 786 ARR_P is needed for comparison with the TFRC-inspired target rate 787 because there is no lag before it reflects the potential rate increase 788 resulting from joining the next higher layer and because it measures the 789 total possible impact on the network since it also includes lost 790 packets. TRR_P is needed because it reflects the rate of data arriving 791 at the receiver and this is used to ensure that there is not a large gap 792 between the joined rate and the receiving rate. 794 The recommended values for Beta and Zeta depend on whether the receiver 795 is in start-up mode (SSR_P = infinity). In start-up mode, it is 796 RECOMMENDED that Beta = (1 - P^(0.25))/2 and Zeta = sqrt(P)/(1 + 797 sqrt(P)). In normal operation, it is RECOMMENDED that Beta = 1 - 798 (P/(1+P))^(EL/TSD) and Zeta = 2*EL/(4+TSD). 800 3.2.2.6. Slow start 802 WEBRC uses a slow start mechanism to quickly ramp up its rate at both 803 the beginning of the session and in the middle of a session when the 804 rate drops precipitously. To enact this, the receiver maintains the 805 following parameters: 807 o SSMINR_P is the minimum allowed slow start threshold rate in packets 808 per second. The recommended value for SSMINR_P is 809 BCR_P*(1+1/P+1/P^2). 811 o SSR_P is the slow start threshold rate in packets per second. It is 812 adjusted at the beginning of loss events as described in Section 813 3.2.3.4. SSR_P is initialized to infinity and is first set to a 814 finite value when the receiver leaves the initial start-up period as 815 described below. 817 At the beginning of a session, the receiver cannot compute a meaningful 818 target rate from its measurements. Thus, it uses SSR_P = infinity until 819 one of the following events causes an end to this start-up mode: 821 o A packet loss is detected. In this case the value of SSR_P is 822 updated to max{SSMINR_P, P*TRR_P} as with the beginning of any other 823 loss event. 825 o A sharp increase in MRTT is detected. While SSR_P = infinity the 826 receiver MUST compute, in the notation of Section 3.2.2.2, 827 differences in successive measurements of (FirstTime-JoinTime) from 828 successive waves and MUST set SSR_P to max{SSMINR_P, P*TRR_P} when a 829 large increase in (FirstTime-JoinTime) is observed. It is 830 RECOMMENDED that an increase in (FirstTime-JoinTime) be considered 831 large if it exceeds (1-P^(NWC+1))/(P*log(P)) / ARR_P. 833 o The maximum reception rate is reached. When SSR_P = infinity, if 834 (P^(-NWC-2)-1)/(P^(-NWC-1)-1)*ARR_P exceeds MRR_P or SR_P, the 835 receiver MUST set SSR_P to max{SSMINR_P, TRR_P}. 837 o TRR_P is not increasing consistent with the last join of a wave 838 channel. While SSR_P = infinity, it is RECOMMENDED that the 839 receiver wait at least one full epoch after the first packet of a 840 wave is received before joining the next wave. If the TRR_P after 841 that full epoch is greatly below ARR_P the receiver SHOULD NOT join 842 and SHOULD then set SSR_P to max{SSMINR_P, TRR_P}. It is 843 RECOMMENDED that TRR_P be considered greatly below ARR_P if TRR_P < 844 c * ARR_P - 2/EL, where c = Zeta + (1-Zeta)*(P^(-EL/TSD))*(Zeta + 845 (1-Zeta)*sqrt(P)*(P^(-EL/TSD)))/g with g = 846 (P^(-NWC-1)-1)/(P^(-NWC)-1). 848 In any of these four cases, the variables associated with LOSSP are 849 reset to make REQN, calculated as in Section 3.2.2.3 with the current 850 value of ARTT, equal TRR_P. 852 3.2.2.7. Target rate 854 In typical operation, SSR_P has a finite value and the target rate TRATE 855 is computed as TRATE = min{max{SSR_P, REQN}, MRR_P}. When SSR_P = 856 infinity, TRATE is computed as TRATE = min{4*TRR_P, MRR_P}. 858 3.2.3. Receiver events 860 There are various receiver events, some of which are triggered by the 861 passing of time on the receiver, and others by events such as packet 862 reception, detection of packet loss, reception of a first packet from a 863 channel, and exceptional time-outs. 865 3.2.3.1. Packet reception 867 Most packet reception events require the receiver to merely register the 868 reception for later calculation of RR_P and IRR_P (see Section 3.2.2.5) 869 and increment W for later calculation of LOSSP (see Section 3.2.2.1). 871 Additional actions, described in the following three subsections, are 872 required if the packet is the first packet received in response to a 873 join operation, the CTSI of the packet indicates a time slot change, or 874 the CN and PSN of the packet indicate a packet loss. 876 3.2.3.2. First packet after join 878 When channel i is the most recently joined channel and the Boolean 879 variable JOINING is true, the reception of a packet with PSN = i is a 880 special event because it is the first packet received in response to the 881 most recent join. MRTT is calculated and ARTT and V are updated as 882 described in Section 3.2.2.2, and JOINING is set to false. The first 883 received packet of the session furthermore necessitates initialization 884 of ARR_P and TRR_P as described in Section 3.2.2.5. 886 3.2.3.3. Time slot change 888 This is an event that is triggered by the reception of a packet with a 889 CTSI value that is one larger modulo T than the previous CTSI value. 890 When a packet with a new CTSI = i is received, a leave is sent for the 891 lowest layer in the previous time slot, i.e., wave channel i-1 modulo T, 892 NWC is updated to NWC-1, and ARR_P is updated to ARR_P - P*BCR_P as 893 described in Section 3.2.2.5. If the channel for which the leave is sent 894 is also the most recently joined wave channel and JOINING is true, then 895 JOINING is set to false. 897 It is possible due to packet reordering for some packets from the 898 previous time slot to be received after packets from the current time 899 slot. It is RECOMMENDED that measures be put into place to handle this 900 situation appropriately, i.e., to not trigger a time slot change in this 901 situation. One simple mechanism for this is as follows: Compute the 902 difference i-j modulo T, where i is the CTSI of the received packet and 903 j is the current CTSI of the receiver. A difference of zero is, of 904 course, not a time slot change. In addition, a very large difference, 905 for example a difference larger than T-Q/2, should also not trigger a 906 time slot change. 908 3.2.3.4. Loss event 910 Each time the receiver detects a lost packet (based on the sequence 911 numbers in the packets scoped by the channel number), the receiver 912 records the start of a new loss event, and sets a Boolean variable 913 LOSS_EVENT to true that will automatically reset to false after ARTT 914 seconds. All subsequent packet loss for a period of ARTT seconds is 915 considered as part of the same loss event. When a start of a loss event 916 is detected, the value of SSR_P is updated to max{SSMINR_P, P*TRR_P}. 918 It is RECOMMENDED that the receiver account for simple misordering of 919 packets without inferring a loss. 921 3.2.3.5. Epoch change 923 This is an event that is triggered by the passage of time at the 924 receiver, which occurs each EL seconds. When this happens, TRR_P and 925 ARR_P are computed as described in Section 3.2.2.5. Immediately after 926 these updates, a decision is made about whether to join the next higher 927 layer as described in Section 3.2.3.6. 929 3.2.3.6. Join the next higher layer 931 At the beginning of each epoch, after updating the values of ARR_P and 932 TRR_P as described in Section 3.2.2.5, the receiver decides whether or 933 not to join the next higher layer as follows: 935 o If the first base channel packet has not yet arrived the receiver 936 does not join. 938 o If there is a loss event in progress (LOSS_EVENT = true) the 939 receiver does not join. 941 o If a join of a channel is in progress (JOINING = true), the receiver 942 does not join. 944 o If NWC = N the receiver does not join. 946 o If the receiver is employing the OPTIONAL rule described in Section 947 3.2.2.6, SSR_P = infinity, and a full epoch has not passed since the 948 first packet arrival on the most recently joined wave channel then 949 the receiver does not join. 951 o If the receiver is employing the OPTIONAL rule described in Section 952 3.2.2.6, SSR_P = infinity, and a full epoch has passed since the 953 first packet arrival on the most recently joined wave channel, then 954 the receiver checks if TRR_P is greatly below ARR_P as described in 955 Section 3.2.2.6. If TRR_P is greatly below ARR_P the receiver does 956 not join. 958 o The receiver calculates REQN as described in Section 3.2.2.3. 960 o The receiver calculates TRATE as described in Section 3.2.2.7. 962 o If the sender is not sending at constant aggregate rate and TRATE < 963 ARR_P*((1/P)^{NWC+2}-1)/((1/P)^{NWC+1}-1), the receiver does not 964 join. If the sender is sending at constant aggregate rate and 965 neither TRATE >= ARR_P*((1/P)^{NWC+2}-1)/((1/P)^{NWC+1}-1) nor TRATE 966 >= SR_P is true, the receiver does not join. 968 o If the sender is producing constant aggregate rate and TRATE >= 969 SR_P, the receiver joins the next wave channel. Otherwise if SSR_P 970 is finite the receiver MAY apply one additional OPTIONAL check 971 before deciding to join. 973 It is RECOMMENDED that the receiver not join if the value of RR_P is 974 not sufficiently lower than the maximum value of RR_P observed since 975 the last join. It is RECOMMENDED that RR_P is sufficiently low to 976 allow a join if RR_P <= max{RRmax-2/EL,P*RRmax}, where RRmax is the 977 maximum measured RR_P since the last join. 979 If the receiver does not join because RR_P is not sufficiently small 980 then a value of LOSSP is calculated so as to make the value of the 981 REQN equation given in Section 3.2.2.3 evaluate to 982 ARR_P*((1/P)^(NWC+2)-1)/((1/P)^(NWC+1)-1) with respect to the 983 current value of ARR_P. Then, the variables associated with LOSSP 984 are reset based on this calculated value of LOSSP as described at 985 the end of Section 3.2.2.1. 987 Suppose the receiver has decided to join and CTSI = i. The receiver 988 joins the next higher wave channel, i.e., the wave channel with CN = 989 i+NWC modulo T, increments NWC by 1, and then updates ARR to 990 ARR_P*((1/P)^{NWC+1}-1)/((1/P)^NWC-1) as described in Section 3.2.2.5. 991 The time of the join is recorded for use in updating ARTT as described 992 in Section 3.2.2.2. 994 3.2.3.7. Join timeout 996 When no packet arrives in response to the join of channel for a long 997 period of time, the join times out. The receiver sets JOINING to false, 998 updates ARR to ARR_P*((1/P)^NWC-1)/((1/P)^{NWC+1}-1), and then 999 decrements NWC by 1. 1001 The RECOMMENDED threshold for a join timeout is max{2*V/ARTT,10*ARTT} 1002 seconds. 1004 3.2.3.8. Exceptional timeouts 1006 These are timeouts when the packet reception behavior is far from what 1007 it should be and these MUST trigger the receiver to leave the session. 1008 Exceptional timeouts include 1010 o No packets are received for a long period. A RECOMMENDED threshold 1011 is max{10,TSD} seconds. 1013 o There is no change in time slot index for a long period. A 1014 RECOMMENDED threshold is max{20,2*TSD} seconds. 1016 4. Applicability Statement 1018 WEBRC is intended to be a congestion control scheme that can be used in 1019 a complete protocol instantiation that delivers objects and streams 1020 (both reliable content delivery and streaming of multimedia 1021 information). WEBRC is most applicable for delivery of objects or 1022 streams of substantial length, i.e., objects or streams that range in 1023 length from hundreds of kilobytes to many gigabytes, and whose transfer 1024 time is on the order of tens of seconds or more. 1026 4.1. Environmental Requirements and Considerations 1028 WEBRC can be used with both multicast and unicast networks. However, 1029 the scope of this document is limited to multicast. WEBRC requires 1030 connectivity between a sender and receivers, but does not require 1031 connectivity from receivers to the sender. 1033 WEBRC inherently works with all types of networks, including LANs, WANs, 1034 Intranets, the Internet, asymmetric networks, wireless networks, and 1035 satellite networks. Thus, the inherent raw scalability of WEBRC is 1036 unlimited. However, in some network environments varying reception 1037 rates to receivers may not be advantageous. For example, the network 1038 may have a dedicated fixed amount of bandwidth allocated to the session 1039 and there may be no effective way for receivers to dynamically vary the 1040 set of channels they are joined to, e.g., in a satellite network. 1042 Receivers join and leave channels using the appropriate multicast join 1043 and leave messages. For IPv4 multicast, IGMP messages are used by 1044 receivers to join and leave channels. For IPv6, MLDv2 messages are used 1045 by receivers to join and leave channels. This is the only dependency of 1046 WEBRC on the IP version. 1048 WEBRC requires receivers to be able to uniquely identify and demultiplex 1049 packets associated with a session in order to effectively perform 1050 congestion control over all packets associated with the session. How 1051 receivers achieve this is outside the scope of this document. 1053 WEBRC is presumed to be used with an underlying network or transport 1054 service that is a ``best effort'' service that does not guarantee packet 1055 reception, packet reception order, and which does not have any support 1056 for flow or congestion control. For example, the Any-Source Multicast 1057 (ASM) model of IP multicast as defined in RFC1112 [5] is such a best 1058 effort network service. While the basic service provided by RFC1112 is 1059 largely scalable, providing congestion control or reliability should be 1060 done carefully to avoid severe scalability limitations, especially in 1061 the presence of heterogeneous sets of receivers. 1063 There are currently two models of multicast delivery, the Any-Source 1064 Multicast (ASM) model as defined in RFC1112 [5] and the Source-Specific 1065 Multicast (SSM) model as defined in [8]. WEBRC works with both multicast 1066 models, but in a slightly different way with somewhat different 1067 environmental concerns. When using ASM, a sender S sends packets to a 1068 multicast group G, and the WEBRC channel address consists of the pair 1069 (S,G), where S is the IP address of the sender and G is a multicast 1070 group address. When using SSM, a sender S sends packets to an SSM 1071 channel (S,G), and the WEBRC channel address coincides with the SSM 1072 channel address. 1074 A sender can locally allocate unique SSM channel addresses, and this 1075 makes allocation of channel addresses easy with SSM. To allocate 1076 channel addresses using ASM, the sender must uniquely chose the ASM 1077 multicast group address across the scope of the group, and this makes 1078 allocation of WEBRC channel addresses more difficult with ASM. This is 1079 an issue for WEBRC because several channels are used per session. 1081 WEBRC channels and SSM channels coincide, and thus the receiver will 1082 only receive packets sent to the requested WEBRC channel. With ASM, the 1083 receiver joins a channel by joining a multicast group G, and all packets 1084 sent to G, regardless of the sender, may be received by the receiver. 1085 Thus, SSM has compelling security advantages over ASM for prevention of 1086 denial of service attacks. In either case, receivers SHOULD use 1087 mechanisms to filter out packets from unwanted sources. 1089 WEBRC assumes that the packet route between the sender and a particular 1090 receiver is the same for all channels associated with a session. For 1091 SSM this assumption is true because the multicast tree is a shortest 1092 path tree from each receiver to the sender and generally this path 1093 changes infrequently. For ASM there are some issues that if not 1094 properly considered may invalidate this assumption. With ASM, the 1095 packet route between the sender and receivers may initially be through 1096 the Rendezvous Point (RP) and then switch over to the shortest path to 1097 the sender as packets start flowing in a channel. The first issue is 1098 that the RP may not be the same for all channels associated with a 1099 session, and thus the first packets sent to the channels may follow a 1100 route that depends on the RP of the channel. This depends on the RP 1101 configuration for the sender. If the sender registers all channels 1102 associated with the session with the same RP then the assumption is 1103 true, but if the sender registers different channels with different RPs 1104 then the assumption may not be true. Thus, it is RECOMMENDED that the 1105 sender register all channels associated with a session with the same RP. 1106 Another issue is that when the channel switches over from the RP to the 1107 sender-based tree then the route to the receivers may vary within a 1108 channel. Furthermore, this may cause either the receipt of duplicate 1109 packets at receivers or loss of packets depending on the smoothness of 1110 the switchover. Thus, it is RECOMMENDED that the RP be placed as close 1111 as possible to the sender. The best location for the RP is that it be 1112 the first-hop router closest to the sender, in which case the path to 1113 the sender and the path to the RP is the same for each receiver and the 1114 problems mentioned above are eliminated. The consequences of this 1115 assumption not being true are that the receiver reaction to congestion 1116 may not be appropriate. Generally, the WEBRC receiver will act 1117 conservatively and reduce its reception rate too much if this assumption 1118 is not true, but there can be cases where the receivers will act 1119 inappropriately. 1121 5. Packet Header Fields 1123 Packets sent to a session using WEBRC MUST include Congestion Control 1124 Information fields as specified in this section. This document specifies 1125 short and long formats for the Congestion Control Information, and it is 1126 RECOMMENDED that protocol instantiations use one of these two formats. 1127 Other formats for the Congestion Control Information fields MAY be used 1128 by protocol instantiations, but all protocol instantiations are REQUIRED 1129 to use these fields in a format that is compatible with the 1130 interpretations of these fields. Thus, if a protocol does use a 1131 different format for the fields in the Congestion Control Information 1132 then it MUST specify the lengths and positions of these fields within 1133 the packet header. 1135 All integer fields are carried in "big-endian" or "network order" 1136 format, that is, most significant byte (octet) first. All constants, 1137 unless otherwise specified, are expressed in base ten. 1139 5.1. Short Format Congestion Control Information 1141 The short format for the Congestion Control Information is shown in Fig. 1142 1. The total length of the short format is 32-bits. 1144 0 1 2 3 1145 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 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | CTSI | Channel Number| Packet Sequence Number | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 Fig. 1 - Short format for Congestion Control Information 1152 The function of each field in the Congestion Control Information is the 1153 following. 1155 Current Time Slot Index (CTSI): 8 bits 1157 CTSI indicates the index of the current time slot. This must be 1158 sent in each packet within the session. The Current Time Slot 1159 Index increases by one modulo T each TSD seconds at the sender, 1160 where T is the number of time slots associated with the session 1161 and TSD is the time slot duration. Note that T is also the number 1162 of wave channels associated with the session, and thus T MUST be 1163 at most 255. 1165 Channel Number (CN): 8 bits 1167 CN is the channel number that this packet belongs to. CN for the 1168 base channel is T, and the CNs for the wave channels are 0 through 1169 T-1. Thus, T+1 channels in total are used, and thus T MUST be at 1170 most 255. 1172 Packet Sequence Number (PSN): 16 bits 1174 The PSN of each packet is scoped by its CN value. The sequence 1175 numbers of consecutive packets sent to the base channel are 1176 numbered consecutively modulo 2^16. The same sequence of PSNs are 1177 used for each wave channel in each cycle. The sequence numbers of 1178 consecutive packets sent to a wave channel are numbered 1179 consecutively modulo 2^16 within each cycle, ending with the last 1180 packet sent to the channel before the channel goes quiescent with 1181 PSN = 2^16-1. 1183 5.2. Long Format Congestion Control Information 1185 The long format for the Congestion Control Information is shown in Fig. 1186 2. The total length of the long format is 64-bits. 1188 0 1 2 3 1189 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 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | CTSI | Channel Number | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | Packet Sequence Number | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 Fig. 2 - Long format for Congestion Control Information 1198 The meaning of each field for the long format is the same as for the 1199 short format, the only difference is that each field is twice as long. 1201 Current Time Slot Index (CTSI): 16 bits 1203 CTSI indicates the index of the current time slot. This must be 1204 sent in each packet within the session. The Current Time Slot 1205 Index increases by one modulo T each TSD seconds at the sender, 1206 where T is the number of time slots associated with the session 1207 and TSD is the time slot duration. Note that T is also the number 1208 of wave channels associated with the session, and thus T MUST be 1209 at most 65 535. 1211 Channel Number (CN): 16 bits 1213 CN is the channel number that this packet belongs to. CN for the 1214 base channel is T, and the CNs for the wave channels are 0 through 1215 T-1. Thus, T+1 channels in total are used, and thus T MUST be at 1216 most 65 535. 1218 Packet Sequence Number (PSN): 32 bits 1219 The PSN of each packet is scoped by its CN value. The sequence 1220 numbers of consecutive packets sent to the base channel are 1221 numbered consecutively modulo 2^32. The same sequence of PSNs are 1222 used for each wave channel in each cycle. The sequence numbers of 1223 consecutive packets sent to a wave channel are numbered 1224 consecutively modulo 2^32 within each cycle, ending with the last 1225 packet sent to the channel before the channel goes quiescent with 1226 PSN = 2^32-1. 1228 6. Requirements From Other Building Blocks 1230 As described in RFC3048 [19], WEBRC is a building block that is intended 1231 to be used, in conjunction with other building blocks, to help specify a 1232 protocol instantiation. 1234 WEBRC does not provide higher level session support, e.g., how receivers 1235 obtain the necessary session description and how the receivers 1236 demultiplex received packets based on their session. There is support 1237 provided by other building blocks that can be used in conjunction with 1238 WEBRC to provide some of this support. For example, LCT [11] can 1239 provide some of the higher level in-band session support that may be 1240 needed by receivers, and the WEBRC Congestion Control Information (CCI) 1241 required in each packet can be carried in the CCI field of the LCT 1242 header [11]. 1244 WEBRC does not provide any type of reliability, and in particular does 1245 not provide support for retransmission of loss packets. Reliability can 1246 be added by independent means, such as by the use of FEC codes as 1247 described in [12] and specified in the FEC building block [13]. 1249 7. Security Considerations 1251 WEBRC can be subject to denial-of-service attacks by attackers that try 1252 to confuse the congestion control mechanism for receivers by injecting 1253 forged packets into the multicast stream. This attack most adversely 1254 affects network elements and receivers downstream of the attack, and 1255 much less significantly the rest of the network and other receivers. 1256 Because of this and because of the potential attacks due to the use of 1257 FEC described above, it is RECOMMENDED that Reverse Path Forwarding 1258 checks be enabled in all network routers and switches along the path 1259 from the sender to receivers to limit the possibility of a bad agent 1260 injecting forged packets into the multicast tree data path. 1262 It is also RECOMMENDED that packet authentication be used to 1263 authenticate each packet immediately upon receipt before the receiver 1264 performs any WEBRC actions based upon its receipt. Unfortunately, there 1265 are currently no practical multicast packet authentication schemes that 1266 offer instant packet authentication upon receipt. However, TESLA [17] 1267 can be used to authenticate each packet a few seconds after receipt. 1268 Thus, TESLA could be used in conjunction with WEBRC to authenticate 1269 packets and for example terminate the session upon detection of a forged 1270 packet. However, it is RECOMMENDED that the normal WEBRC receiver 1271 responses to received packets are allowed to occur immediately and are 1272 not delayed by the TESLA authentication process. This is because the 1273 overall WEBRC performance would be greatly degraded if the receiver 1274 delayed its WEBRC response to packet receipt for several seconds. 1276 A receiver with an incorrect or corrupted implementation of WEBRC may 1277 affect health of the network in the path between the sender and the 1278 receiver, and may also affect the reception rates of other receivers 1279 joined to the session. It is therefore RECOMMENDED that receivers be 1280 required to identify themselves as legitimate before they receive the 1281 session description needed to join the session. 1283 Another vulnerability of WEBRC is the potential of receivers obtaining 1284 an incorrect session description for the session. The consequences of 1285 this could be that legitimate receivers with the wrong session 1286 description are unable to correctly receive the session content, or that 1287 receivers inadvertently try to receive at a much higher rate than they 1288 are capable of, thereby disrupting traffic in portions of the network. 1289 To avoid these problems, it is RECOMMENDED that measures be taken to 1290 prevent receivers from accepting incorrect session descriptions, e.g., 1291 by using source authentication to ensure that receivers only accept 1292 legitimate session descriptions from authorized senders. 1294 8. IANA Considerations 1296 No information in this specification is subject to IANA registration. 1298 9. Intellectual Property Issues 1300 The IETF has been notified of intellectual property rights claimed in 1301 regard to some or all of the specification contained in this document. 1302 For more information consult the online list of claimed rights. 1304 10. References 1306 [1] S. Bradner, ``The Internet Standards Process -- Revision 3,'' 1307 RFC2026, October 1996. 1309 [2] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 1310 Levels,'' RFC2119, March 1997. 1312 [3] J.W. Byers, G. Horn, M. Luby, M. Mitzenmacher, W. Shaver. ``FLID- 1313 DL: Congestion control for layered multicast,'' IEEE J. on Selected 1314 Areas in Communications, Special Issue on Network Support for Multicast 1315 Communication, Vol. 20, No. 8, October 2002, pp. 1558-1570. 1317 [4] P. Dagum, R. Karp, M. Luby, and S. Ross, ``An optimal algorithm for 1318 Monte Carlo estimation,'' SIAM J. Comput., 29(5):1484-1496, April 2000. 1320 [5] S. Deering, ``Host Extensions for IP Multicasting,'' RFC1112, August 1321 1989. 1323 [6] V. K Goyal, ``On WEBRC Wave Design and Server Implementation,'' 1324 Digital Fountain Technical Report no. DF2002-09-001, September 2002, 1325 available at http://www.digitalfountain.com/technology/. 1327 [7] M. Handley, J. Padhye, S. Floyd, and J. Widmer, ``TCP Friendly Rate 1328 Control (TFRC): Protocol Specification,'' Internet Draft draft-ietf- 1329 tsvwg-tfrc-05, October 2002, a work in progress. 1331 [8] H. W. Holbrook, ``A Channel Model for Multicast,'' Ph.D. 1332 Dissertation, Stanford University, Department of Computer Science, 1333 Stanford, California, August 2001. 1335 [9] R. Kermode and L. Vicisano, ``Author Guidelines for Reliable 1336 Multicast Transport (RMT) Building Blocks and Protocol Instantiation 1337 documents'', RFC3269, April 2002. 1339 [10] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft, 1340 ``Asynchronous Layered Coding protocol instantiation,'' Internet Draft 1341 draft-ietf-rmt-pi-alc-08, April 2002, a work in progress. 1343 [11] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, and J. 1344 Crowcroft, ``Layered Coding Transport building block,'' Internet Draft 1345 draft-ietf-rmt-bb-lct-04.txt, February 2002, a work in progress. 1347 [12] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, and J. 1348 Crowcroft, ``The Use of Forward Error Correction in Reliable 1349 Multicast,'' Internet Draft draft-ietf-rmt-info-fec-03.txt, September 1350 2002, a work in progress. 1352 [13] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, and J. 1353 Crowcroft, ``Forward Error Correction building block,'' Internet Draft 1354 draft-ietf-rmt-bb-fec-07.txt, September 2002, a work in progress. 1356 [14] M. Luby and V. K Goyal, ``Wave and Equation Based Rate Control 1357 Using Multicast Round Trip Time: Extended Report,'' Digital Fountain 1358 Technical Report no. DF2002-07-001, September 2002, available at 1359 http://www.digitalfountain.com/technology/. 1361 [15] M. Luby, V. K Goyal, S. Skaria, and G. B. Horn, ``Wave and Equation 1362 Based Rate Control Using Multicast Round Trip Time,'' Proc. ACM SIGCOMM 1363 2002, Pittsburgh, PA, August 2002, pp. 191-214. 1365 [16] A. Mankin, A. Romanow, S. Bradner, and V. Paxson, ``IETF Criteria 1366 for Evaluating Reliable Multicast Transport and Application Protocols,'' 1367 RFC2357, June 1998. 1369 [17] A. Perrig, R. Canetti, D. Song, and J. D. Tygar, ``Efficient and 1370 Secure Source Authentication for Multicast,'' Network and Distributed 1371 System Security Symposium, NDSS 2001, pp. 35-46, February 2001. 1373 [18] L. Vicisano, L. Rizzo, and J. Crowcroft, "TCP-like Congestion 1374 Control for Layered Multicast Data Transfer", Proc. IEEE Infocom '98, 1375 San Francisco, CA, March-April 1998, pp. 996-1003. 1377 [19] B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, and M. 1378 Luby, ``Reliable Multicast Transport Building Blocks for One-to-Many 1379 Bulk-Data Transfer,'' RFC3048, January 2001. 1381 11. Authors' Addresses 1383 Michael Luby 1384 luby@digitalfountain.com 1385 Digital Fountain 1386 39141 Civic Center Drive, Suite 300 1387 Fremont, CA, USA, 94538 1389 Vivek K Goyal 1390 vivek@digitalfountain.com 1391 Digital Fountain 1392 39141 Civic Center Drive, Suite 300 1393 Fremont, CA, USA, 94538 1395 12. Full Copyright Statement 1397 Copyright (C) The Internet Society (2002). All Rights Reserved. 1399 This document and translations of it may be copied and furnished to 1400 others, and derivative works that comment on or otherwise explain it or 1401 assist in its implementation may be prepared, copied, published and 1402 distributed, in whole or in part, without restriction of any kind, 1403 provided that the above copyright notice and this paragraph are included 1404 on all such copies and derivative works. However, this document itself 1405 may not be modified in any way, such as by removing the copyright notice 1406 or references to the Internet Society or other Internet organizations, 1407 except as needed for the purpose of developing Internet standards in 1408 which case the procedures for copyrights defined in the Internet 1409 languages other than English. 1411 The limited permissions granted above are perpetual and will not be 1412 revoked by the Internet Society or its successors or assigns. 1414 This document and the information contained herein is provided on an "AS 1415 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1416 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1417 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1418 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1419 FITNESS FOR A PARTICULAR PURPOSE."