Fair M ulticast C ongestion C ontrol (M2C) Vincent Lucas∗ , Jean-Jacques Pansiot∗ , Dominique Grad∗ and Benoit Hilt† ∗ LSIIT
- Universit´e de Strasbourg - CNRS Email: {lucas, pansiot, dominique.grad}@unistra.fr † Laboratory MIPS (EA2032) - Universit´e de Haute Alsace Email:
[email protected]
Abstract—We propose a new T CP -friendly multicast congestion control for very large groups of receivers. This protocol named M 2C is layered and receiver-driven. Like T CP , M 2C is composed of a Congestion Avoidance and a Slow Start state. However, M 2C can re-activate the Slow Start when the current rate is far below the fair one. This protocol is well designed for continuous and long lived data streams, such as multicast IPTV. We study M 2C performances in terms of bandwidth-sharing fairness and loss rate. This evaluation shows that M 2C is robust and T CP -friendly for most network situations. Besides, we also provide an analysis of the signaling generated. Finally, we compare M 2C and W EBRC performances, showing significant improvements. Index Terms—Congestion control, fairness, T CP friendliness, multicast.
I. I NTRODUCTION Sending a file or an IPTV channel from a server to a very large number of receivers is a service that can benefit from the use of IP multicast in a provider network. However, each receiver must be able to adapt its reception rate to its network capacity, using for example a layered approach: for video [1] or file transfer. Moreover multicast streams have to fairly share the available bandwidth with competing TCP connections. Hence they must use a TCP friendly multicast congestion control mechanism [2]. W EBRC [3][4] is the leading multicast congestion control protocol. W EBRC fair bandwidth sharing computation depends on the loss rate and on an approximation of the RT T based on the multicast join duration. However, the multicast join delay is subject to a variable latency in most actual routers, due to the scheduling of the routing messages. For example, an average delay of 150ms per hop has been measured in [5]. This leads W EBRC to overestimate the RTT and to obtain less than the fair bandwidth. Moreover, even with a join time corresponding to the RT T additional experiments [10] show that W EBRC
is not fair in some cases with several competing T CP streams. This paper presents a Multicast Congestion Control (M 2C ) for very large groups of receivers. This protocol is layered and receiver-driven. The sender part of M 2C is based upon W EBRC . Whereas, the receiver part, which is the main proposal of this paper, can be divided into two mechanisms: • A Congestion Avoidance (CA) mechanism allowing M 2C to fairly share the bandwidth. • A Slow-Start (SS ) mechanism allowing M 2C to approach the fair rate more quickly. The main contribution is to combine the two mechanisms CA, SS in order to create a congestion control protocol able to converge quickly to the fair rate and to minimize the rate variations once this fair rate is reached. Moreover, we have evaluated the performance of M 2C in terms of bandwidth-sharing fairness and loss rate. A testbed was designed to analyze the CA and SS behaviors under various network conditions combining router buffer size, propagation time, rate of the bottleneck, number of T CP and M 2C competing streams and heterogeneous RT T . This study shows that M 2C is robust and T CP -friendly for most network situations. Besides, we also provide an analysis of the signaling generated. Finally, we compare M 2C and W EBRC performances, showing significant improvements. II. A DDRESSED ISSUES The main goal of this work is to create a robust T CP friendly multicast congestion control with a very high scalability. Moreover, we focus exclusively on a receiver driven protocol in order to allow each receiver to adapt its rate to its own bandwidth capacity. The first goal is to obtain a fair rate, meaning the rate a T CP connection would get. Thus, to remain T CP -friendly, previous analysis [6][7] show that the T CP equity depends mainly on loss rate and RT T . To preserve the very high scalability property, a receiver
• •
Adapt its rate with smooth variations to maintain the video quality and limit the viewer disturbance. Minimize the convergence time to quickly reach the fair rate to reduce important rate variation period.
The next sections detail M 2C mechanisms to address these issues. III. BASIC
IDEA
On one hand, the sender provides continuously a set of calibrated channels or layers, each identified by a multicast group. On the other hand, M 2C is receiver driven, which means that each receiver decides to increase or decrease its reception rate. Thereby, each receiver can join more or less groups until its received rate reaches the Estimated Fair Rate (EF R). The main difficulty of this algorithm is to determine EF R considering the issues mentioned in the previous section. The basic idea for EF R calculation is derived from T CP [8][9]: •
•
The Slow Start (SS ) is designed to fill in as fast as possible the buffers of the bottleneck router. SS slope is an exponential growing function to quickly approach the fair rate. The Congestion Avoidance (CA) is designed to share the bandwidth fairly. Following a T CP friendly Additive Increase and Multiplicative Decrease (AIM D) mechanism, the CA slope is a linear growing function. CA slope is very smooth to limit rate variations.
Moreover, when a competing stream stops and frees some bandwidth, the fair rate changes too. As CA grows slowly, M 2C must re-activate SS to approach quickly the new fair rate. At this point, two issues remain: •
•
How the AIM D mechanism can be fair if M 2C cannot compute directly the RT T ? We propose to compute an Estimated Round Trip Time (ERT T ) based on One Way Delay (OW D) and Estimated Buffering Time (EBT ). How can M 2C know that EF R is far below the fair rate and thus must re-activate the SS algorithm? We propose to evaluate a pseudo T CP loss cycle to determine if EF R is far below the fair rate.
30
30
Layer N Layer N+1 Layer N+2 ...
20
Rate (Kb/s)
Rate (Kb/s)
cannot send acknowledgments or any feedback to the sender. This means that there is no RT T for M 2C streams, but we have to estimate a pseudo RT T that a T CP connection would get between the same endpoints. Another issue is to design a protocol fitted to long lived streams such as IPTV. Hence, M 2C must both:
10 0
0
5
20 10 0
10 15 20 25 30
Layer N Layer N+1 Layer N+2 ...
0
5
10 15 20 25 30
Time (s)
Time (s)
(a) W EBRC sender channels Fig. 1.
(b) M 2C sender channels
The sender dynamic channels
IV. P ROPOSITION
DETAILS
The rationale of M 2C is based on previous W EBRC experimentation [5] [10] and T CP analysis [6][7]. This section explains the sender algorithm followed by the details of the receiver part for each mechanism listed in the previous section. A. The sender part As introduced earlier, the sender continuously streams multiple channels or layers each identified by a multicast group. Moreover, M 2C uses a dynamic layering proposed in FLID-DL [11] and W EBRC [3]. This mechanism ables the receiver to reduce its reception rate regardless of the delay for leaving a group. Each channel starts with the highest rate channel rateM AX and decreases progressively until it reaches a minimum threshold. Once this threshold is reached, the channel becomes quiescent and stops sending data for this multicast group. This way, a receiver has just to wait to reduce its reception rate. Of course, each time a channel becomes quiescent, another channel starts at the highest rate. The channel rate decreases in function of the elapsed time t since the channel has started, corresponding to a reduction factor P K each Time Slot Duration (T SD): channel rate(t) := channel rateM AX ∗ β(t) t∗K β(t) := P ( T SD )
(1)
With: P := 0.75 K := 4 T SD := 10
The base slope factor. The speed up factor. The Time Slot Duration (in s).
The only difference with W EBRC is the speed up factor K allowing to reduce the channel rate more quickly in order to improve the protocol reactivity to congestion. However, the number of multicast join and leave signaling is K times greater than with W EBRC . Therefore, we limit K to 4 to keep a moderate average of
And according to [8]: ERT T
Fig. 2.
The receiver state-transition diagram
" 0.8 control messages per second for a receiver. Reducing T SD can improve reactivity too, but we have to keep it large, since dynamic layering is only usable if the join time is below the T SD. M 2C extends W EBRC header with a timestamp field to compute the Estimated Buffering Time and the One Way Delay. This requires to synchronize sender and receiver clocks via methods such as N T P or GP S . 2K T SD
B. The receiver part Each receiver must join new channels while its reception rate is below EF R. Moreover, receivers only leave quiescent channels since the received rate is automatically reduced by the source dynamic layering. The main part of M 2C is the EF R computation by the receiver. The state-transition diagram of figure 2 describes how EF R is managed. This diagram is very similar to the T CP one, with the addition of a new transition, named Far below Fair Rate (F F R), allowing M 2C to re-activate the Slow Start (SS ). We will detail this diagram after describing the computation of ERT T . 1) Computation of ERT T : As expressed in the problem statement, M 2C cannot calculate the RT T and must estimate a pseudo RT T based on: • The One Way Delay (OW D ). It is the difference between the packet arrival time and the packet timestamp. This measure is sensitive to clock synchronization between the source and the receiver. • The Estimated Buffering Time (EBT ). It is computed via the last jitter, which is the difference between the last two OW Ds. This measurement is independent of clock synchronization. EBT
:= max(0, EBT + last jitter)
In fact, the RT T is composed of a forward (P Tf ) and a backward (P Tb ) propagation time, as well as a forward (BTf ) and a backward (BTb ) buffering time. For our pseudo T CP connection, we may assume that P Tf " P Tb and BTb " 0: RT T " 2 ∗ P T + BTf . Since OW D := P Tf + BTf and EBT " BTf : last ERT T
:= 2 ∗ OW D − EBT
:= 0.75 ∗ ERT T + 0.25 ∗ last ERT T
2) Congestion Avoidance (CA) state: CA is based on the T CP -friendly AIM D algorithm described in [12] and based on the T CP analysis [6][7]. For each packet: packet size2 window size inc window size EF R := EF R + ERT T With:
inc window size := α ∗
window size := EF R ∗ ERT T
This algorithm is driven by: • A multiplicative decrease factor β . Contrary to T CP , β is not a constant value and is computed for each received packet using expression (1) where t is the time interval between the last two packets. • An additive increase factor α derived from [12]: α := 3.0 ∗
1.0 − β 1.0 + β
The Estimated Round Trip Time (ERT T ). The T CP -friendliness of CA depends on ERT T accuracy. Moreover, a CA smooth rate variation is insured since α is small. 3) Slow Start (SS ) state: The SS growing function is exponential in order to quickly reach the fair rate. For each packet received: •
EF R :=
EF R β
This slope is the opposite of the sender channel one and thus limits the congestion period following each SS . 4) Congestion Event (CE ) transition: CE is the single signal reducing the EF R. This signal is triggered by a packet loss in any channel. Each CE reduces the EF R and turns M 2C in CA state: EF R := EF R ∗ β
5) Far below Fair Rate (F F R) transition: As previously mentioned, the CA rate variation should be smooth, which leads M 2C to converge very slowly to the fair rate: e.g. it takes several hours in CA to converge to 1Mb/s with 1s of RT T . Therefore, M 2C has to reactivate the SS when EF R is too far below the fair rate. When sharing fairly the bandwidth with some T CP or T CP -friendly streams, congestion events should occur regularly. We compute a TCP Loss Cycle Estimation
A. Criteria 1) Index of Fairness (F ): It evaluates the bandwidth sharing between all competing streams. F is computed as defined by Jain [14]:
Fig. 3.
An example of the testbed with 2 senders and 2 receivers
F
:=
With:
Fig. 4.
Parameters used for the evaluation
(T CP LCE ) corresponding to the delay between two consecutive losses for a pseudo T CP stream. It is derived from [6][7][8]: window size N B RT T := packet size last V ERT T := |last ERT T − ERT T | V ERT T
T CP ERT T
:= 0.75 ∗ V ERT T +
0.25 ∗ last V ERT T
:= ERT T + 4 ∗ V ERT T
T CP LCE := N B RT T ∗ T CP ERT T
Where V ERT T is the mean ERTT variation. Thereby, once the delay since last loss is greater than T CP LCE , M 2C considers that EF R is too far below the fair rate and switches to SS state. V. M 2C
EVALUATION
This section presents a set of experiments to evaluate M 2C in terms of fairness, T CP -friendliness, loss rate and signaling overhead. These experiments were conducted on a dedicated testbed (cf. figure 3). Routers are Linux stations running the XORP routing daemon (PIM-SM, IGMPv3), the NETwork EMulation (N ET EM ) module to emulate different propagation times and the Token Bucket Filter (T BF ) module to change the bottleneck rate and the buffer size of the router with parameters of the figure 4. To evaluate long lived multicast streams, each single test runs for 10 minutes. T CP streams were using new-RENO congestion control algorithm, whereas multicast ones were using our M 2C implementation [13]. For all following experiments the bottleneck is fully used. Let us define the evaluation criteria and then present 4 scenarii in order to analyze specific behaviors of M 2C .
!"
N
#2 N i=1 bi "N 2 i=1 bi
bi
The throughput of connection i.
N
The number of connections.
The streams share fairly the bandwidth, when F ≈ 1. Whereas a totally unfair allocation has F ≈ 1/N when one stream starves all others. 2) Loss rate (LR): It is the ratio between the numbers of lost and sent packets. A high LR indicates an aggressive behavior, which may penalize the application layer. Streams are less aggressive when LR ≈ 0. 3) Signaling Overhead (SO): It evaluates the impact of M 2C in the control plane. SO is the average number of join and leave messages per second explicitly requested by M 2C . B. Evaluation 1) Signaling: In all following tests, each session generates SO ≈ 0.8 messages per second, as expected in section IV.A. Thus, SO is a predictable value and is independent of the number of channels currently joined. 2) M 2C and T CP long lived competing streams: The results point out that M 2C is generally quite fair (F " 0.93) for all 30 network parameter combinations of figure 4. Moreover, M 2C loss rate (LRM 2C " 2.0%) is similar to T CP loss rate (LRT CP " 1.4%). 3) Population of long lived competing streams: This scenario experiments 5 long lived competing streams: n T CP versus (5 − n) M 2C , n ∈ [0..4]. These results show that M 2C is fair (F " 0.96) with multiple long lived competitors. The fairness is improved with larger buffer. For example, F " 0.93 when the buffer size is 10, and 0.95 < F ≤ 0.96 otherwise. For this scenario the loss rate is slightly more important for M 2C(LRM 2C " 5.6%) than for T CP (LRT CP " 3.2%), but is still satisfactory. 4) Background traffic: This scenario takes into account a more realistic model of traffic with: • A background traffic, composed of many short T CP connections such as those used for web browsing. The start time of these connections is defined by a Poisson process generating an average of
1
Jain fairness
0.875 0.75 0.625 0.5
All 30 combinations of propagation time, buffer size and bottleneck rate F(TCP/TCP)
Fig. 5.
F(M2C/TCP)
F(M2C/M2C)
Fairness of M 2C with background traffic
Jain fairness
1 0.875 0.75 0.625 0.5
10
25
50
F(TCP/TCP)
75 100 10 25 50 75 100 10 25 50 75 100 10 25 50 75 100 F(shortest_path/longest_path) in function of buffer size (in packets) F(M2C/TCP) F(TCP/M2C) F(M2C/M2C)
(a) Bottleneck at 1Mb/s Jain fairness
1 0.875 0.75 0.625 0.5
10
25
50
F(TCP/TCP)
75 100 10 25 50 75 100 10 25 50 75 100 10 25 50 75 100 F(shortest_path/longest_path) in function of buffer size (in packets) F(M2C/TCP) F(TCP/M2C) F(M2C/M2C)
(b) Bottleneck at 4Mb/s Fig. 6.
•
Fairness of M 2C with heterogeneous RT T
100 connections per test. Moreover, each connection sends an amount of data following an exponential distribution, such that 85% of these connections carry less than 6 KB of data. Two long lived T CP or M 2C streams: 2 T CP , T CP + M 2C and 2 M 2C .
Figure 5 shows that the ”noise” generated by the short T CP connections does not really disturb M 2C , neither when competing with the long lived T CP stream (F " 0.92, LRM 2C " 1.67 and LRT CP " 1.66), nor with the long lived M 2C stream (F " 0.99 and LRM 2C " 5.07). 5) Heterogeneous RT T : This scenario shows M 2C and T CP behavior with competing streams having a different RT T . Two streams (s1, s2), are sent via two paths: s1 path has no added propagation delay and s2 path has a 50 ms delay added in each direction. It is well known that T CP is not fair in case of heterogeneous RT T and favors the shortest path stream. Figure 6 shows that this behavior is also true for M 2C . Besides, results show that a larger buffer size improves fairness. This is because larger buffers leads to higher RT T . Thus the relative difference of RT T s between the shortest and the longest path is decreased.
Fig. 7.
Overview of M 2C and W EBRC evaluation
6) Summary: All M 2C results are good and improve with buffer size: in figure 7 the fairness is always > 0.9 with a buffer size of 100 packets. This is an encouraging result since current routers usually have large buffers. VI. C OMPARISON
WITH
W EBRC
Among all previously proposed highly scalable congestion control protocols, W EBRC obtains the best results in term of fairness [5]. This section presents W EBRC mechanisms and compares it with M 2C . A. W EBRC mechanisms The layered multicast congestion control protocol principle is to join and leave multicast groups to manage the received rate. But, the multicast leave delay can last several seconds causing long lasting congestions. Dynamic Layering was first proposed in FLID-DL [11] to solve the problem of leave latency. This solution is used and improved in the sender part of W EBRC . Moreover, the T CP -friendliness is an important part of W EBRC , as the receiver uses a fair rate evaluation based on the T CP mean Rate EQuatioN (REQN ). REQN depends on the loss rate and on an approximation of the RT T based on the multicast join duration. B. W EBRC evaluation In order to compare M 2C and W EBRC behavior, all the previous tests were repeated with W EBRC . This evaluation was done with our own implementation of W EBRC [13] and does not involve the join latency problem since XORP is not affected. An overview of the M 2C and W EBRC evaluation is given in figure 7. 1) Signaling: The difference between M 2C and W EBRC source is that K := 1 for W EBRC . So, each session generates SO ≈ 0.2 messages per second, which is predictable and 4 times less than for M 2C . 2) W EBRC and T CP long lived competing streams: The results point out that W EBRC is generally quite fair (F " 0.90, LRW EBRC " 1.0% and LRT CP " 1.3%). These results confirm those of [3] and are close to M 2C results.
1
VII. C ONCLUSIONS
Jain fairness
0.875 0.75 0.625 0.5
All 30 combinations of propagation time, buffer size and bottleneck rate F(TCP/TCP)
Fig. 8.
F(WEBRC/TCP)
F(WEBRC/WEBRC)
Fairness of W EBRC with background traffic
Jain fairness
1 0.875 0.75 0.625 0.5
10
25
50
F(TCP/TCP)
75 100 10 25 50 75 100 10 25 50 75 100 10 25 50 75 100 F(shortest_path/longest_path) in function of buffer size (in packets) F(WEBRC/TCP) F(TCP/WEBRC) F(WEBRC/WEBRC)
(a) Bottleneck at 1Mb/s Jain fairness
1 0.875
10
25
50
75 100 10 25 50 75 100 10 25 50 75 100 10 25 50 75 100 F(shortest_path/longest_path) in function of buffer size (in packets) F(TCP/TCP) F(WEBRC/TCP) F(TCP/WEBRC) F(WEBRC/WEBRC)
(b) Bottleneck at 4Mb/s Fig. 9.
We have presented M 2C , a receiver-driven and highly scalable multicast congestion control protocol designed for long lived streams. Its performances were evaluated in terms of fairness, loss rate and signaling overhead. Experimental results showed M 2C robustness and its ability to be used in various network environments and in competition with multiple short connections and long lived streams. Moreover, experiments with W EBRC bore out the improvements of M 2C in term of fairness even if the loss rate is slightly more important too. Further work will focus on the application of M 2C to multicast hierarchical video for IPTV. We will try to improve the convergence time to reduce the ”zapping” delay. Indeed, M 2C Slow Start last several dozens of seconds, due to an exponential slope which only doubles each 5 seconds. Moreover, we intend to study the effect of this type of congestion control on the application level. R EFERENCES
0.75 0.625 0.5
AND FURTHER WORK
Fairness of W EBRC with heterogeneous RT T
3) Population of long lived competing streams: These results show that W EBRC is not really fair (F " 0.83) for multiple long lived competitors. Unlike M 2C , the W EBRC loss rate grows proportionally to the number of competing W EBRC streams: from LR1∗W EBRC+4∗T CP " 3.2% to LR5∗W EBRC " 9.5%. 4) Background traffic: Figure 8 shows that the ”noise” generated by the short T CP connections does not really disturb W EBRC , when competing with the long lived T CP stream (F " 0.91, LRW EBRC " 1.46 and LRT CP " 1.45). But unlike M 2C , two long lived competing W EBRC streams are not really fair with each other (F " 0.84 and LRW EBRC " 1.31).
5) Heterogeneous RT T : W EBRC is mostly fairer than T CP or M 2C are. But W EBRC is totally unfair (F " 0.62), when competing with others W EBRC streams with the 4Mb/s bottleneck link (cf. figure 9). RFC 3738 [4] recommends that the receiver should not join if the received rate is not sufficiently lower than the maximum received rate observed since the last join. Additional experiments have shown that disabling this recommendation can improve W EBRC behavior.
[1] S. R. McCanne, “Scalable compression and transmission of internet multicast video,” Ph.D. dissertation, EECS Department, University of California, Berkeley, Dec. 1996. [2] M. Handley et. al., “The reliable multicast design space for bulk data transfer,” IETF, RFC 2887, Aug. 2000. [3] M. Luby et. al., “Wave and equation based rate control using multicast round trip time,” in ACM SIGCOMM’02, 2002. [4] M. Luby and V. Goyal, “Wave and equation based rate control building block,” IETF, RFC 3738, April 2004. [5] V. Lucas, J.-J. Pansiot, and M. Hoerdt, “Influence du temps d‘adh´esion sur le contrˆole de congestion multicast,” in CFIP’06, Eds. Tozeur (Tunisie): Herm`es, Oct 2006, pp. 115–126. [6] M. Mathis, J. Semke, and J. Mahdavi, “The macroscopic behavior of the TCP congestion avoidance algorithm,” ACM - CCR, vol. 27, no. 3, 1997. [7] J. Padhye et. al., “Modeling TCP throughput: A simple model and its empirical validation,” in Proceedings of the ACM SIGCOMM ’98, 1998, pp. 303–314. [8] V. Jacobson, “Congestion avoidance and control,” in ACM SIGCOMM ’88, Stanford, CA, August 1988, pp. 314–329. [9] W. Stevens, “Tcp slow start, congestion avoidance, fast retransmit, and fast recovery algorithms,” IETF, RFC 2001, Jan. 1997. [10] V. Lucas et. al., “Vers un m´ecanisme de contrˆole de congestion dirig´e par les r´ecepteurs pour le multicast,” in CFIP’08. Les Arcs (France): http://hal.archives-ouvertes.fr/hal-00250191/en/, march 2008. [11] J. W. Byers et. al., “Flid-dl : Congestion control for layered multicast,” IEEE journal on selected areas in communications, vol. 20, No.8, pp. 1558–1570, October 2002. [12] Y. R. Yang and S. S. Lam, “General aimd congestion control,” in ICNP ’00. Washington, DC, USA: IEEE Computer Society, 2000, pp. 187–198. [13] “Flid-sl, flid-dl, webrc and m2c implementation.” [Online]. Available: http://svnet.u-strasbg.fr/mcc [14] D. Chiu and R. Jain, “Analysis of the increase and decrease algorithms for congestion avoidance in computer networks,” Computer Networks and ISDN Systems, vol. 17, no. 1, p. 114, 1989.
