【正文】 ate schemes by deploying singlerate schemes on selected intermediate contributions of this paper include: ? It proposes ORMCC, a simple and effective singlerate multicast congestion control scheme based on a new metric TRAC, with features such as O(1) state, nontimerbased feedback suppression etc. ? It analyzes the scheme performance theoretically. ? By parison in simulation with PGMCC and TFMCC, it shows that ORMCC achieves better It includes the test results of ORMCC implementation on real systems in Emulab. Our scheme is simple because at the source and receivers, O(1) state is maintained, and only simple putation is required, there is no need to measure RTTs from all receivers to the source, which can be a tedious problem especially without external instrumentation (. GPS, NTP server), and we do not make any assumption on work topology and intermediate nodes beyond standard multicast capabilities. It is also effective because it successfully addresses the problems of slowest receiver tracking, TCPfriendliness, and droptozero, the feedback suppression mechanism works very effectively by suppressing over 95% feedback under normal situations. In fact, it outperforms PGMCC and TFMCC under most situations. The key idea of ORMCC is to base the scheme on a new metric, TRAC(Throughput Rate At Congestion), which is the throughput rate measured by receivers when congestion is detected. (Throughput Rate At Congestion), which is the throughput rate measured by receivers when congestion is detected. The general concept of our scheme is as follows: The source dynamically selects one of the slowest receivers as Congestion Representative (CR), and only considers its feedback for rate adaptation. The slowest receivers are those with the lowest average TRACs. When there is no CR, all receivers may send feedbacks to the source. Once a CR is selected, only the CR and those receivers with average TRAC lower than that of the CR can send feedbacks so that feedbacks are efficiently suppressed. Also notice that our scheme is not concerned with reliability issue and only considers congestion control. Therefore, it is applicable to both reliable and unreliable multicast. 浙江理工大學(xué)科技與藝術(shù)學(xué)院本科畢業(yè)設(shè)計(jì)（論文） Fig. 1. EXAMPLE OF ORMCC OPERATION An example operation can illustrate how our scheme works more clearly. In Figure 1 (a), the source has chosen a receiver behind the most congested path as CR by paring average TRACs of receivers. Only the CR will send feedback while other receivers suppress their feedback. The feedback is CI(181。) in Figure 1 where CI means congestion indication and 181。 is TRAC measured by receiver. After a while, another path bees the new most congested path. Those receivers behind that path will see average TRACs lower than that of the current CR, and will send feedbacks (Figure 1 (b)). As a result, one of them will be chosen as the new CR. After that, again, other receivers suppress their feedback (Figure 1 (c)). 浙江理工大學(xué)科技與藝術(shù)學(xué)院本科畢業(yè)設(shè)計(jì)（論文） II. RELATED WORK Schemes DeLucia et. al?s work in is an early singlerate multicast congestion control scheme using representatives. It requires two types of feedback from receivers, Congestion Clear (CC)and Congestion Indication (CI). Note that their CIs are single bit and thus different from ours carrying 181。. A fixed number of receiver representatives are maintained at the source. Whenever a CI is received by the source, if the sender of this CI is in the representative set, the representative is refreshed。 if not, the sender will replace the representative that has not been refreshed for the longest time. Feedback from representatives is echoed by the source to suppress feedback scheduled at nonrepresentative receivers. The source uses only the feedback from representatives to do MIMD (multiplicative increase and multiplicative decrease) rate adaptation. The representative selection mechanism in that scheme is “simplistic”, but there is certain plexity involved in generating CC. The representative set is not guaranteed to include the slowest receiver, which means that the slowest receiver can be overloaded. Furthermore, it assumes that only a few bottlenecks cause most of the on this assumption, receiver suppression is the only mechanism for filtering feedback from receivers. In a heterogeneous work, where there may be many different bottlenecks and asynchronous congestion, the assumption may not be true. Consequently, the transmission rate may be reduced more than necessarily and stay very low or close to zero. This is known as , TFMCC] and MDPCC are recent work also using representatives. Although they use different policies for rate adaptation, they all leverage the TCP throughput formula for allocating the slowest receiver, the receiver with the lowest estimate TCP throughput according to the formula. Therefore, it is necessary for them to measure packet loss rate and RTT for all receivers. PGMCC keeps one representative as acker. The acker sends ACKs to the source which mimics the behavior of TCP. At the same time, NAKs with loss rate are sent from all other receivers. This is different from our scheme because we do not require separate ACK streams. The PGMCC source measures RTT between itself and all receivers in terms of packet numbers, and pare the estimated throughput for updating acker. Due to the necessity of RTT measurement for all receivers, feedback suppression may have serious effect on PGMCC?s fact, PGMCC does 浙江理工大學(xué)科技與藝術(shù)學(xué)院本科畢業(yè)設(shè)計(jì)（論文） not provide a feedback suppression mechanism. TFMCC adjusts the rate according to the estimated rate calculated by the representative. RTTs are measured by receivers with a somewhat plex procedure. The sender needs to echo receiver?s feedback according to some priority order, and there is oneway delay RTT ad