Computer Science Technical Report Archive

USC Computer Science Technical Reports, no. 743 (2001)

(USC DC Other)

USC Computer Science Technical Reports, no. 743 (2001)

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content 1 Fairness Analysis of Multicast Congestion Control: A Case Study on pgmcc Karim Seada, Ahmed Helmy Electrical Engineering-Systems Department University of Southern California, Los Angeles, CA 90089 {seada,helmy}@usc.edu Abstract Fairness to current Internet traffic, particularly TCP, is an important requirement for new protocols in order to be safely deployed in the Internet. This specifically applies to multicast protocols that should be deployed with great care. In this paper we provide a detailed fairness analysis for a multicast congestion control scheme ‘pgmcc’ [11] when running with competing TCP flows. We try to find those configurations and scenarios in which fairness is violated, and propose modifications for pgmcc mechanisms to improve its fairness and performance. Using simulation we found that in some configurations pgmcc is unfair to TCP. Our analysis shows that such unfairness is due to differences in handling packet losses, timeouts, and due to NACK suppression if network support is used. pgmcc also suffers from performance degradation when acker switching happens between receivers with large differences in delay. To improve fairness of pgmcc, we suggest the addition of an adaptive timeout mechanism similar to that used in TCP. Keywords Reliable multicast, congestion control, fairness, simulation, TCP, pgmcc. 1 Introduction In this paper we perform a fairness analysis for pgmcc. pgmcc [11] is a single rate representative-based multicast congestion control scheme that is designed to be fair with TCP. In addition to TCP-friendliness it should provide scalability and fast response. To achieve fast response while retaining scalability a group representative, called the acker, is selected and a tight control loop is run between it and the sender. In [11] pgmcc has been presented and a set of preliminary experiments have been performed. The initial results show that pgmcc can be safely deployed in the Internet and that it is a good choice for providing TCP-friendliness. In our work we conduct more experiments and investigate more deeply to find those configurations and scenarios in which fairness is violated. We aim to have a better understanding of multicast congestion control protocols in order to assess their safety and their effects on other types of traffic, especially TCP. Based on our study we propose some modifications to the mechanisms of pgmcc to improve its fairness and performance. 2 Our fairness analysis is motivated by several factors. First, fairness especially with regard to TCP is an important criteria required by IETF [8] in order to accept any multicast congestion control mechanism and the analysis of fairness is important for many kinds of protocols that may compete with TCP. Second, pgmcc is an interesting scheme that captures many of the phenomena of representative-based multicast congestion control protocols. The results obtained here may be extended for similar types of protocols. Finally, the switching of the acker in pgmcc is still a new idea that needs further investigation. Our approach attempts to relate overall protocol behavior to individual protocol mechanisms by evaluating carefully selected scenarios. In our experience this often points to possible mechanistic modifications to improve the protocol performance. In this paper, we arrive at these scenarios based on our intuition and understanding of the protocol mechanisms. Ultimately, however, we aim to develop a methodology, based on the STRESS framework [6][7], to systematize this scenario selection process. In our on- going and future work, we address this issue for the classes of multicast congestion control mechanisms that are similar to pgmcc. We have performed several experiments using simulation. In the experiments pgmcc is implemented on top of the PGM [13] multicast transport protocol. The experiments compare the throughput of pgmcc with that of TCP in several configurations. Some configurations are simple just to show the main differences between pgmcc and TCP, with different versions of TCP examined. Other configurations have receivers with different combinations of loss ratios and delays. Losses can be either independent or correlated due to congestion. The effect of network support (NACK suppression) on congestion control is also shown. The results obtained show that pgmcc is not always fair to TCP due to differences in handling timeouts and the behavior with regard to packet losses. NACK suppression also affects fairness in some configurations. The effect of acker switches on pgmcc performance is also examined, where we show that the existence of receivers with different delays can cause performance degradation. Some general issues such as the meaning of fairness, and the appropriate way to achieve it will be considered. We provide some suggestions for improving the fairness and performance. Our main suggestion is the use of an adaptive timeout mechanism similar to that used in TCP, as we will see this is required for solving main fairness issues. A simple solution for dealing with the unfairness due to network support is provided by adding some randomness in the suppression of NACKs. Solving the performance problems caused by acker switching requires careful handling of the ACKs received by the sender after a switch. The rest of this paper is outlined as follows. In section 2 we provide a general background about multicast congestion control and a brief description of pgmcc. In section 3 we present the issues we are going to examine. In section 4 we show our results and the analysis for it. Conclusions and future work are presented in section 5. 3 2 Related Work Related work in general lies in the fields of reliable multicast and multicast congestion control. In this section we start with a general background about these issues and then provide a brief description for pgmcc. 2.1 Background Reliable multicast has been an area of extensive research due to the increasing number of emerging applications that rely on it. Most of the reliable multicast protocols were just a general solution for group communication, but they do not implement any explicit form of congestion control [9][3]. One of the most important criteria that IETF [8] requires for reliable multicast protocols is to perform congestion control. The protocol should be safe to deploy in the current Internet and should not starve other competing flows. Since most of the traffic on the Internet is TCP, then the protocol should be TCP-friendly [5], and should behave similar to TCP by decreasing its rate in the case of congestion. TCP- friendly means that the protocol sessions should have the same effect on competing TCP flows as if they themselves were TCP sessions. Congestion control for reliable multicast is not an easy task as there are a lot of design decisions, challenges and trade-offs. One of the most challenging problems is how to provide feedback for the sender while achieving scalability and responsiveness. Usually scalability and responsiveness are two conflicting tradeoffs. For example, to have scalability some protocols use timer suppression mechanisms, which reduces their responsiveness. On the other hand, to have fast response some protocols can use prompt acknowledgements from the receivers, which decreases their scalability. One idea that attempts to solve both the scalability and responsiveness problems is the use of representatives [2]; a small dynamic group of receivers that provide feedback. This is based on the assumption that only a small set of bottleneck links will cause the majority of congestion problems. Based on the feedback received from the representatives, the source will adjust its rate. If new congestion appears in the network then new representatives should be selected, so that the representative group changes depending on network conditions. The main problem associated with such approach is the dynamic selection of a good set of representatives. Devising a scalable efficient selection mechanism with appropriate reaction to changes in representatives is a challenging problem. 2.2 pgmcc pgmcc [11][12] is a single-rate multicast congestion control scheme that is designed to be TCP-friendly. It supports both scalability and fast response. To achieve fast response while retaining scalability a group representative called the acker is selected and a tight control loop is run between it and the sender. It is called the acker because it is the receiver that sends the ACKs. Other receivers can send NACKs when they lose packets depending on the transport protocol. pgmcc has been used to implement congestion 4 control in PGM [13] 1 . A sample scenario for pgmcc is shown in Figure 1. The acker is the representative of the group. It is chosen as the receiver with the worst throughput. A window-based TCP-like controller based on positive ACKs is run between the sender and the acker. Since the acker is the receiver with the worst throughput, this ensures that the protocol will be TCP-friendly. The feedback in pgmcc is provided in receiver reports that are used by the sender to estimate the throughput. They are embedded into the NACKs and ACKs and contain the loss rate and information for computing an estimate for the round trip time (RTT) of the sending receiver. The RTT can be evaluated by using timestamps or sequence numbers. The loss rate is computed using a low pass filter to avoid oscillations. Perhaps the most critical operation of pgmcc is the acker election and tracking. As mentioned, the acker is selected as the receiver with the worst throughput. When another receiver with worse throughput send a NACK, an acker change can happen. A receiver that does not send NACKs is assumed to have no congestion problems, and will not be considered at all. Computation of throughputs depends on information sent by receivers and the TCP-like formula: where T is the throughput, RTT is the round trip time estimate and p is the loss rate. An acker switch happens from receiver j to receiver i if T(i) < c*T(j), where T(n) is the throughput computed by the sender for receiver n. c is a constant (0<c≤1) that is used during throughput comparison to dampen oscillations of acker selection when the difference between the current acker and the worst receiver is not large. There is a 32-bit field in the ACK called the bitmask, which indicates the receive status of the most recent 32 packets. This is included to help the sender deal with lost and out- of-order ACKs. 1 In [12] the authors state that pgmcc can be used with both reliable and non-reliable transport protocols. Figure 1: A sample pgmcc scenario p RTT T 1 α 1) The sender sends a packet 2) Packet lost by one receiver 3) The receiver sends NACK and the acker sends ACK 4) If the NACK is from a receiver worse than the acker, then it is designated as the new acker Sender Receiver acker Data NACK ACK 5 A window based congestion control scheme similar to that used by TCP is run between the sender and the acker. The parameters used are a window W and a token count T. W is an estimate for the number of packets in flight and has the same role as the TCP window, while T is used to regulate the generation of data packets by decrementing T for every packet sent and incrementing it for every ACK received. On packet loss W is cut by half and T is adjusted accordingly. A packet is assumed lost when it has not been acked in a number (normally three) of subsequent ACKs. W and T are initialized to 1 when the session starts or after a stall when ACKs stop coming in and a timeout occurs. The congestion control here is more conservative than that used by TCP. For example the exponential opening of the window (slow start phase) is limited to a small window size. The reason is that the exponential opening performed by TCP is considered very aggressive and there are still fears of deploying such mechanisms for multicast protocols over the Internet. pgmcc has a different flow/reliability window than that used for congestion, to decouple congestion control from retransmissions and so it can be used with both reliable and non- reliable protocols. Some multicast transport protocols depend on router support for feedback aggregation. For example in PGM routers the first instance of a NACK for a given data segment is forwarded to the source, and subsequent NACKs are suppressed. This can have an effect on the operation of pgmcc. 3 Examined Issues In this section we discuss the issues studied. These issues cause fairness problems and the last point causes performance problems. At the beginning we use simple topologies to compare pgmcc to the different versions of TCP in very simple cases. This comparison helps us to understand the behavior of pgmcc and the subtle differences between it and TCP. We run pgmcc with Reno, New-Reno, and SACK [4]. New-Reno and SACK solve performance problems of TCP in case of multiple-packet loss and they reduce the number of timeouts. According to [10] timeouts have a significant impact on the performance of TCP. Timeouts constitute a significant fraction of the total number of loss indications and measurements have shown that in many cases the majority of window decreases are due to timeouts, rather than fast retransmits. According to that we suggest an adaptive timeout mechanism similar to that used in TCP to be used in pgmcc. Our results show that this improves pgmcc fairness. We investigate the performance of pgmcc when the receivers have different combinations of delay and loss rates (e.g. high loss, low delay vs. low loss, high delay). We examine the effect of independent losses and observe the behavior of pgmcc when a packet is lost and how retransmissions affect the operation of congestion control. In addition, we examine scenarios and topologies where more accurate throughput estimation may be needed. 6 We also examine losses due to congestion when the receivers have different combinations of delay and bandwidth bottlenecks. Congestion losses are more difficult to control than independent losses and they have different effects. We show the effect of network support and NACK suppression on the fairness of pgmcc. It is clear that NACK suppression can cause some problems, because a worse receiver can have its NACKs suppressed. According to the protocol designers this should cause no problems, since a worse receiver will send more NACKs and it is likely that one of them will reach the sender. As we will see in the results section, NACK suppression can shield the worst receivers from being chosen as ackers, especially when the receivers have different delays to the sender. One heuristic to ameliorate this problem is to keep track of loss ratios in the routers. However, we note that keeping loss ratios is not enough to solve this problem but the RTT should also be taken into account, although this increases memory overhead and processing in the routers. So, we propose to add randomness in the suppression of NACKs to increase the probability of worse receivers being chosen. We investigate the case when there are large differences in delay between receivers and acker switches happen between a low and far receiver. These switches decrease the performance of pgmcc in an unexpected way. Solutions to this problem do not seem to be easy. There is a field called bitmap provided in the ACKs that includes the state of the last 32 packets. This field should be used by the sender to deal with lost and out-of-order ACKs. As we will show, however, this has not proved to be enough to deal with the performance problems caused by these switches. 4 Results In this section we show the results obtained using the NS-2 simulator [1] to evaluate pgmcc and analyze its fairness with regard to TCP. The TCP version used is Reno, unless otherwise mentioned. For brevity, we only discuss those experiments leading to unfairness or performance degradation. For each experiment performed, we show the results obtained, and the interpretation and analysis of these results. The source models used in the simulation were FTP sources with packet size of 1400 bytes. The links had propagation delay of 1ms, and bandwidth of 10Mb/s, unless otherwise specified. The queues had a drop-tail discard policy and FIFO service policy, with capacity to hold 30 packets. In the topologies we use TS and TR to refer to TCP sender and TCP receiver, PS and PR to refer to pgmcc sender and pgmcc receiver, respectively. In the graphs we show the sequence numbers sent by the sender along the time. This has the same effect as showing the throughput. 4.1 Experiment 1: Timeouts In the first experiment we use the topology shown in Figure 2 to test the fairness of pgmcc with TCP in a very simple case, where we have only a single TCP session 7 competing with a pgmcc session over a bottleneck link (500Kb/s, 50ms). pgmcc has a number of identical receivers, so anyone of them could be the acker and their number should make no difference. Comparing the throughput of the TCP sender with the pgmcc sender we find in Figure 3 that both of them are so close to each other. At short intervals one of them can get a higher throughput and its window gets larger but soon they converge again and on average they are identical. Similar behavior is also observed between different TCP sessions. This is the same topology and results obtained in [11]. Acker changes and the order in which sessions start have no effect in this topology. The simulation run in Figure 3 is 300 seconds long. However, by extending the same experiment for a longer period (3000 seconds) we get the results in Figure 4. As we see in Figure 4, pgmcc is not fair to TCP and it gets higher throughput which becomes clear as the period gets longer. The reason for this behavior can be interpreted if we look more closely at how pgmcc works in comparison to TCP. pgmcc times out after a stall when the ACKs stop coming in, and a timeout expires. But there are no specific information about that timeout value for pgmcc and how it is determined. Without timeout pgmcc reacts to congestion by cutting the window in half similar to fast recovery in TCP. TCP on the other hand adjusts its timeout value depending on the measured RTT and the standard deviation of the measured RTT values. Figure 2: TCP session competing with pgmcc session over a bottleneck link Figure 3: Throughput of pgmcc vs. TCP over a short period Figure 4: Throughput of pgmcc vs. TCP over a longer period TS TR PS PR1 PR2 Congested Link PR3 TS: TCP Sender TR: TCP Receiver PS: pgmcc Sender PR: pgmcc Receiver 0 10000 20000 30000 40000 50000 60000 70000 80000 0 500 1000 1500 2000 2500 3000 Time Sequence PGM TCP 0 1000 2000 3000 4000 5000 6000 7000 8000 0 50 100 150 200 250 300 Time Sequence PGM TCP 8 Our explanation of the unfairness that is observed over long periods is due to these differences in handling timeouts. In this simulation the timeout is fixed to a relatively high value (4 seconds). In the first 300 seconds that is shown in Figure 3 no timeouts happen to TCP, this is the reason for equivalent throughput. But during the longer period, several timeouts happen. Since the timeout value of pgmcc is fixed to a relatively high value, it incurs fewer timeouts and slow start in comparison to TCP. By observing the window size changes in both of them we found that our explanation is correct and that pgmcc window is larger most of the time and it does not enter the slow start phase. We can see that in Figure 5 where pgmcc window is higher most of the time than TCP window. In Figure 6 we get a closer look over a shorter period, we see how TCP window size goes to ‘1’ several times while pgmcc window does not. We have also conducted several other experiments with changing the timeout value, we found that the results obtained depend heavily on this value. For example, if the timeout is set to a relatively small value this can cause TCP to have a much higher throughput. The appropriate value for timeout that achieves fairness depends on dynamic network conditions that change over time. This makes us believe that the timeout value of pgmcc should be adaptive and change over time similar to TCP. Furthermore TCP depends on ACKs totally for responding to the receiver, changing the window, entering fast recovery and entering slow start. If there are no more ACKs in flight coming due to a large number of losses (e.g. loss bursts) for example, this prevents TCP from entering fast recovery and it has to timeout. pgmcc, on the other hand, has another stimulant for sending retransmissions which is the NACK. The version used for TCP in this simulation is Reno. It has been reported that Reno suffers from performance problems when multiple packets are dropped from a window and a lot of timeouts happen according to that [10]. New-Reno and SACK are versions of TCP that solve these performance problems and reduce the timeouts [4]. By trying the same experiments with New-Reno and SACK we see in Figure 7 (both are almost the same) that pgmcc is much more fair with them. To improve the fairness with Reno we perform the same experiment with an adaptive timeout mechanism added to pgmcc. In this mechanism pgmcc uses an adaptive timeout Figure 5: Window size comparison of pgmcc and TCP Figure 6: Closer window size comparison 0 10 20 30 40 50 60 0 200 400 600 800 1000 Time Window Size PGM TCP 0 5 10 15 20 25 30 35 1500 1550 1600 1650 1700 1750 1800 Time Window Size PGM TCP 9 similar to that used in TCP and the reset of the timeout is controlled to be as close as possible to TCP Reno. It is reset only if there are no packets missing in the received bitmap, that is all ACKs are received in sequence. Because of differences in RTT between different ackers, after a switch a fixed timeout is used until the adaptive timeout for the new acker is computed. Figure 8 shows the result of pgmcc compared to TCP Reno after adding adaptive timeout, pgmcc is much more TCP-friendly in this case. 4.2 Experiment 2: Independent Losses In this experiment we intended to see different combinations of RTTs and loss rates and their effect on the protocol. Also it was set to show how accurate is the equation used for computing the throughput. According to [10] the simplified equation used for computing the throughput is for fast retransmission only and it does not take timeouts into account. It also overestimates the throughput for losses above 5% (this was pointed also in [11]). It is suitable only when loss rates are below 5% and no timeouts happen. In Figure 9 we have two pgmcc receivers, one with high RTT (400ms) and low loss rate (.4% or 2%) and the other with lower RTT (200ms) and higher loss rate (1.6% or 8%). Losses in this experiment are considered to be independent (not due to congestion), for example over wireless links. The reason for this is that we want to control our parameters accurately to have equal throughputs in both links and evaluate the results in this case. In Experiment 3 we will have the more complex case of congested links. Figure 7: Throughput of pgmcc vs. TCP SACK Figure 8: Throughput of pgmcc with the adaptive timeout vs. TCP Reno Figure 9: pgmcc session with receivers having different delays and loss rates competing with TCP sessions 0 10000 20000 30000 40000 50000 60000 70000 80000 0 500 1000 1500 2000 2500 3000 Time Sequence PGM TCP 0 10000 20000 30000 40000 50000 60000 70000 0 500 1000 1500 2000 2500 3000 Time Sequence PGM TCP TS1 TR2 PS PR2 Low Loss High Loss TS2 TR1 PR1 10 In Figure 10 we see that pgmcc and the two TCP sessions have close throughput 2 (although pgmcc is unfair to the reasons mentioned in experiment 1). The loss rates here are .4% for the low loss link and 1.6% for the high loss link. In Figure 11 we are using a loss rate of 2% for the low loss link and 8% for the high loss link, which causes pgmcc to be more unfair to the high loss rate TCP session. It turned out that the reason for that is not because of the simple equation used, but because of the differences in reacting to packet losses. At high independent losses pgmcc is unfair to TCP, because of the way it deals with packet losses. In pgmcc the reliability window is separated from the congestion window and the handling of acknowledgements is different. Unlike TCP there are no cumulative acknowledgements in pgmcc. The window in pgmcc can keep increasing, even if there are previous lost packets not received yet. This separation between reliability and congestion seems to be unavoidable in order to achieve an acceptable performance in reliable multicast 3 . 4.3 Experiment 3: Congestion Losses In this experiment we have the more complex case in Figure 12, where we use high and low BW (1Mb/s and .5Mb/s respectively), instead of low and high losses. The delays are 200ms for the low BW link and 800ms for the high BW link. Losses in this topology are due to congestion, so it is very difficult to control the parameters and the results obtained are sometimes very surprising. Figure 13 shows that the pgmcc session is unfair to one of the TCP sessions. On first look one may think that the reason for this is the same as in experiment 2. But by taking a closer look we found a major difference; here we have no acker changes, which means that pgmcc followed the high throughput session. The reason for that is the following: Although the high BW, high RTT side has lower throughput, due to the high BW no packets get dropped and no NACKs get sent. So the sender does not receive anything from this side and gets only the NACKs of the low BW side. 2 We set the parameters of RTT and loss rates to satisfy that the two TCP sessions get the same throughput. 3 In [12] the authors mention that this separation between reliability and congestion is done so that the scheme can work with both reliable and unreliable protocols, while in [11] the reason mentioned is that in PGM repair packets can be transmitted with a significant delay from the loss detection. Figure 10: Throughput of pgmcc vs. the two TCP sessions with low loss rate Figure 11: Throughput of pgmcc vs. the two TCP sessions with high loss rate 0 10000 20000 30000 40000 50000 60000 70000 80000 0 500 1000 1500 2000 2500 3000 Time Sequence PGM TCP1 TCP2 0 5000 10000 15000 20000 25000 30000 35000 0 500 1000 1500 2000 2500 3000 Time Sequence PGM TCP1 TCP2 11 0 10000 20000 30000 40000 50000 60000 70000 0 500 1000 1500 2000 2500 3000 Time Sequence PGM TCP1 TCP2 This result leads us to the general question of what is actually the definition of TCP- friendliness and whether this the best way to achieve fairness with TCP? For example in this case there is a TCP session with a lower throughput, but it seems to suffer no major problems due to pgmcc. Of course its packets are somewhat delayed by the higher throughput of the pgmcc session, but this delay may be negligible in comparison to the high propagation delay 4 . So does pgmcc really need to slow down to this receiver, even if it is not suffering? 4.4 Experiment 4: NACK Suppression In this experiment we are testing the use of network support in the routers and its effect on congestion control. In PGM, if feedback aggregation is used, the first instance of a NACK for a given data segment is forwarded to the source and subsequent NACKs are suppressed. It is clear that this can cause some problems, because a worse receiver can have its NACKs suppressed. According to the protocol designers this should cause no problems, since a worse receiver will send more NACKs and it is likely that one of them 4 We did also the same experiment with a TCP session on the high BW path instead of the pgmcc session and we found that the resulting throughput seen by the TCP sessions of the high BW path is the same in both cases. Figure 12: pgmcc session with receivers having different delays and loss rates (due to congestion) competing with TCP sessions Figure 13: Throughput of pgmcc vs. the two TCP sessions TS1 TR2 PS PR2 High BW Low BW TS2 TR1 PR1 12 will reach the sender. But in some topologies this will not always hold. For example, using the topology in Figure 14 we find that using feedback aggregation will cause pgmcc to be unfair to TCP, because the worse receiver PR3 will always have its NACKs suppressed (the link leading to the PR3 router has 50 ms delay). In Figure 15 we see the throughput of pgmcc and TCP without network support which is similar to Figure 4, and in Figure 16 we see the throughput with network support and how pgmcc gets much higher throughput than TCP. In Figure 16 there are no change of acker and the acker remains one of the closer receivers. According to these results we recommend that some changes are needed in the way feedback aggregation is performed. In [11] the authors propose a possible approach to reduce the effect of suppression, which is to store the loss ratio for each NACK forwarded and not perform suppression if a higher loss ratio NACK for the same sequence number occur. But as we see the loss ratio alone is not enough since both NACKs may have the same loss ratio but the RTT is the decisive factor. A solution for that is to store both the loss ratio and RTT for each NACK and to compare the throughputs using these values. The RTT in this case cannot be the exact RTT, but it can be some value such as the sequence number used for computing RTT or the time of NACK arrival in the network element. This is accepted since it is used for comparison. This solution will solve the problem, but it increases storage and computation overhead in the routers. A low overhead solution for that is to allow the router to randomly pass Figure 14: pgmcc session with receivers having almost the same loss rate, but different delays Figure 15: Throughput of pgmcc vs. TCP without NACK suppression Figure 16: Throughput of pgmcc vs. TCP with NACK suppression 0 20000 40000 60000 80000 100000 120000 140000 160000 180000 0 500 1000 1500 2000 2500 3000 Time Sequence PGM TCP TS TR PS PR1 PR3 Congested Link PR2 0 20000 40000 60000 80000 100000 120000 140000 0 500 1000 1500 2000 2500 3000 Time Sequence PGM TCP 13 NACKs that should be suppressed. This will give the worst receiver NACKs some chances to reach the sender. 4.5 Experiment 5: Out-of-order ACKs For experiment 5 we use the topology shown in Figure 17, which is the same as that in Figure 14 except that the link leading to the PR3 router has a high delay (200ms). No suppression will happen in this case because the retransmissions will reach PR1 and PR2 before the NACK of PR3 reaches the router. In PGM retransmissions are directed by the router only on those links that sent the NACKs, and these retransmissions delete the NACKs states from routers. This is a general problem in PGM, which causes multiple retransmissions. What we will look at here is actually not related to network support, but to the effect of acker switching between receivers with large difference in delay. As shown in Figure 18, the throughput of pgmcc becomes too low, and the TCP throughput is much higher. This does not constitute a fairness problem, but a performance degradation problem for pgmcc. Note that this result is not related to network support and was also observed when network support was not used. The reason for this bad performance under the given topology is the acker changing between a high RTT receiver and a low RTT receiver. By looking at acker switches in detail we found that two switches happen in succession too close to each other. The first NACK from the closer receiver causes an acker change then the other NACK causes another change for the far one when it arrives. This pattern repeats with packet losses. Although, the used acker switching factor c has a value of 2/3, to dampen the acker oscillation. It is interesting to look at why acker changing causes this bad performance (in other experiments it has no effect). By taking a more detailed look in Figure 19 we see how the change from the far receiver to the close receiver, then to the far receiver again has caused the rate of the sender to decrease (the window is cut several times). In Figure 20 we get a closer look at what happens between the two changes, we find that new ACKs arrive before old ACKs after the change to the close receiver. The old ACKs that arrive at 1226.5 do not cause new packets to be sent which means that they do not generate new tokens. After that when new ACKs arrive the window start at slow rate which means that it has been cut several times. Figure 21 shows how the window is cut at 1226.5. Figure 17: pgmcc session with receivers having large difference in delay TS TR PS PR1 PR3 Congested Link PR2 High Delay 14 ‘ The reason for that seems to be due to the out-of-order ACK delivery and the reactions taken accordingly by the sender. Wrong loss detections can be interpreted, because ACKs for old packets have not arrived yet. Also on a loss detection the sender try to realign the window to the actual number of packets in flight, which will not be interpreted correctly after the switch, because there are still packets and ACKs in flight to and from the old acker. Procedures are required for dealing with these effects. The bitmap can help in this case. We tried to solve this problem by using the bitmap to avoid wrong loss detection interpretation, and to avoid realigning the window to wrong values. The performance is increased a bit after this additions, but it is still bad, since after the two switches there is a lot of inconsistency and a lot of losses occur. 5 Conclusions and Future Work We have performed a fairness analysis for pgmcc. pgmcc is a single rate representative- based multicast congestion control scheme which is designed to be fair with TCP. pgmcc is used to implement congestion control in the PGM protocol. Due to the importance of fairness with TCP, that is required from any new protocol, we have conducted several experiments in order to find configurations and scenarios where Figure 18: Throughput of pgmcc vs. TCP in the topology of Figure 17 Figure 19: Detailed sequence of pgmcc packets, during an acker change Figure 20: More detailed sequence of pgmcc packets, during acker change Figure 21: Window size changes of pgmcc session, during an acker change 29800 29850 29900 29950 30000 30050 30100 1220 1225 1230 1235 Time Sequence Data ACK NACK 0 20000 40000 60000 80000 100000 120000 140000 0 500 1000 1500 2000 2500 3000 Time Sequence PGM TCP 0 5 10 15 20 25 30 1210 1215 1220 1225 1230 Time Window Size 29960 29970 29980 29990 30000 1225.5 1226 1226.5 1227 1227.5 1228 1228.5 Time Sequence Data ACK NACK 15 the fairness criteria is violated. From the results obtained it is clear that in some configurations the protocol might not perform as expected. We believe that some modifications are needed in the protocol mechanisms to be TCP-friendly before it can be safely deployed in the Internet. It is clear from the results that the difference in timeout handling has an effect on fairness. If no appropriate timeout mechanism is used, pgmcc gets an edge over TCP. When the timeout value of pgmcc is fixed to a high value, it has much less chances to timeout and to enter slow start in comparison to TCP. Comparing pgmcc to the different versions of TCP allowed us to gain a better understanding of these issues. According to that we believe that the timeout value of pgmcc should be adaptive and change over time. We suggest an adaptive timeout mechanism similar to that in TCP. Results show that this mechanism improves the fairness of pgmcc especially with TCP Reno. We intend to do more experiments with this mechanism in different situations and with more scalable topologies. High losses also cause pgmcc to be unfair to TCP, because the way packet loss is handled. In pgmcc the reliability window is separated from the congestion window and the handling of ACKs is different. There is no cumulative ACK in pgmcc similar to that in TCP. Due to this separation between reliability and congestion that seems to be unavoidable in order to achieve an acceptable performance in reliable multicast, the solution to this problem is not easy. We intend to investigate more on this problem to find an applicable solution that does not violate the semantics of pgmcc. Also at high loss rates the unfairness can increase because of inaccuracy in the throughput equation. NACK suppression can also be a source of unfairness as seen in some configurations. Solutions depending on loss rates only are not enough. Taking the RTTs of different receivers into account and comparing their throughputs before suppression can solve this problem at the cost of extra overhead in the network elements. We suggest a low overhead solution by adding some randomness in the suppression of NACKs by the routers. A very important result obtained that is related to performance and not fairness, is the effect of having different receivers with large differences in delay, which is likely to appear in larger topologies. Acker changes in this case can cause severe performance degradation to pgmcc. The reason for that seems to be due to the out of order ACK delivery and the reactions taken accordingly by the sender. Procedures using the bitmap are required for dealing with these effects. But as we saw this alone was not enough to solve the problem and more investigation is required to deal with it. Last we would like to mention the more general question of the meaning of fairness, and whether protocols such as pgmcc need always to slow down to the worst receiver, even if this receiver is not suffering? In future work we will try to answer these questions. Since we were able to relate protocol behavior to individual protocol mechanisms (e.g., timeout and NACK-suppression), we believe that parts of our results generalize to other 16 protocols that employ similar mechanisms. Although we were able to find interesting behavior of performance degradation and fairness violation here, we do not claim that our scenarios can be used with any multicast congestion control protocol. Indeed, our scenarios are not a universal benchmark, and it was not our intention to create one in this work. We do, however, recommend that researchers consider our scenarios among others. We are encouraged by our results, and hope to develop a more general, systematic and complete method of choosing scenarios that lead to violation of fairness or performance degradation. We plan to adopt and extend the STRESS [6][7] framework in our future work. We are currently establishing the pgmcc model and defining the correctness criteria, according to which the systematic evaluation of the protocol will be performed. Acknowledgements We would like to thank Luigi Rizzo and Gianluca Iannaccone for providing the NS code of pgmcc. References [1] L. Breslau, D. Estrin, K. Fall, S. Floyd, J. Heidemann, A. Helmy, P. Huang, S. McCanne, K. Varadhan, Y. Xu, H. Yu. Advances in Network Simulation. IEEE Computer, vol. 33, No. 5, p. 59-67, May 2000. [2] Dante DeLucia and Katia Obraczka. Multicast feedback suppression using representatives. Proc. of the IEEE Infocom’97, Kobe, Japan, April 1997. [3] C. Diot, J. Crowcroft. Multicast Transport Survey. Journal of Selected Areas in Communications, 1997. [4] K. Fall and S. Floyd. Simulation-based Comparison of Tahoe, Reno, and SACK TCP. Computer Communication Review, vol. 26, pp. 5--21, July 1996. [5] Mark Handley and Sally Floyd. Strawman Specification for TCP Friendly (Reliable) Multicast Congestion Control (TFMCC). Reliable Multicast Research Group, December 1998. [6] Ahmed Helmy, Deborah Estrin, and Sandeep Gupta. Systematic Testing of Multicast Routing Protocols: Analysis of Forward and Backward Search Techniques. The 9 th International Conference on Computer Communications and Networks (IEEE ICCCN 2000), October 2000. [7] Ahmed Helmy, Sandeep Gupta, Deborah Estrin, Alberto Cerpa, Yan Yu. Systematic Performance Evaluation of Multipoint Protocols. Proceedings of FORTE/PSTV, IFIP, Kluwer Academic Publication, Pisa, Italy, October 2000. [8] A. Mankin, A. Romanow, S. Bradner, and V. Paxson. IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols. RFC 2357, June 1998. [9] Katia Obraczka. Multicast Transport Mechanisms: A Survey and Taxonomy. IEEE Communications Magazine, January 1998. [10] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. Modeling TCP throughput: A Simple Model and its Empirical Validation. ACM SIGCOMM 1998, Vancouver, BC, Canada, September 1998. [11] Luigi Rizzo. pgmcc: A TCP-friendly Single-Rate Multicast Congestion Control Scheme. ACM SIGCOMM 2000, Stockholm, Sweden, August 2000. 17 [12] Luigi Rizzo, Gianluca Iannaccone, Lorenzo Vicisano, Mark Handley. PGMCC single rate multicast congestion control: Protocol Specification. Internet-Draft, draft-ietf- rmt-bb-pgmcc-00.txt, 23 February 2001. [13] Tony Speakman, Dino Farinacci, Jon Crowcroft, Jim Gemmell, Steven Lin, Alex Tweedly, Dan Leshchiner, Michael Luby, Nidhi Bhaskar, Richard Edmonstone, Kelly Morse Johnson, Todd Montgomery, Luigi Rizzo, Rajitha Sumanasekera, and Lorenzo Vicisano. PGM Reliable Transport Protocol Specification. Internet-Draft, draft- speakman-pgm-spec-05.txt, 24 November 2000.

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

USC Computer Science Technical Reports, no. 757 (2002)

PDF

USC Computer Science Technical Reports, no. 755 (2002)

PDF

USC Computer Science Technical Reports, no. 801 (2003)

PDF

USC Computer Science Technical Reports, no. 837 (2004)

PDF

USC Computer Science Technical Reports, no. 690 (1998)

PDF

USC Computer Science Technical Reports, no. 788 (2003)

PDF

USC Computer Science Technical Reports, no. 674 (1998)

PDF

USC Computer Science Technical Reports, no. 753 (2002)

PDF

USC Computer Science Technical Reports, no. 797 (2003)

PDF

USC Computer Science Technical Reports, no. 657 (1997)

PDF

USC Computer Science Technical Reports, no. 727 (2000)

PDF

USC Computer Science Technical Reports, no. 673 (1998)

PDF

USC Computer Science Technical Reports, no. 658 (1997)

PDF

USC Computer Science Technical Reports, no. 734 (2000)

PDF

USC Computer Science Technical Reports, no. 663 (1998)

PDF

USC Computer Science Technical Reports, no. 649 (1997)

PDF

USC Computer Science Technical Reports, no. 816 (2004)

PDF

USC Computer Science Technical Reports, no. 814 (2004)

PDF

USC Computer Science Technical Reports, no. 749 (2001)

PDF

USC Computer Science Technical Reports, no. 812 (2003)

Description

Karim Seada, Ahmed Helmy. "Fairness analysis of multicast congestion control: A case study on pgmcc." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 743 (2001).

Asset Metadata

Creator Helmy, Ahmed (author), Seada, Karim (author)

Core Title USC Computer Science Technical Reports, no. 743 (2001)

Alternative Title Fairness analysis of multicast congestion control: A case study on pgmcc (title)

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)

Tag OAI-PMH Harvest

Format 17 pages (extent), technical reports (aat)

Language English

Unique identifier UC16269710

Identifier 01-743 Fairness Analysis of Multicast Congestion Control A Case Study on pgmcc (filename)

Legacy Identifier usc-cstr-01-743

Format 17 pages (extent),technical reports (aat)

Rights Department of Computer Science (University of Southern California) and the author(s).

Internet Media Type application/pdf

Source 20180426-rozan-cstechreports-shoaf (batch), Computer Science Technical Report Archive (collection), University of Southern California. Department of Computer Science. Technical Reports (series)

Access Conditions The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Repository Email csdept@usc.edu

Inherited Values

Title Computer Science Technical Report Archive

Description Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.

Coverage Temporal 1991/2017

Repository Email csdept@usc.edu

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)