Resumes & CVs

A Flow Control Algorithm for ACK-based Reliable Multicast

Abstract We introduce STBL, a flow control algorithm that uses both window and rate to regulate traffic with smoothed transmission and bounded loss, as well as to compete fairly with TCP traffic. In this paper, we evaluate how STBL behaves as part of
of 19
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  1 A Flow Control Algorithm for ACK-based Reliable Multicast Dah Ming Chiu, Miriam Kadansky, Joe WesleySun Microsystems LabsMay 1, 1999 Abstract  We introduce STBL, a flow control algorithm that uses both window and rate to regulate traffic withsmoothed transmission and bounded loss, as well as to compete fairly with TCP traffic. In this paper, weevaluate how STBL behaves as part of a ACK-based reliable multicast transport protocol (TRAM), based ona simulation model. A library of standard reference scenarios is used to drive the simulation. The results arequite promising. 1.0 Introduction  The primary benefit of reliable multicast is that it offers an efficient way of disseminating information tomany locations (almost) simultaneously.Both error control and flow control in reliable multicast (RM) are difficult problems. The difficulty witherror control is that the need to process ACKs (or NACKs) from multiple receivers can create an implosionat the sender as the number of receivers increases. There are many proposals for reliable multicast transportprotocols, driven by different application requirements in the areas of: reliability, scalability andperformance. These approaches have been reviewed and discussed in [SURVEY].The problems with flow control are many-fold. Scalability is one of the problems: as the number of receiversincreases, the range of suitable transmission rates diminishes and it becomes increasingly difficult toaggregate feedback signals from the receivers. Another problem is with fairness: it is strongly argued thatmulticast flows must be TCP-friendly which, depending on how religiously you conform, can make flowcontrol more challenging. During periods of congestion, a multicast flow’s repair (retransmission) trafficmay come from different nodes, making it harder for the sender take it into account.The following are some of the key factors affecting the design of the flow and congestion control algorithm: •   If and how the sender gets feedback information from the receivers •   Whether the control is window or rate based 1 •   Whether there are external knobs that are used to indicate application requirements and performanceguarantees agreed to out-of-band •   What the fairness goals areThe answers to some of these questions depend on the algorithm used to support reliability; for example,whether it is ACK-based or NACK-based. The issue of fairness hinges on larger issues of network resourceallocation in the Internet, as is discussed below.In an ACK-based protocol, there is regular feedback from the receivers to the sender for error controlpurposes. This feedback channel can be used to piggyback flow and congestion information as well, so it isnatural to incorporate a flow control algorithm that responds to such feedback information continuously. In a  1 We assume this needs no definition. For example, TCP uses a window-based flow control scheme. Someof the transports proposed for ATM networks use rate-based flow control.  2NACK-based protocol, there is no regular feedback from the receivers to the sender. This opens the door forthe design to use a separate feedback channel that is specifically for flow and congestion control and it has tobe justifiably efficient in its own right. This requirement has prompted work on feedback mechanisms basedon representative receivers, and prescriptive flow control algorithms based on feedback of longer termnetwork conditions sampling rather than incremental-adjustment flow control algorithms based on almostinstantaneous feedback.Window-based flow and congestion control is very natural for an ACK-based protocol due to its simplicity.It interacts well with buffer management policies. Due to years of studies on TCP, there is also a wealth of understanding of how a window-based control algorithm works. The advantage of a rate-based control isthat it maps well with application requirements and bandwidth allocation policies. Without regular feedback (ACKs), the control has to be rate-based 2 .Since the Internet supports primarily best-effort traffic, the issue of fairness is critical as it determines hownetwork resources are allocated to competing users. The fairness of TCP has been studied by many, and overthe years TCP has become the primary standard transport protocol as well as the most widely used protocolof the Internet. For these reasons, it has been strongly argued that RM flow control should be TCP-friendly[Mankin]. This is a good design principle. TCP-friendliness, however, should be considered as a qualitativeguideline. Fairness of network resource allocation does not have a single straightforward theoreticalformulation. Even TCP itself cannot always yield predictably fair resource allocation as TCP fairnessdefines 3 . Moreover, it is probably a good design principle to allow some externally configured parameters tohelp guide the flow and congestion control algorithm when necessary. In TCP’s case, one external parameteris the receiver’s window size determined based on available buffers. This is used to give an upper bound tothe congestion window.TRAM is a reliable multicast transport protocol that uses a repair tree to deal with error control [TRAM].This paper discusses the study of the flow control design for TRAM. The scheme adopted is based on using both window as well as rate for flow control. The use of rate helps to smooth (and shape) the senders’transmission; the use of window helps to limit the packet losses. The control scheme is referred to asSmoothed Transmission with Bounded Losses (STBL). A primary goal of STBL is to be TCP-friendly.The basic ideas in STBL - the use of both window and rate to control the flow of traffic - are not specific toTRAM. They can be applied to other ACK-based protocols - multicast or unicast. 2.0 Review of RM Flow Control Approaches  2.1 TFMCC One approach for doing multicast congestion control is the TCP Friendly Multicast Congestion Control(TFMCC) proposal. This approach is based on the work by a number of researchers, see [Floyd],[Montgomery], [Bhattacharyya], [Strawman], [Whetten]. [Floyd] introduced the idea of using a TCPformula to set the transmission rate; [Montgomery] and [Bhattacharyya] described how variations of thisidea is applied to multicast transport design. Later, [Strawman] unified several similar proposals based onthe same approach. [Whetten] addressed some of the theoretical foundations for the TFMCC approach, suchas the definition of fairness and the stability of the control system.  2 Without regular feedback, a popular form of control is based on stop-and-go, or also known as on-off  control, which is a form of rate-based control as well. 3 At a recent research group meeting, after having finished doing lots of simulation of different RM and TCPflows, Mark Handley concludes semi-jokingly: "TCP is not TCP-friendly".  3TFMCC is a rate-based flow control. The crux of this approach is to let the sender use a TCP formula thatmaps packet loss rate to throughput to determine the rate for transmission. Several TCP modeling studieshave led to accurate TCP loss-to-rate formula [Mahdavi], [Mathis], [Padhye]. The claim is that the use of such a formula by the sender’s rate controller automatically guarantees that the (multicast) flow competesfairly with other TCP flows. In the multicast case, the application of this approach is more complicated bythe fact that packet losses occur at the paths from the sender to the different receivers, and they may be quitedifferent. TFMCC’s solution is to let all receivers measure the loss rate and other parameters in the TCPformula (such as the round trip time); and each calculates the suitable sending rate as if it is the onlyreceiver. The sender then figures out the appropriate rate to use.One of the major advantages of TFMCC is that it is independent of the error control mechanism - whetherACK-based or NACK-based. (In either case, there still needs to be some filtering mechanism so that onlythe relevant feedback gets back to the sender). This de-coupling makes TFMCC suitable for considerationas a protocol-independent "building block" [Handley].On the other hand, TFMCC is relatively complicated. The TCP-friendly formula requires measuring the lossrate and the roundtrip time, both of which are quite dynamic. If the measurements are based on very quick sampling, it may not be very representative; if they are based on a longer term sampling, it may reduce thescheme’s responsiveness. Whether the scheme can be made robust enough is still under research. 2.2 Window-based approach Several research studies have investigated adapting the TCP window-based flow control to reliablemulticast, for example [Rhee], [Wang].Rhee described a tree-based reliable multicast protocol, MTCP, which is similar to TRAM. Its window-based flow control relies on SAs (equivalent to TRAM’s repair nodes) to work with the sender inestablishing the values of current data in transit and congestion window. The SA’s also compute a RelativeTime Delay for each acknowledged packet to establish a suitable retransmission timer and compute theround trip time at the sender.A TCP-like multicast transport was also studied in [Wang]. There is no tree-based repair and feedback - thescalability issue is not addressed. It contained several interesting ideas otherwise: •   Proposed a weaker (perhaps more realistic) notion of TCP fairness - "essentially fair" •   Studied a congestion control scheme that reacts to feedback signal probabilistically - a form of filter forredundant feedback for multicast transport 2.3 Theoretical Studies In [Golestani], he made several theoretical observations contrasted rate and window-based flow andcongestion control schemes: •   Even without dynamically adjusting the window size, a windowing scheme slows down the traffic rateas congestion increases, since the round trip time increases as well •   There are two forms of fairness, one tries to achieve equal throughput at the bottleneck resource, and theother achieves relative throughput depending on the round trip time of the flows. He called the formerrate-oriented fairness and the latter window-oriented fairness •   The better way of implementing congestion control (in particular window based control) is to rely onreceivers to collectively participate in the computation - he called this receiver-driven congestioncontrol.Golestani’s observations summarize several key principles in designing rate and window based congestioncontrol and provided us with inspiration.  4 3.0 Smooth Transmission and Bounded Loss (STBL)  In this paper, we report the study of a flow control scheme that uses both rate and window to regulatetransmission. The rate is used to ensure packets are sent in a smoothed fashion, and bandwidth utilization isfair compared to other competing traffic. The window is used to limit the amount of loss so that the senderdoes not get too far ahead of the receivers. The algorithm is based on heuristics and is relatively simple, asdescribed below.The rate-based regulator uses a leaky-bucket algorithm. After a packet is transmitted, the regulatordetermines the time for transmitting the next packet asNext Time = Now + Packet Size / RateBy scheduling packet transmission this way, we expect the average achieved data rate to be approximatelythat of the rate we use to schedule transmission. In what follows, we use the term rate to refer to the rate weuse to schedule transmission. This is also the rate we increase and decrease. The term "achieved rate" isused to mean what we measure that actual data rate (during a congestion window of packets) to be.The regulator also checks to see if the number of "outstanding" packets exceeds the current congestionwindow size. If so, the transmission is halted until new ACKs come in to reduce the number of outstandingpackets to be smaller than the window size. ACKs are sent from receivers once for every ACK Window of packets. ACK Window is set to be half of the congestion window size 4 .Ideally, the congestion window is established commensurate to the length of the "pipe" and remainsunchanged afterwards; the transmission rate is adjusted to compensate for the dynamic conditions of thenetwork (as described in the srcinal short note [STBL]). For example, the following methods can be used: •   Based on the knowledge of the path of the connection, a network manager manually configures a fixedcongestion window size before the start of the session. •   Some sort of network path discovery probe is used to learn the path information for the connection, anduses the information to configure a suitable congestion window size.Without the help of such external configuration, the transport protocol must dynamically determine asuitable congestion window itself, which is discussed below.We considered various ways to determine a suitable congestion window size during a session. Originally, wetried to establish the window size at the beginning of a session, using an algorithm like TCP’s Slow Start.Since the network condition changes continuously, the window size determined during Slow Start would bea function of the network condition only for a particular moment. While this works for a single flow, it didnot yield very good fairness among different STBL flows. This led us to consider other alternatives thatdynamically adjust the congestion window size after Slow Start.All the variations explored share the basic algorithm as described below:Error correction part of protocol: •   receivers send ACKs after receiving ACK Window of packets •   ACK Window is set to 1/2 Congestion Window •   receivers are informed of current ACK Window size in the data packet headerExternally configured parameters: •   minACKWindow - used to bound ACKWindow (hence congestion window size)  4 It is possible to make the congestion window > 2 times ACK Window, which we have not experimentedwith in this paper.  5 •   maxACKWindow - same •   minDataRate - used to bound data rate •   maxDataRate - same •   highWaterMark - used by head to detect congestion based on queue sizePhase 1 (similar to TCP Slow Start): •   start with configured/default a rate and window - the initial rate is set to the configuredmaxDataRate, and the initial ACK Window is set to the configured minACKWindow, whereas thecongestion window is 2 times of the ACK Window. •   increase congestion window at the rate of doubling it every 2 ACK Window of ACKs; •   at the first reported loss, enter phase 2Phase 2: •   cut the rate by half, if there is more loss in the current ACK Window than last •   recalculate Rate Increment as 25% of rate difference 5 •   at the first report of reduced losses, enter phase 3Phase 3: •   increase the rate by Rate Increment, when there is no congestion in a congestion window of packets; •   decrease the rate by 50% if there is congestion in congestion window of packets; •   measure achieved rate in each congestion window of packets; •   (variation 1) recalculate the rate as its average with achieved rate; •   (variation 2) adjust congestion window as follows:under congestion, decrease congestion window (by number of packets lost);else (no congestion) if achieved rate / rate < threshold, then increment congestion windowThe reason for variation 1 is to further improve the "smooth transmission" aspect of the algorithm. Whenthere is a large discrepancy between the transmission rate and the achieved rate, then from a smootheningtransmission point of view, it would not hurt to try a slower rate. We call this variation Smoothed rate .Variation 2 is to not trust the congestion window size determined in phase 1 and adjust it dynamically.When n packets are lost (by a receiver), it assumes that some buffer had an overflow of n packets anddecreases the congestion window by n. When there is a large discrepancy between the transmission rate andthe achieved rate, it assumes this is caused by the congestion window size being too restrictive 6 in holdingoff packets, hence increases the window slowly (by 1 each time). We call this variation Dynamic window .The evaluation of the protocol design is based on simulation. Next we describe a series of referencesimulation scenarios proposed by the RM Research Group which we adopted. 4.0 Simulation Scenarios  In [RefSim], published by the Reliable Multicast Research Group, a series of scenarios are suggested to helpstudy a RM congestion control scheme. While these scenarios are not suggested to be benchmarks, they doserve as a good starting point of having a few clearly defined cases for comparison.  5 We experimented with some different values for this multiplier, but used 25% for the reported results. 6 We experimented with different value of threshold, but used 0.1 for the reported cases.
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks