A Simple Mechanism for Improving the Throughput of Reliable Multicast

Transcription

1 A Simple Mechanism for Improving the Throughput of Reliable Multicast Sungwon Ha Kang-Won Lee Vaduvur Bharghavan Coordinated Sciences Laboratory University of Illinois at Urbana-Champaign fs-ha, kwlee, Abstract Single-rate reliable multicast protocols are known to have scalability problems in the presence of a large number of receivers because the sender cannot distinguish independent packet losses at different receivers from multiple packet losses at the same receiver. In the presence of a large number of receivers, the sender may perceive a large aggregate packet loss even if no individual receiver is highly congested. Consequently, the multicast session progresses at a much slower rate than its desired sending rate. In order to solve this problem, we argue for decoupling of the mechanisms to achieve congestion control and reliability in reliable multicast protocols, and present a very simple loss notification based multicast congestion control mechanism that can be used to augment both ACK-based and NAK-based reliable multicast protocols and solve the independent packet loss problem. We illustrate the efficacy of our approach via simulations using the ns2 simulator. I. INTRODUCTION Recent years have witnessed a tremendous increase in the use of the Internet for a large variety of applications including commerce, web access, software distribution, multimedia, and of course, data communication. Many of these applications involve multiple communicating entities, and require reliable data transmission from a sender to multiple receivers. While it is of course possible to establish multiple unicast TCP connections and accomplish reliable data transmissions between each sender-receiver pair, this approach has two distinct disadvantages: (a) it involves a high overhead in terms of duplicating packet transmissions for connections which may potentially be able to share common links, and (b) it requires application-level synchronization between a sender and its receiver set. For both these reasons, reliable multicasting service is gaining popularity as a highly desirable service of the future Internet infrastructure. Recently, a number of reliable multicast protocols have been proposed [1, 2, 3, 4, 5, 6]. In this paper, we consider the popular class of reliable multicast protocols that support loose synchronization among receivers, i.e. all the receivers in the same multicast group perceive approximately the same progress of the session. Reliable multicast protocols in this class are single-rate and are constrained to progress at a rate that is bounded by the rate of the slowest receiver in the multicast group. Unfortunately, this class of protocols is highly susceptible to degradation in throughput as the number of receivers in a multicast group increases. This is because of the well known independent loss phenomenon, also referred to as the drop-to-zero problem or loss path multiplicity problem in related literature [7, 8], wherein the total amount of loss feedback received by the sender increases with the number of receivers, even when no single receiver experiences significant congestion or packet loss. From the sender s perspective, it is difficult to distinguish independent losses at multiple receivers from bulk losses experienced by a single bottleneck receiver. However, as described before, the progress of a single-rate reliable multicast protocol that provides synchronization among receivers is constrained by the slowest receiver, and in the presence of independent losses at multiple receivers, the sender mistakenly reacts to cumulative loss (i.e. assuming worst case behavior) rather than distinguishing independent losses. This can cause a severe degradation of throughput, as we have observed in our experiments and as has been reported in related work [6, 8]. In this paper, we seek to improve the throughput of reliable multicast protocols in particular, and single-rate multicast protocols in general, by proposing a very simple mechanism to augment the existing multicast congestion control algorithms in such protocols. Basically, our mechanism helps to overcome the independent loss problem by triggering the multicast congestion control algorithms only for significant losses (i.e. losses at the bottleneck receiver(s)). We show that our mechanism is applicable for both ACK-based [1, 6] and NAK-based [2, 4, 5] protocols. Basically our approach is to decouple the congestion feedback and the reliability feedback that are generated by the receivers. In reliable multicast protocols, receivers either generate positive (cumulative) acknowledgements in the ACK-based paradigm to indicate the successful reception of packets, or negative acknowledgements in the NAK-based paradigm to indicate loss of packets. Typically, cumulative ACKs are aggregated by specialized multicast routers in the network [6] and duplicate NAKs are suppressed by receivers or specialized filters in intermediate routers [5, 9] in order to prevent feedback implosion at the sender. When the sender receives ACK/NAK feedback, it identifies which packets have been lost and retransmits all lost packets (packets that may be lost by any receiver). In other words, the sender must respond to every packet loss (for simplicity, we do not consider local recovery in this paper). On the other hand, in terms of adjusting the sending rate for multicast congestion control, the sender only needs to respond to loss notifications from the slowest receiver(s). This naturally calls for a decoupling of reliability feedback (wherein the sender retransmits all lost packets at any receiver) from congestion feedback (wherein the sender throttles its rate according to the receiver that lost the maximum number of packets). Unfortunately, due to ACK aggregation and NAK suppression, the sender cannot figure out the latter merely by monitoring the source of the ACK/NAK feedback even if it chose to do so. Thus, we need some additional mechanisms to augment the existing ACK/NAK feedback in order to enable the sender to determine when to trigger congestion control. A fortuitous consequence of decoupling congestion feedback from from reliability feedback is that we can also support congestion control for unreliable or semi-reliable single-rate multicast protocols using the same mechanism. In this paper, we argue for very simple loss notification feedback from the receivers that can be used by the sender to trigger multicast congestion control selectively (i.e. in response to losses at bottleneck receivers) and overcome the independent loss phenomenon. Loss notification can be piggybacked to the ACK/NAK feedback, and have aggregation/suppression mechanisms that are similar to, but distinct from, the reliability feedback. We show that even for fairly small multicast groups, the effect of augmenting our loss notification mechanism to existing ACK-based and NAK-based reliable multicast protocols is very significant in terms of throughput. As the size of the multicast group grows, the percentage improvement in the throughput achieved using our mechanism progressively improves. The rest of the paper is organized as follows: Section 2 presents the motivation for loss notification. Section 3 describes the simple idea of our mechanism and the operation of the loss notification mechanism in the context of both ACK-based and NAK-based reliable multicast. Section 4 presents initial simulation results illustrating the performance

2 improvements achieved using loss notification. Section 5 describes related work and Section 6 summarizes the paper. II. INDEPENDENT LOSS PROBLEM p p p 1 - (1 - p) n... r r 1 n split connection p p r r 1 n... data retransmit loss notification loss notification Independent Loss Independent Loss Independent Loss loss probability p loss probability p loss probability p < p n receivers (a) n < n receivers (b) n receivers (c) Figure 1: Figure (a) illustrates the independent loss problem. Figure (b) shows how it can be alleviated by breaking up the multicast tree, at the expense of destroying the end-to-end semantics of the multicast protocol. Figure (c) shows how to alleviate the problem by using local servers in addition to, rather than replace, the end-to-end semantics. The motivation for considering these approaches is to solve the independent loss problem merely by intelligent tree management without requiring any special congestion control mechanisms. Clearly, the approaches described above are only of limited use. The problem of independent packet losses in multicast communication has also been referred to in literature as the drop-to-zero-problem or the loss path multiplicity problem [7, 8]. The problem can be simply stated as follows: even if the packet loss probability on an individual path from the sender to a receiver is small, when there are multiple such paths in the multicast tree, the perceived (aggregate) loss probability at the sender can become very large as the number of the paths increases. Consider a simple example of a multicast tree with n independent paths where each path has a packet loss probability p, where 0 < p 1 (see Figure 1.a). In this case, the aggregate packet loss probability p 0 that the sender will perceive is 1? (1? p) n, and p 0! 1 as n! 1. Consider that the sender uses a linear increase/multiplicative decrease congestion control algorithm (LIMD) [10]. For such algorithms, it is well known that the average sending rate is inversely proportional to the square root of the mean loss probability, i.e. r / 1= p p. Now, if the mean loss probability on a path is p and there are n independent paths, the ideal multicast sending rate should be / 1= p p while in fact, the actual multicast sending rate is / 1= f1? (1? p) n g. As p becomes small, f1? (1? p) n g! np, and the actual multicast sending rate / 1= p np. In other words, the multicast sending rate degrades by a factor of the square root of the number of independent loss paths. It has been reported that most of the losses in the MBONE, for example, occur near the receivers [11]; in this case, for a multicast group of 100 receivers, the multicast sending rate may degrade by up to an order of magnitude from the ideal multicast sending rate. The independent path loss problem is thus a very serious issue for scalable single-rate multicast protocols. An immediate first-cut solution to this problem without requiring any new mechanisms is to break up the multicast tree into a forest of trees, such that each leaf of the top-level multicast tree that is rooted at the sender is itself the root of a subtree (i.e. it becomes a local server) that spans a subset of the receivers (see Figure 1.b). While this can reduce the number of independent paths on each tree, splitting the tree into multiple subtrees violates end-to-end reliability, receiver synchronization, and the single rate semantics of the multicast protocol. If we wish to preserve the original semantics of the multicast protocol and still augment it with local retransmission, then it is possible for a local server to send data packets in response to a loss notification from a receiver but still forward the loss notification upstream (see Figure 1.c). Augmenting end-to-end retransmissions with local retransmissions can help to reduce, but not eliminate, the problem of independent losses because in the worst case, the sender will still react to the aggregate of the loss notifications. In summary, we want the sender to react to all loss notifications for the purposes of providing end-to-end reliability, but only some of the loss notifications for the purposes of multicast congestion control. This clearly calls for at least some enhancement to the basic multicast congestion control mechanisms. There are several possible solutions to this problem, and we briefly review some of the contemporary approaches in Section V after describing our approach in Section 3. III. LOSS NOTIFICATION MECHANISM In this section, we describe the implementation of the loss notification mechanism in both ACK-based and NAK-based frameworks. It is important to note that we are not trying to develop a new multicast congestion control algorithm per se in this paper; rather, we are trying to design a mechanism that enables the sender to determine for which losses it must invoke the existing multicast congestion control algorithm. While the loss notification mechanism does not really care what congestion control algorithm is being used, it has been argued that popular linear increase/multiplicative decrease (LIMD) unicast congestion control paradigm is also suitable for the multicast environment [13, 14, 15]. Thus we model the congestion control at the sender to be LIMD that operates as follows: the sender periodically (once every epoch) invokes the congestion control algorithm. If the loss notification mechanism tells the sender that there has been a significant loss in the last epoch, the sender decreases the sending rate by a multiplicative constant (0.5); otherwise it increases the sending rate by an additive constant (1). A. Solving the Independent Loss Problem Using Loss Notification The approach we explore in this paper is very simple. We know that the sending rate of a multicast connection can be no faster than the sustainable rate of the slowest receiver. In a fluid model, the instantaneous max-min fair share for a single rate multicast session at any time is exactly equal to the instantaneous max-min fair share of the connection from the sender to the slowest receiver at that time. In the packet model, due to buffering at intermediate routers, it is acceptable and even desirable for rate of the multicast session to be higher than the instantaneous minimum of the fair shares over all receivers, so long as the rate is no faster than the sustainable rate of the slowest receiver over a short time duration (the precise analytical characterization of the relationship between the ideal multicast session rate and the max-min fair shares of the receivers is dictated by several factors such as buffering in the network, round-trip times, etc. and is a part of ongoing work). This points to the fact that the sender must react to the maximum of the packet losses observed among all its receivers in the recent past. The first cut solution is for each receiver to send the total number of packet losses observed from the start of the connection as its loss notification to the sender. The sender can then react only when the maximum feedback that it sees increases. Of course, we know that this simplistic approach will not work for two reasons: (a) as the number of receivers increases, the sender will be inundated with loss feedback, and (b) the sender must only take into account losses in the recent past and not from the start of the connection. The first point calls for aggregation/suppression of loss notification feedback and is considered in this subsection. The second point is considered in the next subsection. 1) Loss Notification in the ACK-based Framework In the basic ACK-with-aggregation approach, multicast routers in the tree [6] or designated receivers [1] are responsible for aggregating cumulative ACKs as they progress upstream

3 from the receivers to the sender. Aggregation involves computing the minimum of the cumulative ACKs from all the children, and forwarding this value to the upstream multicast router. Similar to ACKs, loss notification can be aggregated by taking the maximum of the loss notifications from all the children and propagating it upstream. The loss notification from a receiver contains the total number of packets lost from the start of the connection to the current time, and is generated periodically (at the start of each epoch, where the epoch marks the frequency of sending loss notifications but epochs across receivers need not be synchronized). Loss notifications can be piggybacked on ACKs, and are aggregated as they propagate upstream. The loss notification received by the sender is thus the maximum of the loss notifications over all receivers in an epoch. At the sender, if the loss notification mechanism detects an increase in the loss feedback over the previous feedback, then it triggers a congestion response according to congestion control algorithm (e.g. multiplicative decrease); otherwise it triggers a no congestion response (e.g. additive increase). 2) Loss Notification in the NAK-based Framework In the basic NAK-with-suppression approach, when a receiver detects the loss of a packet, it waits for a random time period (upperbounded by a timeout value) to listen for NAKs corresponding to the lost packet initiated by some other receiver, and then multicasts a NAK to the multicast group (including the sender) for the packet if it does not hear a NAK in the meantime. Any receiver that hears the NAK and has lost the same packet suppresses its own NAK. When the sender receives a NAK, it knows that at least one receiver did not receive the packet, and retransmits the packet. Similar to NAK suppression, we can achieve loss notification suppression. Once every epoch, the receiver with the largest loss notification from the previous epoch multicasts its updated loss notification to the multicast group (including the sender). Any receiver whose loss notification is not greater than the advertised value suppresses its own loss notification. A receiver whose loss notification is greater than the advertised value backs off for a random time (upper bounded by a timeout) and then multicasts its own loss notification if all the advertised notifications it has heard in the meantime are smaller than its own value. The loss notification mechanism at the sender maintains the largest loss notification heard by it in each epoch, and at the end of an epoch (epochs need not be synchronized across hosts) triggers a congestion response according to the congestion control algorithm (e.g. multiplicative decrease) if the maximum loss in the current epoch is larger than in the previous epoch; otherwise it triggers a no congestion response (e.g. additive increase). Thus we see that achieving the aggregation or suppression of loss notification similar to ACK-aggregation and NAK-suppression is a straight-forward task, and prevents the sender from getting inundated with loss notifications as the number of receivers increases. At the same time, it enables the sender to react to the maximum loss among all receivers, rather than aggregate loss summed over all receivers. Furthermore, it can work with different congestion control algorithms (both rate-based and window-based), and enables a significant improvement in the throughput of the multicast session as the number of receivers in the multicast group increases. B. Distinguishing Serial Losses from Parallel Losses The key remaining issue is to adjust the loss notification mechanism described above to account only for loss notifications over the recent past as opposed to loss notifications from the start of the connection. Consider a simple case with one sender and two receivers in a multicast group, as shown in Figure 2. Each receiver experiences 4 packet losses. For this simple scenario, consider the two loss feedback patterns in Figure 2.a and Figure 2.b (in (a) (b) loss at R1 feedback to sender feedback to sender epoch feedback from receivers feedback to sender feedback from receivers loss at R2 Figure 2: This figure illustrates parallel and serial loss feedback from two receivers to a sender in a multicast group. Figure (a) is the upper axis and losses from both receivers occur in parallel in epochs 1, 3, 4 and 7. Consequently, the sender receives 4 loss indications. Figure (b) is the lower axis and losses from the receivers occur in series. Receiver 1 observes losses in epochs 1-4, and receiver 2 observes losses in epochs 5-8. Thus 8 loss indications are sent to the sender. this example, the feedback indicates individual losses rather than cumulative loss notifications). In each case, when and how much should the loss feedback to the sender be? Intuitively, the losses in Figure 2.a occur in parallel, hence we expect the loss feedback to the sender to be 4, as shown in the figure. On the other hand, the losses in Figure 2.b occur in series, hence we expect the loss feedback to be 8, as shown in the figure. From the illustration above, it seems intuitively clear that the sender should get a loss feedback that is the maximum among all receivers for parallel losses, and the aggregate over all receivers for serial losses. The problem is that it is very difficult to characterize a given loss pattern as being parallel or serial. Moreover, the boundary between parallel losses and serial losses is somewhat arbitrary and will depend on several factors such as the buffering in the network, round trip times to the receivers, etc., but no single host has the global knowledge of these factors. Epoch boundaries can be used as a first cut classifier, i.e. all losses in the same epoch are parallel and across epochs are serial. The problems with this approach are two-fold: (a) epochs need not be synchronized across hosts, and (b) since epochs are initially used for controlling the frequency of sending feedback (and reacting to feedback), it may be inappropriate to use the same periodicity to determine parallel/serial losses. Nevertheless, we believe that epochs can be used in classification, as described below. In order to take into account both serial and parallel losses, we can use a running average of the number of packet losses in an epoch. Let li j be the number of losses observed by receiver i in epoch j, and let li be the running average of the loss notification. Then, at the end of each epoch j, each receiver updates the running average as follows: li li + li j The sender maintains the maximum loss notification L j corresponding to epoch j. At the end of epoch j, the sender performs the following computation: L j maxif lig If (L j > L j?1 ) detect congestion else detect no congestion Of the two steps described above, the first one is achieved through the aggregation or suppression of loss notifications, while the second one is explicitly computed by the sender. In this step, the sender also scales back the loss notification information collected over the last epoch by the same factor, so that if there are no losses in the current epoch, the feedback in the current epoch matches the scaled back value in the last epoch; thus only significant packet losses are detected. The values of the constants and play a crucial role in determining which losses are classified as parallel and which losses are classified as serial. In particular, = 1 and = 1 corresponds to counting losses from the start of the connection, while = 0 and = 1 corresponds to reseting the loss value every epoch. Setting appropriate values for and based on the session dynamics is a very interesting problem that is ongoing work. In a related work [11], Yajnik et al. observed that the packet loss pattern in the MBone (or the multicast backbone)

4 has very small time and spatial correlation and most of the packet loss bursts are short (one or two packets). In our terminology, most of the losses in such an environment could be classified as parallel. In the extreme case when all losses are parallel, then the running average approach becomes equivalent to the simplistic approach of just maintaining a cumulative loss notification at each receiver (i.e. = 1; = 1). A key point to note is that the mechanisms described in this section are independent of the specific reliability scheme and congestion control algorithm. We believe that they can be used to augment any reliable multicast protocol, and even unreliable or semi-reliable multicast protocols. In effect, we believe that loss notification is a simple yet effective mechanism that can be used to augment any single-rate multicast protocol to solve the problem of independent packet losses across multiple receivers. In the next section, we evaluate the performance enhancements obtained using our mechanism. IV. PERFORMANCE EVALUATION We now evaluate the performance of the proposed loss notification mechanism using the ns2 simulator [12]. We have incorporated the loss notification mechanism in the simulation codes of IRMA [6] (for the ACK-based scheme) and SRM [5] (for the NAK-based scheme). As a background information, in IRMA, the sender adopts the flow control and congestion control of TCP, which employs a modified LIMD congestion control: the sender increases the congestion window by one packet when there was no packet loss in the last congestion window but decreases the congestion window by half when it detects packet losses in the last congestion window. In SRM, maintaining traffic under the connection capacity is not a transport issue. The designers of SRM assume that connection capacity is determined by a separate session management protocol or the congestion control is performed by the application. Thus we have implemented an adaptive ns application, which periodically probes the state variable of the SRM and determines the sending rate of the next epoch according to the variable. When an SRM agent observes request packets (or NAKs), it sets the state variable which is read by the application at the end of each epoch. After reading the variable, the application clears the variable and determines the new sending rate using LIMD congestion control. For simplicity, we used the basic SRM without adaptive adjustment of random timer algorithms or local recovery mechanism in the simulation. We call this integrated congestion control mechanism (of SRM and the adaptive application) as SRM in this section for simplicity. These basic congestion control schemes of IRMA and SRM were extended by the loss notification mechanism proposed in this paper. We call IRMA and SRM with these extensions IRMA+ and SRM+, respectively. One of the interesting problems with the loss notification mechanism is how to effectively distinguish the serial losses from parallel losses, and vice versa. A comprehensive analysis to this problem is an ongoing work. In this paper, we present the result with = 1 and = 1, i.e. all losses in the network are assumed to be parallel. Of course this simplifying assumption may not be sufficient to handle all types of loss patterns and transmission scenarios. However, we find that even this simple scheme is suitable for addressing the various scenarios simulated in this section and results in performance improvement. In each test, we sent packets with size of 1 KB for 100 seconds and measured the effective throughput at the receivers. In IRMA, TCP Reno congestion control mechanism was employed at the sender. The parameters for SRM (e.g. C 1 ; C 2 ; D 1 ; D 2 ) were adopted from [5]. We model network congestion as random packet loss on the link. Local recovery mechanisms were disabled in both protocols to assess the net effect of the loss notification mechanism. In addition to IRMA, IRMA+, SRM, and SRM+, we also present the performance of TCP unicast from the sender to the farthest receiver (which is the most constrained receiver) as a reference, which is the performance upperbound of the single rate reliable multicast [6]. We now present the simulation results in four network topologies with progressively increasing complexity: simple star, two level binary tree, 7 and 15 receiver asymmetric trees (See Figure 3). In all cases the link bandwidth were set to 3 Mbps and one-way link delay was set to either 5 msec unless otherwise noted. Test 1. Simple binary tree In this test, we compare the performance of TCP, IRMA, IRMA+, SRM, and SRM+ in the simplest configuration as shown in topology 1 in Figure 3. We measured the throughput of each protocol with various (independent) packet loss probability on the level 1 links. Table 1 summarizes the result. Table 1 loss TCP IRMA IRMA+ SRM SRM+ 0% % % We observe two major results: First, when there is no packet loss, all the protocols perform comparably; and second, when the packet loss probability of links is non-zero, the loss notification mechanism improves the throughput (by 11 % in IRMA and 13 % in SRM on the average). Note that our goal is not to compare the performance of IRMA and SRM in this paper; but we are interested in the performance improvement resulting from the loss notification mechanism in each case. The poor relative performance of SRM in this test must be mainly due to the conservative parameter selection and disabling adaptive timer managements. We expect SRM performance to improve with fine parameter tuning and the adaptive timers adjustment [5]. The performance gap between TCP and IRMA+ is because IRMA+ cannot resolve all serial/parallel losses correctly. In other words, the simple mechanism with = 1; = 1 reacts wrongly when losses are in series occasionally. Test 2. Two level binary tree In this test, we measured the performance of each protocol in a network configuration as shown in topology 2 in Figure 3 with various independent link loss rates. We tested 6 different cases: (a) no loss on the links, (b) only level 2 links have 0.3 % loss rate, (c) the level 1 links have loss rate 0.1 % and the level 2 links have 0.2 %, (d) both level 1 and level 2 links have loss rate 0.15 %, (e) the level 1 links have loss rate 0.2 % and the level 2 links have 0.1 %, and (f) only level 1 links have 0.3 % loss rate. In other words, we tried to measure the effect of the location of packet losses on the efficacy of the proposed scheme. Table 2 summarizes the result. Table 2 case TCP IRMA IRMA+ SRM SRM+ a (0:0) b (0:0.3) c (0.1:0.2) d (0.15:0.15) e (0.2:0.1) f (0.3:0) The behavior of TCP is mostly independent of the location of packet loss which is expected. For IRMA and SRM, we expect the performance to degrade as the location of packet losses moves away from the sender (i.e. from level 1 to level 2 links) since it increases the effective loss rate by making most packet loss to be independent and serial. We observe this effect

5 topology 1 topology 2 topology 3 topology 4 level Figure 3: Network topologies for the simulations 1 4. The circles denote end hosts and the squares denote multicast routers, where the gray nodes are the senders and white nodes are the receivers. All links have 5 msec delay except topology 4 where the links have 10 msec delay. clearly in IRMA whose throughput varies from 865 Kbps to 1.9 Mbps. But in case of SRM the effect is less prominent. This may be due to the NAK suppression mechanism of SRM which reduces the generation of NAK ideally to a few packets per loss. Thus, in case of IRMA, we observe a large variance in the improvement of performance by the introduction of IRMA+: 47 % (case f) 150 % (case b). On the other hand, the variance of the improvement by SRM+ is not very large: 44 % (case b) 73 % (case f). In any case, we observe that IRMA+ and SRM+ improve the basic congestion control of IRMA and SRM. We also observe that with the loss notification mechanism the effect of congestion location is less than the case without one. Test 3. Asymmetric topology We now consider an asymmetric tree configuration with 7 receivers as shown in topology 3 in Figure 3. In this configuration, we performed five tests varying the independent packet loss probability on each link. There are five cases: (a) no packet loss on the links, (b) the loss probability of the level 1, level 2, level 3 links are 0.1 %, 0.3 %, and 0.5 %, respectively, (c) the loss probability of the level 2 links is 0.4 % and that of level 3 links is 0.5 %, (d) the loss probability of the level 1 links is 0.1 % and the other links are error-free, (e) the loss probability of the level 2 links is 0.3 % and the other links are error-free, and (f) the loss probability of the level 3 links is 0.5 % and the other links are error-free. Table 3 summarizes the result. Table 3 case TCP IRMA IRMA+ SRM SRM+ a (0:0:0) b (0.1:0.3:0.5) c (0:0.4:0.5) d (0.1:0:0) e (0:0.3:0) f (0:0:0.5) In this test we are interested in how the loss probability and its location affect the performance of the loss notification mechanism in an asymmetric setting. In terms of location, essentially we observed the same trend as the previous test: in case of IRMA, the improvement due to IRMA+ becomes more significant as the location of the losses move down the multicast tree, e.g 22 % (case b) 66 % (case c); however, the variance in the performance of SRM+ is rather small. We also observed that performance improvement is greater with larger loss probability, e.g. performance improvement of IRMA+ in case d is 5 % whereas in case e it is 87 %; similarly the performance improvement of SRM+ in case d is 51 % and in case e is 97 %. We conjecture the proposed loss notification mechanism is suitable for the reliable multicast protocols on the MBone, which has been reported to have very low time and space correlations and where most of the packet losses are localized near the leaves of multicast tree [11]. Test 4, Larger configuration We now briefly illustrate that the performance improvement we have observed in the preceding tests is still valid in a slightly more complex network configuration as shown in topology 4 in Figure 3. Though we admit that it is still very simplistic model of real multicast environments, and hence the simulation result presented in this section is still far from comprehensive, we believe the performance results presented in this paper give an insight on the advantage of the simple loss notification mechanism. We simulated three cases: (a) all links are error-free, (b) only the level 1 links have the independent loss probability of 0.1 %, and (c) only the level 3 links have the loss probability of 0.1 %. The effective throughput of each protocol is presented in Table 4. Table 4 case TCP IRMA IRMA+ SRM SRM+ a (0:0:0:0:0) b (0.1:0:0:0:0) c (0:0:0.1:0:0) In this case, we observe a different trend of performance improvements in this test from the previous case: IRMA+ still greatly improves the performance when the location of packet losses is close to the receivers and losses are mostly independent, and so does SRM+. In case when the congestion is located near sender (case b), IRMA+ and SRM+ only slightly improves the performance of IRMA and SRM: 13 % in IRMA+ and 7 % in SRM+, respectively. However, when most losses happen at level 3 links the performance improvement is much greater since most receivers are connected via the level 3 links and hence most losses are independent. In this case, the performance of plain IRMA and SRM degrades severely due to the independent packet loss problem. From the result, we observe that IRMA+ and SRM+ handle the problem effectively improving the performance of the protocols by 339 % and 143 %, respectively. Overall, we observed that: (a) the proposed loss notification mechanism handles the independent packet loss problem effectively; and (b) the proposed mechanism scales well in terms of network complexity; in fact the percentile performance improvement increases with the network complexity. Essentially, the loss notification is most effective when the independent losses are located close to the receivers, which is the common case of MBone loss characteristics observed from the empirical study [11]. We observe this trend in all the test cases with IRMA+. With SRM+, the trend was not very clear in small network configurations but became obvious with a larger network topology.

6 V. RELATED WORK In this section, we review existing approaches to overcome the independent loss problem in a multicast environment. Montgomery [13] proposed flow and congestion control mechanisms called loss tolerant rate controller (LTRC) in the reliable multicast context. LTRC reduces the sending rate only when the loss rate reported by some receiver is greater than a threshold. In addition, it does not reduce the sending rate again within a certain time period to make sure that the sending rate decrease is not too aggressive. The performance of LTRC thus is closely dependent on the choice of the threshold and the time period: if the time period is large, then the sending rate decrease may be too slow and the algorithm may not be responsive; otherwise, the adaptation of time period may not be effective. DeLucia et al. [14] proposed a multicast congestion control mechanism which uses the concept of representatives, a small number of receivers that provide congestion (or loss) feedback. The basic idea is to reduce the number of congestion feedback by ensuring only representatives provide congestion feedback on behalf of all the receivers. It is sender s job to choose which receivers to be in the representative set based on the recent feedback. The rate adaptation algorithm adopted by the sender is a variation of LIMD congestion control with TCP Vegas-like delay estimation. The performance, of course, is highly dependent on the choice and the effectiveness of the representatives [8]. Random listening algorithm (RLA) [15] tries to estimate the number of congested receivers (say n) in the multicast group, and react to the congestion feedback with the probability of 1=n. The sender s congestion control algorithm is basically a rate-based modified LIMD (decrease with probability) and updated on the basis of the SACK-like feedback from the receivers. A receiver is considered to be congested if the loss probability is greater than a certain threshold level presented in the paper. The RLA was shown to be essentially fair to TCP in terms of the bandwidth usage. Bhattacharyya et al. [8] formulated the independent loss problem in detail and presented a general framework called filtered loss indication-based congestion avoidance (FLICA) for various LIMD-based multicast congestion control algorithms (including [13, 14]). They provided analysis and simulation results on different filter-based algorithms and concluded that filter algorithm can only alleviate the level of congestion but cannot handle all the problems. They also presented the description of an ideal multicast congestion control algorithm that can trace the worst receiver in the multicast group at all time and showed that it can achieve desired fairness properties. The algorithm is surely effective but at a relatively high cost: the sender needs to keep track of the congestion level of all the receivers. Approaches mentioned above were typically proposed in the context of NAK or SACK-based reliable multicast. In ACK-based protocols, researchers typically tried to handle multicast congestion control problem using local recovery, i.e. the retransmissions of lost packets are handled by local repair servers near the receivers without waiting for the sender to retransmit [1, 6, 7]. Some approaches perform local recovery as an enhancement to basic end-to-end retransmission [6] and the others adopted a split-connection reliability semantics where local servers themselves act as the sender [1, 7]. The loss notification mechanism proposed in this work can be viewed as a simple, efficient, and low overhead instantiation of a filter in the FLICA framework. However, it is more robust than RLA and representative schemes, and it is applicable to both NAK and ACK based protocols. We are not trying to develop a new multicast congestion control algorithm; instead, we our goal is to determine when it is appropriate to trigger the congestion control algorithm in the presence of independent losses at different receivers. VI. SUMMARY As the number of multicast receivers and links in the network increases, the number of independent losses also increases. A single-rate multicast sender must retransmit upon every loss feedback to achieve reliability but does not need to react to every loss for congestion control. Therefore, decoupling of congestion control and reliability mechanisms is necessary in a reliable multicast environment. To this end, we proposed a simple and efficient loss notification mechanism that can augment both ACK-based and NAK-based reliable multicast. A fortuitous consequence of this decoupling congestion control from reliability is that we can also support congestion control for single-rate unreliable or semi-reliable multicast protocols using the same mechanism. The basic idea of loss notification is to trigger congestion response only to the maximum of the losses experienced by any receiver rather than the sum of the losses experienced by all receivers. This takes care of the independent loss problem, and enables the single-rate multicast congestion control algorithm to closely approximate the ideal rate, i.e. the fair share of the bottleneck receiver. We have implemented the loss notification mechanism in both ACK-based and NAK-based protocols. Initial performance evaluation shows that loss notification is an effective approach to the independent loss problem, and that it is robust and easy to incorporate. Even though the proposed loss notification mechanism is very simple, tuning it appropriately to obtain the optimal performance is still a challenging task, and is the focus of our ongoing work. VII. REFERENCES [1] J. C. Lin and S. Paul. RMTP: A Reliable Multicast Transport Protocol. Proceedings of IEEE INFOCOM, March [2] A. Koifman and S. Zabele. RAMP: A Reliable Adaptive Multicast Protocol. Proceedings of IEEE INFOCOM, March [3] H. W. Holbrook, S. K. Singhai, and D. R. Cheriton. Log- Based Receiver-Reliable Multicast for Distributed Interactive Simulation. Proceedings of ACM SIGCOMM, September [4] R. Talpade and M. H. Ammar. Single Connection Emulation (SCE): An Architecture for Providing a Reliable Multicast Transport Service. Proceedings of the 15th IEEE International Conference on Distributed Computing Systems, June [5] S. Floyd, V. Jacobson, C-G Liu, S. McCanne, and L. Zhang. A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. IEEE/ACM Transactions on Networking, November [6] K.-W. Lee, S. Ha, and V. Bharghavan. IRMA: A Reliable Multicast Architecture in the Internet. Proceedings of IEEE INFOCOM, March [7] I. Rhee, N. Balaguru, and G. N. Rouskas. MTCP: Scalable TCPlike Congestion Control for Reliable Multicast. Proceedings of IEEE INFOCOM, March [8] S. Bhattacharyya, D. Towsley, and J. Kurose. The Loss Path Multiplicity Problem in Multicast Congestion Control. Proceedings of IEEE INFOCOM, March [9] B. DeCleene, S. Bhattacharyya, T. Friedman, M. Keaton, J. Kurose, D. Rubenstein, and D. Towsley. Reliable Multicast Framework (RMF) Specification. A white paper, University of Massachusetts, March [10] V. Jacobson. Congestion Avoidance and Control. Proceedings of ACM SIGCOMM, August [11] M. Yajnik, J. Kurose, and Don Towsley. Packet Loss Correlation in the MBone Multicast Network. Proceedings of IEEE GLOBECOM, November [12] On-line Document. Network Simulator. [13] T. Montgomery. A Loss Tolerant Rate Controller for Reliable Multicast. Technical Report: NASA-IVV , August [14] D. DeLucia and K. Obraczka. A Multicast Congestion Control Mechanism for Reliable Multicast. Proceedings of IEEE Symposium on Computers and Communications, June [15] H. A. Wang and M. Schwartz. Achieving Bounded Fairness for Multicast and TCP Traffic in the Internet. Proceedings of ACM SIGCOMM, September 1998.