AN IMPROVED STEP IN MULTICAST CONGESTION CONTROL OF COMPUTER NETWORKS

Transcription

1 AN IMPROVED STEP IN MULTICAST CONGESTION CONTROL OF COMPUTER NETWORKS Shaikh Shariful Habib Assistant Professor, Computer Science & Engineering department International Islamic University Chittagong Bangladesh Abstract In the advent of all kinds of services on the Internet that deal with broadcasting streams of data(voice and video) with a limited bandwidth, managing multicast flows from multiple sources to multiple destinations becomes critical. TCP (Transmission Control Protocol) is for point-to-point communication. In the multicasting there is a group of s. All the s may not response at the same time. So it is very difficult to manage all the s. In this paper I have written some proposed step which can co-exist with the TCP protocol to manage the s for smoothly sending the packet by sender. Keywords: congestion control, feedback implosion, multicast, representative, suppression, TCP-friendliness 1. INTRODUCTION: Multicast improves the efficiency of multipoint data distribution by building a distribution tree from a sender to a set of s [1]. For reducing the load TCP sessions respond in congestion. Therefore, the IETF reliable multicast criteria [2] require each multicast transport protocol proposal for the avoidance of congestion. A transport protocol has two main objectives [3]. 1. Avoid congestion collapse, 2. Achieve fairness. Multicast congestion control protocols proposed recently can be classified into 3 categories: single rate, replicated stream and layered. In single rate data packet will be sent at one rate to the whole group. In replicated category the s may be partitioned into groups and each joins one group. In layered category, the data stream is organized in an incremental way, and a incrementally joins higher groups according to its available bandwidth. In the single rate multicast congestion controls there are different concepts, such as Representative [4], LTRC [5], RLA [6], TFMCC 12 [7], MTCP [8], Golestani [9]. In this paper I have tried to solve the congestion in a different way which have the similarities of the previous approaches. Congestion collapse in today s Internet is prevented by the congestion control mechanisms in TCP. Multicast congestion control mechanisms can co-exist with TCP in the FIFO queues of the current Internet. 2. RESOURCE RESERVATION PROTOCOL: To avoid congestion, extra information can be broadcasted to the group periodically to tell the routers along the tree to maintain certain data structures in their memories. Any can send a reservation message up the tree to the sender, using the reserve path forwarding routing algorithm[10]: 1. At each hop, router notes reservation and reserve necessary bandwidth 2. If insufficient bandwidth is available, it reports back failure

2 3. By the time the message gets back to source, bandwidth has been reserved all the way from sender to along the spanning tree a b c a b c a b c d e f d e f d e f g h I g h I g h i j k l j k l j k l (i) (ii) (iii) Fig-1 resource reservation router sender(upper portion) receive(lower portion) In the above figure, host 3 has requested a channel to host 1. Once it has been established, packets can flow from 1 to 3 without congestion. Next host 3 decides to reserve a channel to the other sender host 2 and 2 nd path is reserved. Now host 5 makes a reservation to host 1. First, dedicated bandwidth has to be reserved as far as router h. Router h can see that it already has a feed from host 1. Assume bandwidth requested for host 1 to host 5 is no more than that reserved for host 1 to host 3. As the necessary bandwidth has already been reserved, it does not have to reserve any more. The current Internet provides best effort service. Quality of service reservation using Resource reservation Protocol [11] has not been widely deployed. Without service reservation, open-loop congestion control is difficult to implement. Therefore all multicast congestion control proposals are based upon feedback control now. 3. THE TCP-FRIENDLY RATE CONTROL PROTOCOL (TFRC) [12] & THE TCP-FRIENDLY MULTICAST CONGESTION CONTROL PROTOCOL(TFMCC): There are two congestion control mechanisms. 1. TFRC and 2. TFMCC. TFRC is a unicast congestion control mechanism. TFMCC extends the basic mechanisms of TFRC into the multicast domain. In TFRC measures the packet loss rate and feeds this information back to the sender. The sender uses this feedback messages to measure the round trip time to the. The sender uses the control equation to derive an acceptable transmission rate from the measured loss rate and round trip time (RTT) and the sender then adjusts its transmission rate. In TFMCC each must measure the loss event rate. Here each must measure or estimate the RTT to the sender and uses the control equation to calculate an acceptable sending rate from the sender to itself. 4. SENDING RATE CALCULATED BY RECEIVER: The control equation used by TFRC and TFMCC is derived from a model for long-term TCP throughput in bytes/sec [13]: s TTCP (1) 2 3 p p t RTT 3 8 p p The TTCP is expected throughput calculated by the s. Here p is the steady-state loss event rate, the round-trip time t RTT and the packet size is s. Each TFMCC measures its own loss event rate and estimates its RTT to the sender and finally uses this equation to find out the expected rate from the sender. If the sender does not exceed this rate for any then it should be TCP-friendly otherwise not. In a feedback control system, the result of the control is measured and the control parameter is adjusted. In an open-loop control system, a predetermined control strategy is fixed without adjustment. 13

3 The other type of estimation algorithm is the well known Additive Increase Multiplicative Decrease (AIMD) [14] algorithm which is given below: if CI indicates congestion c=c*α if CI indicates no congestion in interval T, c= c+b, where α is a constant less than 1 and b is another constant. TCP uses the AIMD estimation algorithm with window size wnd as control parameter,α = 0.5, T=RTT and b=1. 5. FEEDBACK IMPLOSION PROBLEM: There are two approaches to solve the feedback implosion problem: suppression-based, and structurebased [15][16][17] 6. SUPPRESSION: Not all the s will send their feedbacks to the sender. One solution is to choose some s as representatives, and only the representatives send their feedbacks [4]. Receivers control their feedbacks using random timers. The difficulty with this approach is how to set the timer. SRM[18] tells to set the timer according to the distance (delay) between the sender and the. 7. CONGESTION INDICATOR FILTERING: Multicast congestion control has a wide range of operating parameters for each connection. So if the number of s increases, the range of suitable transmission rates diminishes. From the equation (1), we can see that the higher the loss probability, the lower the throughput. If the sender gives the responses to all congestion indicators then the sender will reduce the throughput to zero as the number of s increases. So filter scheme is very essential. 8. REPRESENTATIVE: The Representative approach is used to solve the feedback implosion problem. Congestion indicators are restricted to be from only a small set of representatives. sender congestion indication representative Fig-2 representative in the congested portion Another problem of multicast congestion control is the fairness problem. The source multicast data at a variable rate. Based on feedback from the group it adjust the rate dynamically to avoid network congestion, while trying to make use of available network bandwidth. 9. PROPOSED ALGORITHM OR STEPS: 1. When congestion occurs then any congested will sent a congestion indicator (CI) packet to the sender so that the sender can estimate the total time from sending the previous packet to the time when received CI. Suppose this time is α. The sender will wait for the control output satisfied by equation (1) of throughput for extra more time of amount α so that within this extra α time it can get the control message of throughput from the to adjust its (sender) rate. However this CI message will be received by all at that time of sending the CI message to the sender so that the other s can t send any message to the sender of expected throughput. This is for reducing the traffic both for the line and for the sender. Then there will be created a set of representatives. That is from each congested portion (sub tree) of the whole tree there will be one representative. As a result we can get a small number of representatives from all of congested portions, one from each. Each representative 14

4 can be selected from that congested portion randomly. sender 2. When the set has been created then the members (representatives) of the set can be rearranged by descending order of the loss rate (p) of the packet. 3. The rounded value of the [total representative s/2] will be calculated. These number of s will send the expected throughput to the sender and the sender will immediately adjust its sending rate according to the lowest throughput of the received throughputs. For information it is to be mentioned that the first of the list has the lowest throughput as it has the highest loss rate. For example if the number of representatives is 9 then 9/2=5 messages will be sent from five representatives. These limited number of packets will be sent from the s for security of reaching the messages to the sender as some of the packets may be lost in the communication path. Not all the s will be selected from the representative set because the traffic may be increased. 4. The processing activities that is from representative set creation to sending throughput to the sender will be performed after the time of detecting congestion. For example if the time from sending the packet by sender to the time congestion detected by the be β then the processing time(representative set creation etc.) of the until sending the throughput packet will be less than or equal to β. β is the fraction of time α in step 1. Fig-3 Timing time= β 5. If a from a non congestion portion send an acknowledgement to the sender before sending the congestion indication from the of congested portion then sender will wait until the Congestion Indication(CI) has come. For example, say the time at the moment of sending the acknowledgement from (non congestion) is Ω and the time at the moment of sending the CI from random (congestion) is µ. So, the sender has to wait greater than time (µ- Ω) to get the Congestion Indication(CI) from the after getting the acknowledgement (ACK) message from the (non-congestion). 6. The time interval when there is no congestion the sender will calculate the throughput by additive increase corresponding to TCP (as there is no loss rate so p=0 and then the throughput may be infinity). But it must have to wait extra time (µ- Ω). Of course the time (µ- Ω) is very little. 7. If there is no ACK or CI is received in a certain amount of time that is time out, then the sender will reduce the packet by multiple decrease (AIMD). 10. CONCLUSION & FURTHER WORKS: Multicast congestion control is still an active research area. Comprehensive performance evaluation of the current proposed approaches are needed. In future I 15

5 will try how to find out the time (µ- Ω). It is a further research area. REFERENCES: [1] S. Deering. Host extensions for IP multicasting. RFC1112, Jan,1989 [2] A. Mankin, A. Romanow, S. Bradner and V. Paxson. IETF criteria for evaluating reliable multicast transport and application protocols. RFC2357, June [3] S. Floyd. Congestion Control Principles, INTERNET DRAFT, Jan, 2000 [4] D. DeLucia and K. Obraczka. Multicast feedback suppression using representatives. In Pceedings Of IEEE INFOCOM 97, [5] M.T. A loss tolerant rate controller for reliable multicast. Technical report NASA-IVV , August 1997 [6] H.A. Wang and M.Schwartz. Achieving bounded fairness for multicast traffic and TCP traffic in the Internet. In Proceedings of ACM SIGCO MM 98, 1998 [7] M. Handley and S. Floyd. Strawman Specification for TCP Friendly(Reliable) Multicast Congestion Control (TFMCC), Working Draft, Dec [8] I. Rhee, N. Ballaguru and G.N. Rouskas. MTCP: Scalable TCP-like congestion control for reliable multicast. In proceedings of IEEE INFOCOM 99, 1999 [9] J. Golestani and K. Sabnani. Fundamental observations on multicast congestion control in the internet. In proceedings of IEEE INFOCOM 99, [10] Andrew S. Tanenbaum, Computer Networks, Fourth Edition, ISBN [11] L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala. RSVP: A new resource ReSerVation Protocol. IEEE Network Magazine, 9(5), [12] S. Floyd, M.Handley, J. Padhye and J. Widmer. Equation-based congestion control for unicast applications. In Proc. ACM SIGCOMM, pages 43-56, Stockholm, Sweden, Aug [13] J. Padhye, V. Firoiu, D. F. Towsley and J. F. Kurose. Modeling TCP Reno performance: a simple model and Its Empirical validation. IEEE/ACM Transactions on Networking, 8(2): , April 2000 [14] D.-M. Chiu and R. Jain. Analysis of the increase and decrease algorithms for congestion avoidance in computer networks. Computer Networks and ISDN Systems, 17(1):1 14, [15] C. Diot, W. Dabbous, and J. Crowcroft. Multipoint communication: A survey of protocols, functions and mechanism. IEEE Journal on Selected Areas in Communications, 15(3): , 1997 [16] K. Obraczka. Multicast transport mechanism: A survey and taxonomy. submitted to IEEE Communications Magazine, 1997 [17] K. K. Ramakrishnan and S. Floyd. A Proposal to add Ex-plicit Congestion Notification (ECN) to IP, IETF RFC 2481, Jan 1999 [18] S. Floyd, V. Jacobson, C. Liu, S. McCanne, and L. Zhang. A reliable multicast framework for lightweight sessions and application level framing. IEEE/ACM Transactions on Networking, 5(6): ,