Congestion Control with ECN Support in Poll-based Multicast Protocols

Transcription

1 Congestion Control with ECN Support in Poll-based Multicast Protocols Marinho P. Barcellos André Detsch Post-graduate Program on Applied Computing - PIPCA/UNISINOS São Leopoldo, RS - Brazil marinho@acm.org, adetsch@exatas.unisinos.br Abstract Most of the traffic in the Internet nowadays is transmitted using TCP, or Transport Control Protocol. The stability of the Internet depends on the congestion control being performed by this protocol, as well as equivalent mechanisms employed by other protocols. The ECN technique (Explicit Congestion Notification), in which packets forwarded by routers are marked whenever congestion is about to occur (or already occurring), allows a transmitter to reduce the sending rate accordingly without relying on packet drops. ECN has not been fully explored, particularly regarding multicast protocols. This paper presents models of poll-based reliable multicast protocols and extends them with a new single-rate congestion control mechanism that harnesses ECN. Simulation results show that it provides fairness between flows from multiple sources, and is TCP-friendly. Further, they demonstrate the substantial efficiency gain obtained with the use of ECN in multicast.. Introduction IP Multicast allows the efficient transmission of data to a group of receivers, avoiding the unnecessary replication of packets in the network. Reliable multicast protocols allow applications to do reliable multipoint transfers efficiently, whose uses include grid applications, web caching and site mirroring, computational steering (of large simulations), and group-based dependable middleware and applications. The use of congestion control algorithms is fundamental to allow transport protocols to coexist in a shared network like the Internet. The development of congestion control algorithms for reliable multicast protocols involves aspects that are not present in unicast. The scalability of such a protocol is given mainly by its error and congestion control mechanisms. Multicast congestion control has been addressed by recent work, such as [, ]. A multicast flow is TCP-friendly if, for each pair sender-receiver, the friendliness of TCP is verified []. In the (wired) Internet, the detection of congestion by transport protocols is, mostly, based on packet loss detection. That is, the congestion is only tackled after packets have been dropped by a router. In case of routers with droptail policy [5], these losses only occur because of queue overflow, which means protocols can only detect congestion when it the first negative consequences have been felt. Routers that employ Random Early Detection (RED) ameliorate this problem by randomly discarding packets before the queues get completely full. However, losses are still generated to tell the stations that a congestion is imminent. In this context, Explicit Congestion Notification (ECN) [4, 9] represents a potential improvement as it allows end-hosts to proactively detect an imminent congestion, before packets have to be discarded. Congestion signals are generated, explicitly, by the capable routers. Despite the advantages of this technique, its use in multicast congestion control protocols has not been well explored. This paper describes several models of polling-based reliable multicast protocols optimized for medium-scale groups (up to a few hundred receivers), using simulation to compare them and select the best one. These protocols use sliding windows and are single-rate: receivers get data in the same rate. Then they are enriched with a congestion control mechanism which takes advantage of ECN to provide significant gains in performance. The rest of this document is organized as follows. Section addresses ECN, and discusses how congestion control is applied to different categories of single-rate multicast protocols. Section 3 presents models of polling-based reliable multicast protocols, and selects the two that exhibit the best performance in simulation experiments with networks of the intended size (up to 4 receivers). Section 4 proposes a congestion control algorithm for these protocols which is built using sliding windows (similarly to TCP) but achieve the required scalability through polling. Section 5 presents, through simulation experiments, the TCPfriendliness and the gains obtained using ECN on multicast. Final remarks and future work appear in Section 6, which closes the paper.. ECN and Multicast Congestion Control With ECN, signals are explicitly generated by routers to indicate to end nodes the occurrence of congestion. The ECN signaling piggybacks the information into existing data packets. The RFC368 [9] defines the incorporation of ECN to the IP protocol, through a -bit field in the Type

2 of Service (TOS) octet. This field may assume values according to three situations: (i) not-ect: the transport protocol does not provide support for ECN; (ii) ECN-Capable Transport (ECT): the protocol supports ECN; (iii) Congestion Experienced (CE): used by routers to indicate congestion to end-nodes. The RFC defines also how ECN is to be implemented in routers and transport protocols. In ECN-enabled routers, the marking of packets must observe a simple rule: a packet must be marked, i.e. its field set to CE, only when the protocol supports ECN and under the same conditions a packet would be discarded if there was no ECN. In other words, marking only occurs to replace what would be a packet drop. In the case of transport protocols, the RFC requires that the actions taken by the algorithm in face of a marked packet are equivalent to the ones taken under loss detection. This way, two protocols with congestion control whose difference is ECN support tend to receive the same share of network resources. Single-rate reliable multicast protocols may be classified in regards to the error control scheme: NACK-based (e.g. []) or TCP-SACK based (e.g. [7]). NACK-based single-rate protocols employ NACKs as feedback, which tell the sender that a packet has been lost, or appears to be lost. This NACK packet typically has two functions: (a) for the error control mechanism, it works as an indication of loss originating from that receiver; (b) for the congestion control mechanism, as an indication that the transmission rate may have to be decreased. When there is a large number of receivers, there must be a suppression mechanism for redundant NACK packets, in order to prevent implosion. This suppression, which may be done in the hosts [3] as well as in the routers [], must take into account both error and congestion control aspects. In single-rate multicast protocols based on TCP-SACK [8], the feedback that is generated by a receiver contains a representation of the receiver window, directly referring to multiple packets. PrP - Probabilistic Polling: each data packet has also a potential poll request included, making a receiver reply to packets according to a given probability (p), whose value is informed in the packet. If the source sends a window of data containing say, ws packets, approximately ws p N responses will be sent back by receivers. PSEW - Poll Subgroups after Each Window: it operates switching between the phases of window transmission and response collection. Each response refers to a full window, reducing substantially the number of feedback packets and required processing at the source in comparison with PET. Further, receivers are divided in subgroups, allowing a poll request to be efficiently sent with multicast directly to a given subgroup (each one having a different IP multicast address). - Response-Bucket Polling: it employs a tokenbucket scheme to limit the amount of pending responses; the source keeps the bucket, and each token represents a permission to request a response from a receiver. So, when a poll is sent to a given receiver (always via unicast), a token is removed from the bucket; likewise, when a response is received, a token is returned to the bucket. PeP - Periodic Polling: the limiting factor for poll transmission is an inter-packet gap between two consecutive polls; the sender keeps track of the receivers that need to be polled, and sends requests smoothly. We have conducted extensive simulation experiments to evaluate the performance and scalability of the above protocol models in a topology with up to 4 receivers with links of equal capacity (see Fig., where source is at the lower left). We discuss briefly the results below. The effective throughput is normalized in regards to link capacity ( Mbps), and network overhead in regards to data size (6 Mbytes). The network overhead represents the sum of all polling and feedback packets, and headers of data packets as well. 3. Polling-based Reliable Multicast Protocols Polling is a concept as old as computer communication. It can be used in a reliable multicast protocol in order to limit the amount of feedback. The risk of implosion exists when the product of data transmission rate by the sender and the number of receivers results in an excess of feedback packets. As in [], polling can be used to reduce the volume of acknowledgments according to the capacity of the machine and the network. The receiver piggybacks polling requests in data packets to elicit feedback as required. Because the sender has information about the network and receivers, it can react faster to changes in network conditions, and act less conservatively when conditions improve. The ECN mechanisms proposed in this paper are applicable to polling-based reliable multicast protocols. We have identified five models of protocols of this class, which we now describe very briefly: PET - Poll Every Time: a protocol in which each data packet contains an implicit poll request that, once received, causes a response to be sent to the source. Figure. Simulated network topology. Throughput and network bandwidth were measured for each of the five protocols, and presented in Fig. (each legend roughly follows the order in which curves appear). PET overwhelmed the network even with groups as small as 5 receivers, as shown in Fig. (b), and its performance resulted very low. PSEW presented very low network overhead (. for 4 receivers) and the highest performance (around.9) for groups of up to receivers. However,

3 the throughput of PSEW drops linearly thereafter until.4, with 4 receivers. Both and PeP showed very little loss of performance as the group size increased, with being consistently better (.9 and.8, for group sizes and 4, respectively). The network overhead of grows smoothly up to.5. The costs of PeP and PrP are comparatively high. We chose to use and extend with congestion control because it combined provided the best overall results. Normalized throughput Group Size PeP PSEW PrP PET (a) Effective throughput Normalized network overhead Group Size PET PrP PeP PSEW (b) Network overhead Figure. Comparison of protocols. 4. Combining ECN Congestion Control and Polling-based Multicast Based on the protocol chosen in the previous section, we designed a window-based congestion control algorithm that takes advantage of ECN. When a receiver is delivered a packet, it updates its receive window, but does not send a response immediately; ACKs and NACKs (like TCP-SACK) are sent combined in response packets that can only be sent under request from the sender. A new multicast congestion control mechanism must obey a set of requirements: it must be TCP-friendly [3], do not suffer from the loss path multiplicity problem [] and, when window-based, it must not use a global regulation scheme for all receivers. The latter is important in order to prevent an excessive reduction in send rate when there is substantial heterogeneity among receivers [6]. Further, a congestion control mechanism with ECN support must follow the behaviour specified in RFC 368 [9]. Next, we present the phases of the proposed algorithm: congestion detection, congestion window adjustment and send rate calculation. Congestion detection is performed by receivers. Signs of congestion are the detection of packet losses or the receipt of packets that were marked by a router, as explained below. The loss of a data packet is detected through a NACK in the receive window. Whenever a packet is received, the receiver updates the window and checks if a gap was created in the packet sequence number. If so, it is likely that this packet signals a congestion. Differently, congestion detection through ECN happens by examining the reserved bits in the IP header. In both cases, each receiver R i records in lct i (last congestion time) the time of the most recent signal of congestion. The value of lct i is forwarded to the sender using a field in response packets, leading to the adjustment of the congestion window. Adjustment of the congestion window. Like TCP or any other window-based scheme, the adjustment of the send rate is achieved by varying the size of the congestion window, according to the AIMD policy: Additive Increase with Multiplicative Decrease. In the proposed scheme, the adjustment is performed independently for each R i by means of cwnd i (congestion window), which is kept in the sender. The value of cwnd i is used to limit the amount of outstanding data packets between the sender and R i. The variation of cwnd i is done similarly to TCP, by establishing two different periods, corresponding to Slow Start and Congestion Avoidance. The transition between them, as the adjustment of the threshold on which this transition is based, is performed like TCP, but with Slow Start being applied only at the beginning of the session. The increase in cwnd i happens when a packet is first acknowledged by R i. At this moment, the value of cwnd i is increased proportionally to the number of new ACKs. This adjustment can be done in two ways: when in Slow Start, each new acknowledgment leads to an increase of one slot in the congestion window, i.e. cwnd i = cwnd i + ; when in Congestion Avoidance, each new acknowledgment provokes an increase equivalent to a fraction of slot, which is inversely proportional to the current congestion window size, i.e. cwnd i = cwnd i + /cwnd i. The reduction of the congestion window is performed similarly to TCP, i.e. each congestion signal reduces in half cwnd i, but the sender considers signals only when spaced by at least one RTT. This filtering is needed to prevent a signal that has been already handled from causing a further reduction, which is implemented as follows. The sender controls the spacing maintaining, for each R i, a variable lct eff i, which contains the most recent value of lct i reported and that has led to a reduction in cwnd i. When a new value of lct i is received, the sender verifies weather lct i lct eff i + rtt i, where rtt i represents the current estimate of RTT between the sender and R i. If the condition is true, the sender decreases cwnd i and updates lct eff i with lct i. Obtaining the send rate. The send rate of a single-rate protocol must obey the requirements of TCP-friendliness considering the bottleneck receiver. However, it is not possible to employ the minimum value among the congestion window sizes and apply it over the global transmission window. This is so because it might excessively reduce the rate when the receiver with the smallest window does not match the one with highest RTT [6]. To avoid this problem without compromising friendliness to TCP, the proposed mechanism calculates, for R i, a value ht i which corresponds to the packet with largest sequence number that can be transmitted according to the state of the send window and cwnd i. Therefore, the transmission is limited by the smallest value of ht i among the receivers, instead of the minimum congestion window.

4 Considerations. As explained below, the proposed mechanism satisfies the requirements in the beginning of this section. The algorithm (a) is TCP-friendly, since it mimics the behaviour of TCP congestion control mechanism, adjusting the values of cwnd i for each R i according to AIMD, and taking as reference the slowest receiver before sending new data; (b) does not present the loss path multiplicity problem, as an individual cwnd i is maintained for each receiver, isolating the signs of congestion; (c) does not employ a single regulation parameter for all receivers ([6]): each R i possesses its own congestion window size, cwnd i ; (d) employs ECN as mandated by RFC 368, since the ECN information is considered as a congestion signal like in a packet loss. 5. Analysis of the Proposed Mechanism This section provides a simulation evaluation of the congestion control using the reliable multicast protocol chosen in Section 3,. We first investigate the fairness and TCPfriendliness properties of the mechanism, and then valuate the performance impact of using ECN. 5.. Assessment of Fairness and Friendliness _3 _4 (b) RED without ECN (a) Drop-tail _3 _ (c) RED with ECN Figure 4. Four competing flows. _3 _4 Experiments were used to observe the behaviour of the congestion control algorithm when there is network contention. We present first simulation results for evaluations of fairness, then of friendliness, of the mechanism proposed. The same scenario is employed in both sets of experiments: a double-bell topology whereby a common bottleneck link is shared by multiple concurrent flows. Although comparatively simple, this kind of topology is typical of congestion control studies (e.g. see [], [4]). As shown in Fig. 3, the topology differs from the large-scale network in Section 3. The idea is to create a scenario which is simple enough to capture the properties of interest. TCP Sources Sources Mb/s, ms TCP Receivers Receivers Figure 3. Topology used in fairness and friendliness experiments. Fairness. To evaluate the proposed mechanism in regards to fairness, we run experiments where four flows share the available bandwidth in the bottleneck, varying between each experiment the queueing mechanism employed by routers: drop-tail, RED without ECN support, and RED with ECN support. The simulations were configured so that flows were started at times,, 4 and 6 seconds. The ending time for each flow was set to 6, 4, and seconds, and the number of receivers for each flow was, 5, and 5 receivers, respectively. An algorithm that implements fairness among flows of the same protocol, in general, provides an equal distribution of the bandwidth in the bottleneck link. In the configuration used, the rate observed for each individual sender should be similar. The next plots present the variation of send rate in the transmitter nodes, that is, the raw throughput (including retransmissions and communication overhead) generated by each sender throughout the session. As it can be observed in Fig. 4(a), (b), and (c), the flows share equally the available bandwidth; hence, the proposed mechanism, in the conditions analysed, can maintain fairness among flows of the same protocol (intra-protocol). Notice, also, that the algorithm quickly adapts when a new flow appears or an existing flow terminates. Finally, the frequent variation in send rate seen in the plots is a characteristic of protocols that mimic the AIMD behaviour of TCP. TCP friendliness. This set of experiments aims to evaluate the behaviour of the protocol when there are three TCP (New Reno) concurrent flows, to evaluate qualitatively the TCP friendliness of the mechanism. The scenarios employ routers with different queue management policies: droptail, RED with no ECN support and RED with ECN support. In the latter case, we simulated scenarios both with and without ECN enabled in TCP. We employed three unicast TCP flows and one multicast flow with receivers. The flow was started at time and terminated at 6 seconds, whereas the TCP flows were started at times, 4 and 6 seconds, and terminated at times 4, and seconds, respectively.

5 (a) Drop-tail TCP_ TCP_ (c) RED with ECN; TCP flows with ECN TCP_ (b) RED without ECN TCP_ (d) RED with ECN; TCP flows without ECN Figure 5. competing with TCP flows. The overall rates for TCP and flows reported in Fig. 5(a) to (d) are equivalent. The results obtained show that the proposed mechanism behaved adequately with TCP in all cases evaluated, including experiments where the flow employs ECN and the TCP flows do not support/exploit it, as in Fig. 5.(d). 5.. ECN Impact The impact of ECN is to prevent packet losses, with benefits in terms of latency (it is not necessary to detect a loss, potentially through a timeout), and bandwidth (reduces the number of retransmissions). Further, by partly preventing losses, it becomes less likely that the window will block in the sender. The topology used in the previous section has a single bottleneck: packet losses observed by receivers are the same (fully correlated). However, in a real environment, losses may occur independently for each receiver. Therefore, we chose to use a more complex topology, one which contemplated this factor. The idea behind the topology, as illustrated in Fig. 6, remains simple: instead of receivers sharing the same bottleneck, each receiver has its own independent bottleneck which is shared with exclusive flows, not the ones that compete with other receivers. We performed experiments varying the number of TCP flows for each receiver (between and TCP flows), and the queue management policy in routers (again varying between drop-tail, RED without ECN support and RED with ECN support). Because it is not compatible with ECN, the experiments with drop-tail queues serve only as a reference for the remaining results. In all experiments, the flow, started on time TCP Sources Source TCP Sources Mb/s, ms N Bootlenecks TCP Receivers Receiver Receiver N TCP Receivers Figure 6. Topology for ECN experiments. seconds, performed the reliable delivery of 5 packets, with bytes of data each, to receivers. To add nondeterminism and independence between the bottlenecks, the TCP flows are started at different times, according to some random delay uniformly distributed between and 5 seconds. The TCP flows cease only after the end of the flow; the starting time for the flow was delayed (to seconds) to allow the network to reach steady state after the start of TCP flows. Next, we present the results obtained using the following metrics: the number of data packets (re)transmitted, the effective throughput (goodput) of the multicast transmission and, lastly, the average delays required to deliver data packets to all receivers. Data packets transmitted. The results below show the impact of ECN on the number of data packets that need to be (re)transmitted. This number is directly proportional to the number of losses. The results were normalized by the number of data packets to be delivered by the sender, similarly to Section 3. For example, a normalized means that no retransmission was required; a value of indicates that on average, each packet required retransmission in order to deliver the packet to all receivers. According to the results in Fig. 7(a), we observe that when RED with ECN support was used, no retransmission was required, regardless of the number of concurrent TCP flows. The absence of retransmissions occurs because the packet drops are prevented through the use of marking to indicate imminent congestion. In contrast, when no ECN was used, the number of retransmissions grew linearly with the number of concurrent TCP flows. When drop-tail was used in routers, the result was worse than pure RED (and much worse then RED with ECN), achieving an index of over for concurrent TCP flows for each receiver. Effective throughput. The effective throughput is determined by dividing the amount of data reliably transferred by the time required to do it, or transmission time. More precisely, the transmission time is given by the period between the transmission of the first data packet and the receipt of the last positive confirmation required (when the sender obtains acknowledgements for all packets from all receivers). The times required to establish and close the session are not included, which is an overhead present in any reliable protocol where the sender knows and controls the membership

6 Required transmissions for each data packet Drop-Tail RED_without_ECN RED_with_ECN TCP flows for each receiver (a) required transmissions Mean delivery delay (normalized by optimum) Effective throughput (KBits/s) Drop-Tail RED_without_ECN RED_with_ECN TCP flows for each receiver (c) mean delay Drop-Tail RED_without_ECN RED_with_ECN TCP flows for each receiver (b) effective throughput 6. Conclusions and Future Work This paper offers three important contributions: first, it presents a set of generalized poll-based reliable multicast protocols and uses simulation to compare them, chosing the one with overall best results. Second, it presents a single-rate congestion control mechanism for this protocol, showing that it provides fairness between flows and is TCP friendly. Third, it proposes and evaluates the use of ECN in these protocols. We are presently extending the simulations with more realistic scenarios, including larger network topologies and adding flows with different traffic properties. We intend to study the impact of ECN in other classes of reliable multicast protocols, and quantitatively compare the poll-based reliable multicast with ECN congestion control and other reliable multicast protocols. Acknowledgments. We d like to thank the reviewers for their comments. This work has been partly supported by CNPq, Brazil. Figure 7. Impact when the number of TCP flows per receiver is increased. of the group. Fig. 7(b) exposes the negative impact that using drop-tail has on throughput: both RED and RED with ECN allowed the reliable multicast protocol to perform substantially better. It also shows that the main profit steems from the use of RED, not from ECN. Still, there is a substantial gain in using ECN instead of RED alone; for example, in Fig. 7(b), the effective throughputs measured for drop-tail, RED, and RED with ECN, are 33, 93 and 33 Kbits/s, respectively, when there are concurrent TCP flows for each receiver. That is, using ECN allows an improvement of 43% in comparison with RED alone, and 43% in comparison with drop-tail. Delivery latency. The delivery latency refers to the time interval between the transmission of a packet and its delivery to all receivers, including factors as link propagation latencies, queueing delays and packet losses (in the protocols considered, recovered by means of retransmission). The delivery of a packet is only considered effective in a receiver when all previous packets (with smaller sequence numbers) have been received. The reduction of this time is important in interactive applications or when the transmissions occur in sporadic fashion, involving small data volumes, as in the case of group communication systems. The plot in Fig. 7(c) illustrates the average delivery delays, normalized with optimal delivery delay, that is, considering only the latencies of the paths involved. Primarily, there is great disparity between the results obtained with the use in routers of RED or drop-tail: the use of routers with RED, even without ECN support, represents a sizable reduction in delivery latency. Additionally, ECN prevents considerably the growth in latency that would be otherwise caused by the increase in the number of TCP flows. References [] M. P. Barcellos and P. Ezhilchelvan. A Reliable Multicast Protocol using Polling for Scaleability. In IEEE INFO- COM 98, pages IEEE, Apr [] S. Bhattacharyya, D. Towsley, and J. Kurose. The Loss Path Multiplicity Problem in Multicast Congestion Control. In IEEE INFOCOM 99, pages IEEE, Mar [3] D. M. Chiu, M. Kadansky, J. Provino, J. Wesley, H. Bischof, and H. Zhu. A Congestion Control Algorithm for Treebased Reliable Multicast Protocols. In IEEE INFOCOM, June. [4] S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, 4(5): 3, 994. [5] P. Gevros, J. Crowcroft, P. Kirstein, and S. Bhatti. Congestion Control Mechanisms and the Best Effort Service Model. IEEE Network, 5(3):6 5,. [6] S. J. Golestani and K. Sabnani. Fundamental Observations on Multicast Congestion Control in the Internet. In IEEE INFOCOM 99, pages 99, 999. [7] S. Liang and D. Cheriton. TCP-SMO: Extending TCP to Support Medium-Scale Multicast Applications. In IEEE IN- FOCOM,. [8] M. Mathis and el at. TCP Selective Acknowledgement Options. RFC 8, IETF, Apr [9] K. Ramakrishnan, S. Floyd, and D. Black. The Addition of Explicit Congestion Notification (ECN) to IP. RFC 368, IETF, Sept.. [] L. Rizzo. pgmcc: a TCP-friendly Single-rate Multicast. In SIGCOMM, pages 7 8,. [] J. Widmer, R. Denda, and M. Mauve. A Survey on TCP- Friendly Congestion Control. IEEE Network, 5(3):8 37,. [] J. Widmer and M. Handley. Extending Equation-based Congestion Control to Multicast Applications. In ACM SIG- COMM,. [3] J. Widmer and M. Handley. TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification. INTER- NET DRAFT: draft-ietf-rmt-bb-tfmcc-4.txt, Oct. 4.