Equation-based end-to-end single-rate multicast

Ann. Telecommun. (2010) 65:219–231 DOI 10.1007/s12243-010-0159-1

Equation-based end-to-end single-rate multicast congestion control Wafa Kammoun & Habib Youssef

Received: 6 July 2008 / Accepted: 7 January 2010 / Published online: 16 February 2010 # Institut TELECOM and Springer-Verlag 2010

Abstract Among the recently proposed single-rate multicast congestion control protocols is transmission control protocol-friendly multicast congestion control (TFMCC; Widmer and Handley 2001; Floyd et al. 2000; Widmer et al. IEEE Netw 15:28–37, 2001), which is an equation-based single-rate protocol that extends the mechanisms of the unicast TCP-friendly rate control (TFRC) protocol into the multicast domain. In TFMCC, each receiver estimates its throughput using an equation that estimates the steady-state throughput of a TCP source. The source then adjusts its sending rate according to the slowest receiver within the session (a.k.a., current-limiting receiver, CLR). TFMCC is a relatively simple, scalable, and TCP-friendly multicast congestion control protocol. However, TFMCC is hindering its throughput performance by adopting an equation derived from the unicast TFRC protocol. Further, TFMCC is slow to react to congestion conditions that usually result in a change of the CLR. This paper is motivated by these two observations and proposes an improved version of TFMCC, which we refer to as hybrid-TFMCC (or H-TFMCC for short). First, each receiver estimates its throughput using an equation that models the steady-state throughput of a multicast source controlled according to the additive increase multiplicative decrease (AIMD) approach. The second modification consists of adopting a hybrid sender/receiver-based rate control strategy, where the sending rate can be adjusted by the source or initiated by the current or a new CLR. The source monitors W. Kammoun (*) : H. Youssef Research Unit PRINCE, ISITCom H-Sousse, University of Sousse, Sousse, Tunisia e-mail: [email protected] H. Youssef e-mail: [email protected]

RTT variations on the CLR path, in order to rapidly adjust the sending rate to network conditions. Simulation results show that these modifications result in remarkable performance improvement with respect to throughput, time to react, and magnitude of oscillations. We also show that HTFMCC remains TCP-friendly and achieves a higher fairness index than that achieved by TFMCC. Keywords Multicast transport protocols . Equation-based . Single-rate multicast congestion control . AIMD

1 Introduction The robustness of the current Internet is due, in large part, to the end-to-end congestion control mechanism of transmission control protocol (TCP) [18, 20, 23, 24]. It is generally known that TCP dominates current Internet operations as it represents 90% of traffic. It is widely accepted that congestion and flow control are integral parts of any Internet data transport protocol whose traffic travels over a shared network path. Emerging multicast services such as collaborative applications, database replication, software distribution, etc., call for the deployment of new multicast transport protocols with adequate congestion control schemes. End-to-end multicast congestion control has been an important research issue over the last decade [1–4, 6, 8]. There is a consensus among the research community that alternative congestion control mechanisms intended for use in the internet have to fairly coexist in an environment dominated by TCP. The design of a reliable end-to-end MCC protocol that provides high performance, scalability and TCP friendliness is a complex problem. One of the most significant challenges that confront end-to-end multicast congestion control is the provision of a scalable

220

solution that must be designed in a TCP-friendly way to coexist with current Internet traffic. A TCP-friendly flow is a flow that competes “fairly” with TCP connections. In other words, TCP friendliness means that if a multicast session shares a bottleneck link with TCP connections, the destinations should receive the data packets approximately under the same delay and packet loss conditions as TCP connections. TCP congestion control protocol ensures a fair share of bandwidth between competing TCP flows, and is based on reducing a source flow of packets when congestion is detected. MCC is much harder than the TCP unicast case because of the following reasons: Heterogeneity This is the first problem that needs to be solved for several multicast applications. Single-rate MCC schemes solve this problem by forcing data transfer to proceed at the rate of the slowest receiver within the session. Scalability The protocol should be able to work under a variety of conditions that include multiple network topologies, link speeds, and multicast group sizes. It is more important to have a good understanding of how and when a protocol breaks than when it works. A MCC scheme should be able to deal with the heterogeneity of the participants in a scalable manner. That is, resource requirements (memory and processing) and performance should be nearly insensitive with a growing group size. Efficiency The protocol must achieve good throughput and must achieve good link utilization. Further, it should exhibit good responsiveness (react swiftly and rapidly) to congestion conditions. Thus, an inefficient protocol fails to reduce load in response to increased loss. Fairness Fairness between competing flows on the Internet is a serious issue. Particularly, new designed protocols should be tested for fair share of the bandwidth with competing TCP flows within different group members within the multicast session. Also, it must not starve competing flows. Several studies have pointed out that schemes with a severe RTT unfairness problem, where competing flows exhibit widely different RTTs can consume considerable unfair bandwidth shares [5, 10, 11, 22]. MCC protocols reported in the literature belong to two main categories: single-rate and multi-rate protocols. In the single-rate approach, the multicast source selects a receiver within the session having the lowest rate as the group representative (a.k.a., current-limiting receiver, CLR). This CLR is supposed to be the slowest receiver within the multicast session, so that the source adjusts its transmission rate accordingly. Whereas in the multi-rate approach [15, 16], the source transmits the data packets with a rate varying with the grade of service of the receivers over

Ann. Telecommun. (2010) 65:219–231

multiple streams (in layers) matching their capacities. So that, each receiver could join/leave a layer according to its available bandwidth and resources. In practice, the singlerate MCC is much simpler to implement and easier to deploy. The primary drawback of the single-rate scheme is that it cannot meet receivers varying demands on throughput, thus penalizing faster receivers. The single-rate congestion control mechanisms can be used for a wider range of multicast applications but it is necessary to ensure, that adjusting the sending rate to a single receiver does not excessively degrade the performance for faster receivers. Whether to choose multi-rate or single-rate transport is a fundamental decision in the design of a MCC-mechanism. When the receivers have different requirements, a multi-rate approach is better. At the same time, this is only possible if the data to be transmitted can be divided into multiple layers. Adjusting the number of layers does not allow an adaptation of the receive rate as fine-grained as single-rate congestion control does (since a receiver is either subscribed to a layer or not), and it is usually much more complex to build. A typical example is multicast video where each additional layer of data improves the visual quality for the receivers. Our focus in this paper is on TFMCC, a recently proposed equation-based single-rate MCC protocol [2, 6– 9]. The equation used is adopted from the unicast TCPfriendly rate control (TFRC) [14] protocol. TFMCC is a well-designed protocol that was shown to satisfy TCP fairness while assuring a smooth steady rate of the multicast source. However, TFMCC suffers from two main weaknesses: (1) for the sake of guaranteeing TCP fairness, TFMCC adopts the conservative approach of controlling the rate of the multicast source by an equation that estimates the steady-state throughput of a unicast TCP source, while using the RTT and PLR (p) of the slowest receiver; (2) TFMCC is slow to react to network varying network conditions that cause changes of the CLR. We believe that these two weaknesses are behind the lower throughput performance of TFMCC compared to the more recent MCC scheme ORMCC [1]. This paper proposes solutions to these two weaknesses. First, we propose an analytical model to derive an equation that expresses the steady-state throughput of a multicast source controlled according to the additive increase and multiplicative decrease (AIMD) approach. This equation [17] is then integrated in TFMCC instead of the old steady-state TCP throughput equation. The second contribution consists of adopting a hybrid sender/receiver-based rate control strategy, where the sending rate can be adjusted by the source or initiated by one of the receivers (the CLR or a new CLR with an estimated rate lower than that of the current CLR). According to this hybrid strategy, the source monitors its RTT with the CLR. Observed RTT variations are used to

Ann. Telecommun. (2010) 65:219–231

estimate a congestion factor (fcon) which is used to adjust more rapidly the source rate in small amounts, calibrated by the magnitude of RTT variations. From now on, TFMCC refers to the original TFMCC and TFMCC with the aforementioned modifications as hybrid-TFMCC or HTFMCC for short. Simulation results show noticeably better performance of H-TFMCC compared to TFMCC as well as ORMCC. We also show that, similar to TFMCC and output rate multicast congestion control (ORMCC), HTFMCC is TCP-fair. The rest of the paper is organized as follows: In Section 2, we present work related to single-rate MCC schemes. In Section 3, we introduce an analytical model to derive an equation that estimates a multicast source controlled according to the AIMD approach, which is then implemented in TFMCC. In Section 4, we describe our second contribution, which consists of making the sender capable of monitoring observed RTT variations in order to rapidly adjust its sending rate with the varying network conditions. In Section 5, we demonstrate that H-TFMCC satisfies the TCP-friendly property as well as other important properties. In Section 6, we present simulation results comparing the original TFMCC with that of HTFMCC and ORMCC. We conclude in Section 7.

2 Single-rate multicast congestion control schemes Single-rate congestion control mechanisms can be used for a wide range of multimedia multicast applications. For single-rate MCC protocols, the multicast source regulates the rate based on feedback information from the slowest group member, known also as CLR. The CLR is usually the receiver with the highest loss rate. Several single-rate multicast protocols have been proposed such as MTCP [13], PGMCC (Pragmatic General Multicast Congestion Control) [3], TFMCC [2], and ORMCC [1]. All these protocols have been shown to be TCP-friendly. MTCP [13] is a reliable multicast protocol that follows a window-based congestion control strategy. PGMCC [3] is rate-based, where the source continuously monitors receivers’ reports embedded in the feedback information. The sender estimates the throughput of the receivers using feedback information on packet loss ratio (p) and RTT (roundtrip time) of each receiver, where RTT is expressed in number of packets. A receiver rate is calculated using an equation that estimates a TCP source throughput at equilibrium as a function of RTT and p. The rate of the slowest receiver is adopted as a sending rate. Hence, for the sake of TCP fairness, PGMCC tries to make the multicast source behave like a TCP source. The TFMCC scheme belongs to the equation-based rate control approaches. TFMCC extends the basic mechanisms

221

of the unicast protocol TFRC [3, 14] into the multicast domain. Padhye et al. [12] proposed the average TCP throughput as the TCP-friendly equation which is derived from a mathematical model to characterize the steady-state TCP behavior. In TFMCC, each receiver estimates the loss ratio p and RTT, then applies Eq. 1 to determine the acceptable rate, and sends it as feedback information to the source. S qffiffiffiffi 2p 3p 2 3 þ 12 8 pð1 þ 32p Þ

qffiffiffiffi

XTCP ¼ RTT



ð1Þ

The rate is then adjusted according to the receiver with the smallest feedback value, which is designated as the CLR. The CLR is the receiver that the sender believes currently has the slowest expected throughput of the group, and this one may change dynamically within the session. The CLR feeds back to the source any changes (increase/decrease) in its estimated acceptable rate. However, a non-CLR receiver will not send feedback unless its estimated acceptable rate falls below the current sending rate. The CLR will change if another receiver sends feedback indicating that a lower transmission rate is required or the CLR leaves the multicast group. However, if the CLR leaves the group, the new CLR may have a significantly higher calculated rate. Further, TFMCC uses a probabilistic timer-based feedback suppression mechanism. Thus, the total number of feedbacks is a function of the estimated total number of receivers, and an additional delay is introduced into the feedback and feedback suppression mechanism. TFMCC suffers from two major problems. First, it is slow in identifying a change of the CLR and so, it is slow in reacting to changes in congestion conditions. Another significant problem is that a single CLR can drag down the whole TFMCC session. For more thorough description of TFMCC, the reader is referred to [2, 8]. ORMCC [1] is a more recent multicast rate control scheme, using the policy of AIMD approach. ORMCC uses a metric, throughput rate at congestion (TRAC), which is the throughput measured by the receivers when congestion is detected, and so indicating how much bandwidth the network bottleneck has at a congestion state. The source dynamically selects one of the slowest receivers in the group as the Congestion Representative (CR). It compares the average TRAC, measured at the receivers, to identify the slowest ones, and selects one of them as the current CR, to adjust its transmission rate accordingly. ORMCC imitates the behavior of TCP. That is, if there is no congestion indication from the current CR, the transmission rate is increased by α=S/RTT once per RTT, where S is the packet size, and RTT is the roundtrip time between the source and the slowest receiver (CR). When a congestion indication (CI) from the CR is received, the sending rate is decreased

222

Ann. Telecommun. (2010) 65:219–231

S0

That is, if there is no CI from the slowest receiver (CLR) the transmission rate is increased by α=S/RTT per RTT, where S is the packet size and RTT is the roundtrip time between the source and the congestion representative. We assume ACK and NACK suppression so that at most, one increase or decrease per RTT is allowed. Whenever a CI is received, the rate is decreased with 0 < β < 1, which represents the multiplicative reduction factor. The source reacts to negative feedback by reducing the transmission rate and to positive feedback by increasing it. Consider the sequence of instants tn when the source rate is updated (increased/decreased), and define the nth interval as [tn, tn+1). Let the sequence of roundtrip times RTTn = tn+1 −tn. RTTn (n≥1) represents the sequence of roundtrip times seen by the AIMD-control mechanism. Recall that the rate updates are made once per RTT. The multicast source is going to transit between two states: A state S0 of no congestion, consisting of a burst of consecutive additive rate increases, and a state S1 of congestion, consisting of a burst of congestion indications resulting in rate reductions. This behavior corresponds to a Markov chain as illustrated in Fig. 1. Let π0 and π1 be the probabilities of the source being in state S0 and S1, respectively. These probabilities are obtained by solving the following system: 8   < 1p p ðp 0 ;p 1 Þ ¼ ðp 0 ;p 1 Þ 1p p : p 0 þp 1 ¼ 1

p

1- p

1-p

S1

p

Fig. 1 The Markov chain modeling the state of the AIMD source

by the rate reduction factor β. The reduction factor β (set to 0.65) is an important ORMCC parameter to avoid oscillations. The larger is β, the more aggressive is ORMCC. The main contributions of this paper consist of proposing solutions to the two major weaknesses of TFMCC, discussed at the end of Section 1, namely the adoption of the steady-state TCP throughput equation and the slow response to network state changes. Two modifications are proposed to TFMCC. First, each receiver estimates its throughput using an equation that models the steady-state throughput of a multicast source controlled according to the AIMD approach. The second modification consists of monitoring RTT variations at the source side, in order to rapidly adjust the sending rate to network conditions. As shall be shown later on, these two modifications resulted in significant performance improvement compared to original TFMCC as well as ORMCC, while remaining TCP-friendly.

3 A new equation for the control of the TFMCC sending rate The general concept of our proposed scheme in the singlerate context is that the source selects one of CLR receivers and only considers its feedback for the rate adaptation. Once the CLR is selected, only this one and those receivers with the average rate that is lower than that of the current transmission rate should send feedback to the source. Recall that TFMCC handles the reliability issue so that each receiver that detects lost messages will send a NACK back to the source to notify the lost sequence. In order to avoid the feedback implosion problem at the source, only the feedback of the CLR is allowed to reach the source, so that feedbacks are efficiently suppressed for the other receivers. In our model, we consider a single-source S that disseminates the data packets to N receivers simultaneously over a multicast tree. The transmission rate of the multicast source is assumed congestion controlled according to the AIMD approach. Fig. 2 Cyclic behavior of a multicast source whose rate is controlled according to the AIMD approach

Additive increase burst

This leads to,   ð 1  pÞ ð p 0 þ p 1 Þ ¼ p p0 ¼ 1  p ) pð p 0 þ p 1 Þ ¼ p 1 p1 ¼ p Therefore, the mean sojourn times at the states S0 and S1 are, respectively: E ½S0  ¼

1 p

E ½ S1  ¼

1 1p

where p is the probability of receiving a congestion indication at the source. A congestion indication is generated by a receiver when a packet is lost, and therefore, p is the probability of packet loss. This loss may correspond to a single packet loss or multiple consecutive packet losses. Therefore, according to the aforementioned Markov chain model, the abstract state of the multicast source is a series of Multiplicative decrease burst

Cycle 1 Rate= x0

and

Cycle 2 Rate= x1

…… Rate= x2

Ann. Telecommun. (2010) 65:219–231

223

Fig. 3 Verification of the convexity condition

Functions of interest (Left) x f(1/x) and (Right) x 1/f(1/x), for the TCP, TFMCC and AIMD formulae. The curves indicate that the convex condition holds for all three functions.

repeated cycles, where a cycle consists of an additive increase burst of length E[S0]=1/p followed by a multiplicative decrease burst of length E[S1]=1/(1−p) (see Fig. 2).Let x0 be the initial output rate of the source and xn be its rate at the end of the nth cycle, n≥1. The source rate at the end of a cycle n, n≥1, is given by the following expression:   1 a 1p xn ¼ xn1 þ ð2Þ b p Which corresponds to, on average 1/p additive increase events, followed by 1/(1−p) multiplicative decrease events. Hence, one can easily show that xn has the following expression: a p

4 Hybrid proactive congestion prevention approach

! 1

b 1p

ð3Þ

j¼1

The above equation simplifies to the following, xn ¼ x0 b

n 1p

a þ p

1

n

b 1p  b 1p

! ð4Þ

1

1  b 1p

Therefore, the steady state of such a multicast source would correspond to the limit of Eq. 4 when n→∞, i.e., a x ¼ lim n!1 xn ¼ p

In the next section, we present another modification made to TFMCC. Instead of waiting for a feedback from the receivers to signal a rate increase or decrease with or without a change in the CLR, the sender proactively monitors RTT variations with the CLR, which it uses to compute a congestion factor fcon. A positive/negative value of fcon results in a rate increase/decrease by the sender. Such rate variations may trigger new feedback from one of the group members, which could result in a CLR change. This is a proactive approach implemented at the sender to prevent the occurrence of congestion.

It is generally difficult to get an exact model of the network dynamics. Several measurement methods are used to determine the performance of the network resources such as those presented in [18–20, 22]. Congestion control in TFMCC is receiver-based, where changes to the source rate occur always as a consequence of a feedback from some of the receivers as follows. Each receiver Ri computes estimates of the packet loss ratio and its RTT with the source and determines its throughput Xi according to Eq. 1. If Xi is less than the source current throughput, then the receiver Ri sends feedback to the source informing it of its

!

1

b 1p 1

1  b 1p

ð5Þ

Recall that, α=S/RTT, where S represents the packet size, p is the packet loss ratio, and RTT is the roundtrip time between the source and the CLR. The parameter β (00 then the rate of the source is decreased, else, if Δn