GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3738

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3738.txt · Last modified: 2004/04/20 20:27 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki