Internet Engineering Task Force Bing Zhang INTERNET-DRAFT Zengji Liu draft-zhang-barm-congestion-01.txt Xidian Univ. July 17, 2005 Expires: January 17, 2006 Binomial Congestion Control At Receivers for Multicast (BARM) Status of this Document By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies Binomial congestion control At Receivers for Multicast (BARM). BARM is a single rate multicast congestion control protocol for streaming media applications in the best effort Internet environment. Combining aspects of window-based and rate-based congestion control, the protocol shifts most of the congestion control mechanisms to multicast receivers. A congestion window is maintained and updated by each receiver independently according to TCP-friendly binomial algorithm, and is converted to the expected sending rate which is then fed back to the sender if permitted. To suppress feedback implosion, a representative receiver is selected among receivers and a distributed suppression mechanism is used. BARM has good TCP-friendliness, smoothness, scalability, and acceptable responsiveness. Zhang/Liu [Page 1] Expires: January 17, 2006 July 17, 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 2.1. Binomial Algorithm . . . . . . . . . . . . . . . . . . . . 5 2.2. Packet Contents . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Sender Packets . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Feedback Packets . . . . . . . . . . . . . . . . . . . . 6 3. Data Sender Protocol . . . . . . . . . . . . . . . . . . . . 7 3.1. Sender Initialization . . . . . . . . . . . . . . . . . . 7 3.2. Selecting Representative and Adjusting Sending Rate . . . 8 3.3. Assisting Receiver-side RTT Measurement . . . . . . . . . 8 3.4. Suppressing Feedbacks from Non-representative Receivers . 9 3.5. Determining Maximum RTT . . . . . . . . . . . . . . . . . 10 4. Data Receiver Protocol . . . . . . . . . . . . . . . . . . 10 4.1. State Diagram at Receivers . . . . . . . . . . . . . . . 10 4.2. Adopting Window Round Mechanism to Detect Congestion . . 12 4.3. RTT Measurement . . . . . . . . . . . . . . . . . . . . . 12 4.4. Calculating the Expected Sending Rate . . . . . . . . . . 13 4.5. Feedback and Feedback Suppression . . . . . . . . . . . . 14 4.6. Joining and Leaving Multicast Session . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 17 Zhang/Liu [Page 2] Expires: January 17, 2006 July 17, 2005 1. Introduction The document specifies Binomial congestion control At Receivers for Multicast (BARM) [1]. BARM is a receiver-driven single rate multicast congestion control protocol. It has good TCP-friendliness, smoothness, scalability and acceptable responsibility, which makes BARM suitable for congestion control of streaming media multicast applications. It can scales to receivers sets on the order of several thousand receivers. BARM is a building block as defined in RFC3048. Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as RTP [2], in an application incorporating end-to-end congestion control at the application level. This document does not discuss packet formats, reliability, or implementation-related issues. BARM is designed to be friendly when competing for bandwidth with TCP flows. A BARM flow is defined as TCP-friendly when for each sender-receiver pair, the multicast flow has the property of being unicast TCP-friendly, that is, its existence does not reduce the long-term throughput of any coexistent TCP flow more than another TCP flow on the same path would under the same network conditions. BARM is a single rate scheme whose sending rate is adapted to the receiver experiencing the worst network conditions. BARM is designed to keep good rate smoothness. Its rate fluctuation is much smaller than that of TCP when network conditions change. It achieves this at the cost of a reduced responsiveness to changes in available bandwidth. Thus BARM should be used for applications which have requirements for smooth throughput. For applications that simply need to multicast as much data as possible in as short a time as possible, PGMCC [3] may be more suitable. To achieve a good scalability, BARM shifts most of the work to receivers, and the mechanisms of representative selection and distributed feedback suppression are used. The sender selects as the representative the receiver with the lowest feedback rate, and updates its sending rate according to expected rate of the representative. To avoid feedback implosion, a feedback round suppression scheme is used in which only selected receivers are allowed to send feedbacks, thus decreasing the amount of feedbacks greatly. Compared with TFMCC [4][5], BARM is easier in implementation and better in scalability, making it suitable for multicast group with up to several thousands of receivers. BARM is designed for applications that use a fixed packet size, and vary their sending rate in packets per second in response to congestion. BARM is most applicable for sessions that deliver a substantial amount of data, i.e., in length from hundreds of kilobytes to many gigabytes, and whose duration is in the order of tens of seconds or more. Zhang/Liu [Page 3] Expires: January 17, 2006 July 17, 2005 1.1. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate requirement levels for compliant BARM implementations. 1.2. Related Documents As described in RFC 3048, BARM is a building block that is intended to be used, in conjunction with other building blocks, to help specify a protocol instantiation. 2. Protocol Overview In general, as a single rate multicast congestion control mechanism, BARM works as follows: - Each receiver independently maintains a variable called cwnd (congestion window) and measures the round-trip time (RTT) to the sender. It also maintains a state diagram similar to TCP. According to network congestion condition based on the arrival of the packets, receivers adjust their own cwnd separately. In particular, at Congestion Avoidance state cwnd is adjusted according to TCP-friendly binomial algorithm. In order to detect packet loss at receivers and emulate the behavior of TCP, a "window round" mechanism is introduced, and cwnd is updated at the end of each window round. - Based on RTT and cwnd, each receiver calculates its expected sending rate, which reflects the network condition from sender to it. - To avoid feedback implosion, most receivers' feedbacks are suppressed by means of distributed feedback suppression mechanism in which a "feedback round" scheme is introduced. The protocol gives more feedback probability to the receivers with lower expected rates. Receivers who get the chance to send feedbacks report their expected rate to the sender in so-called feedback reports. The feedback reports serve two purposes: they inform the sender about their expected sending rate, and they allow the receivers to measure their RTT. - The sender selects as the representative the receiver with the lowest feedback rate, and updates its sending rate according to feedback rate of the representative. Zhang/Liu [Page 4] Expires: January 17, 2006 July 17, 2005 The design of BARM references some mechanisms of TFMCC protocol (such as feedback round scheme and RTT measurement). However, BARM is radically deferent from TFMCC in their main mechanisms. Compared with TFMCC, BARM [1] is easier in implementation and better in scalability. 2.1 Binomial algorithm BARM adopts binomial algorithm [6] as the congestion window adjustment scheme at the state of Congestion Avoidance (see section 4.1). At the end of a window round (see section 4.1) during which there is no packet loss, cwnd is increased according to equation (1): cwnd += a/sqrt(cwnd) (1) When a receiver detects packet loss during a window round, it immediately decreases its cwnd to the value given in equation (2): cwnd -= b*sqrt(cwnd) (2) cwnd is the congestion window maintained at each receiver, while a and b are two constants. The values of a and b are set to 0.28 and 0.2 respectively. Binomial algorithm with above parameters is the key to TCP-friendliness and rate smoothness of BARM. 2.2. Packet Contents This section introduces congestion control information contained in the packets sent by the sender and feedbacks packets sent by the receivers. Information from the sender can either be sent in separate congestion control messages or piggybacked onto data packets. As BARM will be used along with a transport protocol, packet formats are not specified, since these depend on the details of the transport protocol used. 2.2.1. Sender Packets Each packet sent by the data sender contains the following information: - A sequence Number i: This number is incremented by one for each data packet transmitted. The field must be sufficiently large that it does not wrap causing two different packets with the same sequence number to be in the receiver's recent packet history at the same time. Zhang/Liu [Page 5] Expires: January 17, 2006 July 17, 2005 - A representative receiver ID Rep_r: This value is to inform receivers of the current representative receiver. If there is no representative, the field should be set to 0 to indicate the difference from all the receivers. - State of representative receiver St_r: This value is to indicate the state of current representative. The state of SS or CA should be specified (see section 4.1). - A current sending rate X_send in bits/s: A new joined receiver uses this value to calculate its initial cwnd. - A suppression rate X_supp in bits/s. Only receivers with a calculated expected rate lower than the suppression rate are eligible to give feedbacks, unless their RTTs are higher than the maximum RTT described below in which case they are also eligible to give feedbacks. - A timestamp ts_i indicating when the packet is sent. This value is to measure RTT from sender to a receiver. The resolution of the timestamp should typically be milliseconds. - A receiver ID rcvr and a copy of the timestamp ts_r of that receiver's last report, which allows the receiver to measure its RTT. ts_r which is included in the sending packet, needs to be adjusted by the time interval between receiving the feedback packet and sending data packet (i.e., that time interval has to be added to the timestamp value). The receiver ID is described in the next section. The resolution of the timestamp echo should be milliseconds. - A feedback round counter fb_nr. This counter is incremented by the sender at the beginning of a new feedback round to notify the receivers that all feedbacks for older rounds should be suppressed. - A maximum RTT value R_max, representing the maximum of the RTTs of all receivers. All of the RTTs should be measured in milliseconds. 2.2.2. Feedback Packets Each feedback packet sent by the receiver contains the following information: - A unique receiver ID rcvr indicating the receiver who sends this feedback packet. The ID should be a positive integer. - A flag have_RTT indicating whether the receiver has made at least one RTT measurement since it joined the session. Zhang/Liu [Page 6] Expires: January 17, 2006 July 17, 2005 - A flag receiver_leave indicating that the receiver will leave the session. - A timestamp ts_r indicating when the feedback packet is sent. The representation of the timestamp should be the same as that of the timestamp echo in the data packets. - An echo of the timestamp of the last data packet received. If the last packet received at the receiver has sequence number i, then ts_i is included in the feedback. If there is a delay t_d between receiving that last data packet and sending feedback, then ts_i' = ts_i + t_d is included in the feedback instead of ts_i. The representation of the timestamp echo should be the same as that of the timestamp in the data packets. - A feedback round echo fb_nr, reflecting the highest feedback round counter value received so far. The representation of the feedback round echo should be the same as the one used for the feedback round counter in the data packets. - The expected sending rate X_exp. This is the rate calculated by the receiver. The representation of the expected sending rate should be the same as that of the suppression rate in the data packets. 3. Data Sender Protocol The main tasks that are provided by a BARM sender are: (1) selecting the representative from feedbacks of receivers; (2) adjustment sending rate according to the feedbacks of the representative; (3) Determining the Maximum RTT and assisting receiver-side RTT measurement; (4) suppressing receivers' feedbacks using feedback suppression scheme. 3.1. Sender Initialization At initialization of the sender, the maximum RTT is set to a value that should be larger than the highest RTT to any of the receivers. It should not be smaller than 500 milliseconds for operation in the public Internet. The sending rate X_send is initialized to 1 packet per maximum RTT and no_feedback_timer is set to expire after t_f second (12 times Maximum RTT is recommended). This process is terminated as soon as any feedback from one of the receivers is received. After that, the representative is selected and the sender sends packets at the rate that matches the representative's Zhang/Liu [Page 7] Expires: January 17, 2006 July 17, 2005 expected sending rate. At any time, if the sender does not receive any feedback report from any of the receivers for some time (after no-feedback-timer of t_f expires), it cuts its sending rate in half. The lowest sending rate is limited to 1 packet every 64 seconds. 3.2. Selecting Representative and Adjusting Sending Rate BARM is a single rate multicast congestion control whose sending rate depends on the receiver experiencing the worst congestion condition. Each receiver has an opportunity to send feedback packet reporting its expected sending rate from the sender. The sender selects the receiver that reports the lowest rate as representative receiver and adjusts its sending rate accordingly. When a feedback from a receiver arrives at the sender, the sender has to decide whether to change the representative and adjust its sending rate. If no representative is present, the sender selects the receiver to become the representative and adjusts its sending rate to the expected sending rate of the receiver. If the representative is already present but the receiver is not the representative, the receiver becomes new representative only if its expected rate is smaller than current sending rate. The sending rate is decreased to its expected rate. If the feedback is from the current representative, the sender sets its current sending rate to the expected rate in the feedback packet no matter the expected rate is higher or lower than current sending rate. If the receiver has not yet measured its RTT (i.e., the have_RTT flag is set false), the receiver report will include a expected rate that is based on the maximum RTT rather than the actual RTT to that receiver. In this case, the sender adjusts the sending rate using its measurement of the instantaneous RTT R_r to that receiver: X_exp' = X_exp * R_max / R_r X_exp' is then used instead of X_exp to detect whether to switch to a new representative. When the representative leaves the multicast group, or if the sender receives no reports from the representative for a period of time (after no-representative-feedback-timer expires, 10 times Maximum RTT is recommended), the sender will cancel the current representative (i.e., Rep_r should be set to 0) and start to select a new one. 3.3. Assisting Receiver-side RTT Measurement Zhang/Liu [Page 8] Expires: January 17, 2006 July 17, 2005 Each receiver measures its RTT by sending a timestamp with the feedback packet, which can be echoed in the next data packet (It is necessary to account for the time that elapses between receiving a report and sending the next data packet). With the information of the receiver ID and the echoed timestamp contained in the data packet, the corresponding receiver measures its RTT. If more than one feedback from different receivers arrive at the sender during the same packet interval, the sender's timestamp echoes are prioritized in the following order: - 1. a new representative (after a change of representative) or a representative without any previous RTT measurements - 2. receivers without any previous RTT measurements in the order of the feedback round echo of the corresponding receiver report (i.e., older feedback first) - 3. non-representative receivers with previous RTT measurements (again, older feedback first) - 4. the representative. 3.4. Suppressing Feedbacks from Non-representative Receivers The sender uses feedback round scheme to suppress lots of feedbacks from non-representative receivers. The sending process is divided into consecutive feedback rounds with a new round starting after the ending of last round. Every feedback round is identified by a number fb_nr which is also included in all packets sent during the current feedback round. Each feedback round has duration T of Nt times Maximum RTT where Nt of 8 is recommended. At the beginning of each feedback round, the sender sets its suppression rate to a maximum possible value that can be represented. Only if the expected sending rate of a receiver is smaller than current suppression rate X_supp, or its RTT is larger than current Maximum RTT can a receiver send its feedback. When receiving a feedback report from a non-representative, the sender resets its suppression rate to: X_supp = (1-g) * X_exp Where X_exp is the expected sending rate of the receiver and g of 0.9 is recommended. After a time span of T, the current feedback round ends. The feedback round counter is incremented by one and a new feedback round begins. The suppression rate X_supp is reset to the highest representable value. Zhang/Liu [Page 9] Expires: January 17, 2006 July 17, 2005 When the sender receives a feedback report from a non-representative whose expected sending rate is lower than the expected rate of current representative, the receiver becomes new representative. 3.5. Determining Maximum RTT Maximum RTT is the maximum among all RTTs from sender to each receiver. It is mainly used for suppressing feedbacks from receivers with different RTTs. When receiving a feedback report from a receiver, the sender calculates its instantaneous RTT Rs_ins to the receiver as: Rs_ins = t_now - ts_i Where t_now is the arrival time of feedback packet, ts_i is timestamp contained in the feedback packet. If the instantaneous RTT is larger than current Maximum RTT, the Maximum RTT is adjusted to a new value as: R_max = Rs_ins If no instantaneous RTT larger than Maximum RTT is received during current feedback round, Maximum RTT is reduced to: R_max = MAX(R_max * 0.9, R_peak) Where R_peak is the maximum receiver RTT measurement during the feedback round. 4. Data Receiver Protocol A congestion window (cwnd) and a state diagram are maintained independently by each receiver, who adjusts cwnd according to current state and the data packets received. Meanwhile each receiver measures its RTT to the sender. Through the information acquired, the expected sending rate is calculated which reflects the network condition from the sender to it. In order to avoid feedback implosion caused by feedback reports from lots of receivers, a feedback round scheme is used where only selected receivers send their feedbacks. 4.1. State Diagram at Receivers Zhang/Liu [Page 10] Expires: January 17, 2006 July 17, 2005 +---------+ packet drop | |---------- -------------------->| FR | \ / | |<----- | | +---------+ \ | | | | | packet | |after | drop | |a RTT | | | +---------+ +---------+ / | | | cwnd >= ssthresh | |------ | ------->| SS |----------------->| CA | / / | | | |<--------- | +---------+ +---------+ | | | |after a RTT |timeout | | | | | V | | +---------+ | \ | | timeout / --------| TO |<-------------------- | | +---------+ BARM state diagram at receivers Figure 1 Unlike TCP, BARM maintains a variable called cwnd at each receiver instead of at the sender and adjusts it based on the arrival of the packets. It greatly decreases the information that would be maintained at the sender. For this a state diagram is set up at each receiver. The states of BARM consist of four states: Slow Start (SS), Congestion Avoidance (CA), Fast Recovery (FR) and Timeout (TO). Figure 1 shows the state diagram at BARM receivers. Each receiver works as follows: Initially cwnd is set to 1. When the first data packet is received, the receiver enters SS state, during which the congestion window increases exponentially as Slow Start of TCP to explore the network bandwidth available rapidly. This state does not change until a packet loss is detected (see section 4.2) or the cwnd is larger than SSthresh (the Slow Start threshold), when the receiver enters FR or CA respectively. FR state is entered if a packet loss occurs. At this state, the receiver decreases its cwnd immediately according to the binomial decrease algorithm (equation 2). Then it waits for a period of R (i.e., the measured RTT at the receiver, see section 4.3), and all the packets received during this time are ignored. At the end of the RTT period, it changes to CA state. At CA state, the cwnd Zhang/Liu [Page 11] Expires: January 17, 2006 July 17, 2005 increases according to the binomial increase algorithm (equation 1). If persistent congestion occurs so that a RTO (Receiving Timeout) timer expires, it changes to TO state. After a period of R, the receiver changes its state to SS and cwnd is set to 1. The initial value of SSthresh is recommended to 64. When a packet drop is detected at the state of SS, SSthresh is cut in half, while at CA state SSthresh is set to m times current SSthresh. The value of m of 0.8 is recommended. RTO (Receiving Timeout) is a period of time during which no data packet is received. The value of RTO of 12 times Maximum RTT is recommended. 4.2. Adopting Window Round Mechanism to Detect Congestion Each receiver adjusts its window in terms of "window round". The idea of window round we use comes from TEAR [7]. The arrival of packets is partitioned into non-overlapping window rounds. A new window round begins when the current window round ends. If no packet loss occurs, a window round contains roughly an arrival of the cwnd number of packets. If congestion detected, the current window round ends immediately and after a period of R a new window round begins. At the end of a window round, the receiver updates its cwnd. Because the feedback at the end of the previous window round may take effect at the sender after an R period, the protocol also maintains another variable named lastCwnd at each receiver. lastCwnd is the value of cwnd at the end of the previous window round. A window round ends only when "lastCwnd" number of packets are received if no packet loss occurs in current window round. Like TCP, the receivers detect congestion by packet loss (in fact ECN [8] can also be used to detect congestion). Each data packet has a sequence number and the packets are transmitted in sequence. The receivers each maintain a packet history that keeps track of which packets have arrived and which are missing in the current round. If congestion occurs resulting in a packet loss, there will be a gap in the packet history. The loss of a packet is detected by the arrival of at least three packets with a higher sequence number than the lost packet. The current window round ends and FR state is entered immediately. If the receiver gets less than three packets after a packet loss until the packet with the largest sequence number in the current window round has arrived, or if no packet is received during a period of time (one RTO), the current window round also ends and TO state is entered. 4.3. RTT Measurement Zhang/Liu [Page 12] Expires: January 17, 2006 July 17, 2005 A receiver measures RTT to the sender using timestamp contained in the feedback packet. When a receiver receives a data packet that includes the receiver's own ID in the rcvr field, the receiver updates its RTT estimate. The current RTT sample is given as: R_sample = t_now - ts_r Where t_now is the time when the data packet arrives at the receiver and ts_r is the receiver report timestamp echoed in the data packet. Then the smoothed RTT estimate R is updated: If no feedback has been received before R = R_sample Else R = q*R + (1-q)*R_sample A filter parameter q of 0.5 is recommended for non-representative receivers. As representative receiver performs RTT measurements much more frequently, a larger filter value should be used. We recommend using q=0.9. 4.4. Calculating the Expected Sending Rate The updated cwnd can't be fed back to the sender directly. The value of cwnd must be converted to the expected sending rate X_exp. First a rate sample r is calculated as r = cwnd * packet_size / R Where packet_size is the size of a data packet. To further decrease the rate fluctuation, the weighted averaging over rate samples taken over the past several rounds is applied. For this reason, the expected receiving rate X_exp is given as R_tot = 0; W_tot = 0; for (i = 1 to n) { R_tot = R_tot + (r(i) * w(i)); W_tot = W_tot + w(i); } X_exp = R_tot/W_tot; Zhang/Liu [Page 13] Expires: January 17, 2006 July 17, 2005 Where n the number of expected rate samples, r(i) being the rate sample calculated in the recent ith window round. The value of n is recommended to be 8. w(i) is the weight which is given as If (i <= n/2) w(i) = 1; Else w(i) = 1 - (i - n/2)/(n/2 + 1); 4.5. Feedback and Feedback Suppression BARM uses feedback round mechanism to avoid the feedback implosion. Every data packet arrived at the receiver includes a feedback round counter value of fb_nr. When the receiver receives a packet with a new fb_nr, it set a feedback timer. After the timer expires the receiver sends a feedback report unless the timer is cancelled before the expiration of the timer. Feedback suppression mechanism is only used for non-representative. The representative sends its feedback in each window round and its feedback is independent from other receivers. The feedback from representative neither is suppressed by feedbacks from other receivers nor suppresses other receivers' feedbacks. Let fb_nr be the highest feedback round counter value received by a receiver. When a new data packet arrives with a higher feedback round counter than fb_nr, a new feedback round begins and fb_nr is updated. Outstanding feedback for the old feedback round is cancelled. Non-representative receiver sets a feedback timer at the beginning of a feedback round. Using an exponentially weighted random timer mechanism, the feedback timer is set to expire after t = max(T * (1 + log(x)/log(N)), 0) where x is a random variable uniformly distributed in (0,1), T is the duration of a feedback round (i.e., 8 * R_max), N is an estimated upper bound on the number of receivers. A value of N of 10000 is recommended. When the feedback timer expires, a feedback report is sent unless the timer is cancelled before. The expected sending rate contained in the Zhang/Liu [Page 14] Expires: January 17, 2006 July 17, 2005 feedback packet is the one calculated by the receiver at the end of most recent "window round". If the suppression rate contained in the sending data packet is lower than the expected rate calculated at the receiver, AND the value of maximum RTT in the data packet is higher than or equal to RTT (i.e., R) computed at the receiver, the feedback timer is cancelled. This means feedback for that feedback round is suppressed. Likewise, a data packet indicating the beginning of a new feedback round cancels all feedbacks for older feedback rounds. 4.6. Joining and Leaving Multicast Session A receiver may join or leave a BARM session at any time. A late joined receiver should decide its initial congestion window size and initial state according to current sending rate and the state of the representative. Its initial cwnd is given as: cwnd = X_send * RTT_max Where X_send is the sending rate contained in data packet, and RTT_max being initial maximum value for RTT (500ms is recommended). After that, the receiver adjusts its cwnd according to state diagram, calculates expected sending rate and sends feedback report if permitted. When the first RTT value is measured, the receiver should adjust its cwnd to avoid abrupt fluctuation of expected rate: cwnd = X_exp * R where X_exp is the expected sending rate, R being its measured RTT. After that, cwnd is not adjusted when the value of R changes. If a receiver wishes to leave the BARM session within the next feedback round, it may indicate the pending leave by setting the receiver_leave flag in its report. If the leaving receiver is the representative, the receiver_leave flag should be set for all the reports within the feedback round before the leave takes effect. 5. Security Considerations The associated security issues will be identified as further works to go on. Zhang/Liu [Page 15] Expires: January 17, 2006 July 17, 2005 6. IANA Considerations There are no IANA actions required for this document. 7. Authors' Addresses Bing Zhang State Key Lab. of Integrated Services Networks Xidian University Xi'an, Shaanxi, 710071, China Zhangbing328@sina.com Zengji Liu State Key Lab. of Integrated Services Networks Xidian University Xi'an, Shaanxi, 710071, China zjliu@xidian.edu.cn 8. Acknowledgments We would like to acknowledge Joerg Widmer and Mark Handley who designed TFMCC. Some mechanisms of BARM are based on or from TFMCC. For the purpose for protocol integrity, the authors quote some of them in this document. We would also like to thank Zhen Li and Yayan Xu who participated in the implementation of the protocol. 9. References [1] B. ZHANG, Z. LIU, Y. XU, Z. LI, S. ZHANG, "Binomial congestion control at receivers for multicast", Proc. ITCOM 2004, Philadelphia, October 2004. [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [3] L. Rizzo, "Pgmcc: A TCP-friendly Single-rate Multicast Congestion Control Scheme", Proc ACM SIGCOMM, Stockholm, Sweden, 2000. [4] J. Widmer, M. Handley, "Extending Equation-based Congestion Control to Multicast Applications", Proc ACM SIGCOMM, San Diego, 2001. [5] J. Widmer and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", Internet Draft Zhang/Liu [Page 16] Expires: January 17, 2006 July 17, 2005 draft-ietf-rmt-bb-tfmcc-03.txt, July 2004, work in progress. [6] D. Bansal, H. Balakrishnan, "Binomial Congestion Control Algorithm", Proc IEEE INFOCOM 2001, Alaska 2001. [7] Rhee, V. Ozdemir, Y. Yi, "TEAR: TCP Emulation at Receivers - Flow Control for Multimedia Streaming", Tech. report., Dept. of Comp. Sci., NCSU, April 2000. [8] K. Ramakrishnan and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999. 10. Copyright Notice Copyright (C) The Internet Society (2005). 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. Zhang/Liu [Page 17]