Feb 16, 2011 - AbstractâWe introduce a simple model of the Relentless Con- gestion Control proposed by Matt Mathis. Relentless Congestion. Control (RCC) ...
1
TCP Relentless Congestion Control Model
arXiv:1102.3270v1 [cs.NI] 16 Feb 2011
3
R´emi Diana1,3, Emmanuel Lochin2,3 1 T´ eSA/CNES/Thales, Toulouse, France 2 CNRS ; LAAS ; 7 avenue du colonel Roche, F-31077 Toulouse, France Universit´e de Toulouse ; UPS, INSA, INP, ISAE ; LAAS ; F-31077 Toulouse, France
Abstract—We introduce a simple model of the Relentless Congestion Control proposed by Matt Mathis. Relentless Congestion Control (RCC) is a modification of the AIMD congestion control which consists in decreasing the TCP congestion window by the number of lost segments instead of halving it. Despite some ongoing discussions at the ICCRG IETF-group, this congestion control has, to the best of our knowledge, never been modelled nor evaluated. In this letter, we provide an analytical model of this novel congestion control and compare its accuracy with simulations over ns-2. We also propose an improvement of this congestion control with the addition of a lost retransmission detection scheme. Index Terms—Relentless Congestion Control, Performance Evaluation
I. I NTRODUCTION Relentless Congestion Control (RCC) is a proposal from Matt Mathis which consists in a simple modification of the AIMD congestion control algorithm [2]. Basically, instead of halving the TCP congestion window after a loss, RCC proposes to decrease the current congestion window by the number of lost segments. It can be modelled as a strict implementation of van Jacobson’s Packet Conservation Principle1 . Indeed, during recovery, new segments are injected into the network in exact accordance with the segments that are reported to have been delivered to the receiver by the returning ACKs [3]. Relentless Congestion Control is in opposition to the idea that the Internet can attain sufficient fairness with simple network devices, send uniform congestion signals to all flows, and mandating that all protocols have equivalent responses to these congestion signals. RCC is an AIMD-unfriendly protocol and as a result, requires that the network allocates capacity through Fair Queuing or Fair Dropping queue managements. The benefit of these algorithms is that they segregate traffic into distinct flows and send different congestion signals to each flow (segment losses, ECN marks or queuing delay) to each flow such that the network, and not the end-system, controls capacity allocation [3]. RCC can be applied to any AIMD congestion control algorithm and thus, we could add RCC to current congestion controls such as Cubic, Newreno or Compound. Intuitively, RCC might enhance the performance of standard congestion controls when losses are not due to congestion (over very noisy wireless links) or long-fat product bandwidth networks 1 This principle suggests that a new packet should not be placed into the network until an old packet leaves.
(LFBP). In the first case, RCC would prevent severe congestion window decrease due to error link losses while in the context of LFBP networks and long delay links, RCC might achieve a higher throughput. In this letter, we propose an RCC model to assess the theoretical throughput that would achieve TCP Newreno with this slight modification. Then, to verify the accuracy of our model we compare analytical results with an ns-2 implementation of RCC. Finally, we propose an improvement of RCC with the addition of a lost retransmission detection scheme based on SACK+ [1] and discuss the parameters of the model. II. A NALYTICAL MODEL In this section, we develop a stochastic model of TCP Relentless Congestion Control algorithm coupled with the algorithm of selective acknowledgement (SACK). This leads to a simple analytic expression for the throughput of a saturated TCP Relentless sender as a function of loss rate p and the average round trip time (RT T ). Our RCC model lays on the well-known Padhye’s TCP model [5] where we borrow the same notation to ease the understanding. The resulting stochastic model is thus an adaptation of Padhye’s TCP model with RCC and SACK. The notations are presented in Figure 1. The period denoted T D defines an elementary cycle (corresponding to T DP in [5]), delimited by two consecutive decreases of the window Wi where i refers to the ith T D.
Fig. 1.
Evolution of the congestion window size over time
Let be Yi the number of packets sent in T Di , αi the number of the first loss, βi the amount of packets sent after αi to complete the round and Ni the number of retransmission done in T Di . We also define Xi the number of round in T Di and b the slope. Obviously, we have : Yi = αi + βi + Wi . Thus: E[Y ] = E[α] + E[β] + E[W ]
(1)
2
We now have to derive E[α] and E[β]. If we consider uniform and independent losses, α = k means that the first k − 1 packets are successfully sent and the k th packet is lost. The packet loss probability is independent and is denoted p. We can compute E[α] as follows: P k−1 P (α = k) = (1 − p)k−1 p −→ E[α] = ∞ p.k k=1 (1 − p) E[α] =
1 p
(2)
βi evolves from 0, if the losses occur at the top of the window to Wi − 1, if losses occur at the beginning of the window. The uniform aspect of losses implies the uniform distribution of βi in this range. It follows that: E[W ] − 1 (3) 2 The relation between window size in T Di−1 and T Di can be written as follows: Wi = Wi−1 − Ni−1 + Xib−1 as a consequence: E[β] =
E[X] − 1 E[N ] = (4) b The expected value of N can be evaluated with the same hypothesis than previously. In fact, if we consider uniform and independent losses with the elementary probability of p, then N follows a binomial law of parameters p, E[W ] − 1 where E[W ] − 1 is the mean amount of packets sent when the losses occur. Thus, E[N ] = p(E[W ] − 1) and (4) becomes: E[X] = bp(E[W ] − 1) + 1
(5)
The evolution of the window size can also be written using the slope b, which corresponds to the evolution pace of W . Xi /b−1
Yi
X
=
k=0
(Wi−1 − Ni−1 + k).b
Xi 1 − ) (6) 2b 2 If we now take the mathematical expectation of (6) assuming for a first approximation that Xi and Wi are mutually independent sequence of i.i.d random variables, it comes: =
Xi (Wi−1 − Ni−1 +
E[X] 1 − ) 2b 2 If we combine (7), (1), (2), (3) and (5) we obtain: E[Y ] = E[X](E[W ] − E[N ] +
(7)
1 bp(E[W ] − 1) + 1 1 − ) 2 b 2 1 3 .(bp(E[W ] − 1) + 1) = + E[W ] − 1 p 2
(E[W ] − p(E[W ] − 1) +
(8)
If we solve (8) and keep only the positive root we obtain: E[W ] = q b(p −
3 2
−
1 2(bp− 21 bp2 )
1 2 2bp )
−
4( p1
−
− bp2 + 32 bp + 1 1 2 )(− 2 bp(p
Moreover, we know that the average time of a T D corresponds to the average number of rounds in a T D multiplied by the average time of a round, which corresponds to an RT T . Thus, E[A] = E[X].RT T . Now, if we consider p near zero and combine the expressions of E[W ], E[Y ] and E[A], we obtain the average throughput of a Relentless flow T p :
1 2
√ + p b.
− 1) +
1+b 2b
−
1 p)
E[Y ] = Tp = E[A]
MSS 2
1 2
√ 16b+1 b
p
1 + o( ) p
(9)
Let C be the constant term in (9). We have a general expression for the throughput of a Relentless flow which is: Tp =
C.M SS 1 + o( ) RT T.p p
(10)
As in [4], the next step is to assess the value of constant C. III. L IMITS
OF THE MODEL
Our RCC model presents two limits. Firstly, TCP retransmission time out (RTO) is not considered. In fact, combining Relentless and SACK retransmission scheme leads to only one type of RTO which is the lost of a retransmitted packet. If the loss rate is low, this event can occur but can be considered as extremely rare. Secondly, the model does not take into consideration the impact of losses at the top of the congestion window. Thanks to SACK mechanism, we can detect all the lost packets a round later and trigger their retransmission. However, if a loss occurs at the top of the congestion window, its detection is possible only two rounds after. As the pace of the sent packets are driven by the pace of the received acknowledgements, this implies that the number of packets sent in the round following this lost is lower than the window size value. More generally, we can state that, if there are n losses at the top of the congestion window, the number of packets sent in the next T D is reduced by n. The impact of these two points are discussed in the simulation part. IV. S IMULATION Our model gives a simple approximation of the throughput of a Relentless flow as a function of the RT T and the loss rate p. To validate this model, we have implemented RCC with ns-2 and compared the results obtained. We used a simple topology with one lossy link between two nodes in order to estimate the maximum throughput of a Relentless flow. To verify the parameters of the model, simulations are done with a loss rate ranging from 0.03% to 5%. To estimate the maximum throughput of the Relentless flow, we have to ensure that we are not limited by the link capacity between the source and the destination. We set this capacity to 100Gb/s which is much more than the maximum achievable theoretical throughput for our set of chosen parameters. The first tested algorithm is the basic Relentless Congestion Control algorithm as described in the introduction. This means that RTO due to lost of retransmitted packets can occur. The results are presented in figure 2(a). The dotted line provides the theoretical result with C = 0.5 as constant. The constant is lower than the theoretical constant of the model which
3
is about 1.2 for b = 1. This implies that the throughput is quite degraded by the RTO. The second tested algorithm is an improvement of RCC which prevents RTO due to lost of retransmitted packets. The results with this algorithm, denoted RCC+, are presented in figure 2(b). RCC+ is detailed later in section V. Each point represents a simulation result with the corresponding parameters. The duration of the simulations are long enough to reach the steady state (i.e to remain in the congestion avoidance phase). Practically, the computation of the throughput is done over a period of 600 seconds when the steady state is reached. 1000
1000 rtt=50ms rtt=100ms rtt=200ms rtt=400ms
100 10
1 Simulation Theory (C=0.5) 0.001
0.01 Loss rate (p)
(a) RCC algorithm Fig. 2. flow
100
VI. C ONSTANT
VALUE AND LOSS DISTRIBUTION
Loss Model Uniform b=2 Gilbert Elliot b=3 b=4
C C C C
RCC = 0.50 = 0.66 = 0.72 = 0.78
RCC+ C = 1.0 C = 0.90 C = 0.90 C = 0.90
TABLE I I MPACT OF LOSS MODEL ON C
10
1 0.1
rtt=50ms rtt=100ms rtt=200ms rtt=400ms
retransmission. Actually, if the regular packet sent after the retransmission is acknowledged before the retransmitted one, we can suppose that the retransmitted packet is lost. Anyway, all these solutions are only different by their implementation: the result remains the same.
0.1
Simulation Theory (C=1) 0.001 0.01 Loss rate (p)
(b) RCC+ algorithm
Comparison of theoretical and simulated throughput of a Relentless
Figure 2(b) shows that the model perfectly fits the simulation with C = 1. Once again, C is lower than the constant given by the model. RCC+ prevents RTO due to lost retransmissions (we have checked inside the simulation traces that there was no retransmission time out). Thus, the difference of throughput between RCC+ and the model is linked to the second limitation raised section III and not taken into account in the model: the lost at the top of the congestion window. Nevertheless, for both RCC and RCC+ algorithms, we can note that the evolution’s law of throughput fits perfectly the model even if it overestimates the constant value and that RCC throughput evolves in p1 , as intuited by M. Mathis in [2]. We also underline that with RCC+, the maximum throughput is about two times larger than with RCC. V. RCC+
IN A NUTSHELL
As mentioned in part IV, we develop an improvement of RCC in order to avoid RTO due to lost of retransmissions. Of course, if a packet is lost each time retransmitted, RTO cannot be avoided. With TCP, each packet is re-sent no more than three times. In other words, it must be received before four RTTs elapsed, which is approximately the value of the retransmission timer. The configuration of this timer is also possible to enable more retransmission tries. In our implementation, we choose a discrete resolution of the problem as in [1]. However, we could chose a continuous solution and set a timer to each retransmitted packets. We could set this timer to λ ∗ RT T , with RT T the current estimation of RT T and λ > 1 to prevent spurious retransmissions. In our case, for each retransmitted packets, we fix a trigger. This trigger is the acknowledgement of the following regular packet which is sent after the retransmission. By regular, we refer to packets that do not correspond to a
In the previous section, we only have considered uniform losses pattern. We now propose to investigate the value of the constant of the model in the case of bursty loss channel as realised in [4]. We drive a set of experiments to evaluate C with an average burst size ranging from 2 to 4 following a Gilbert Elliott channel. An important point to note is that RCC flow throughput evolves in p1 even with bursty losses. Table I gives the results obtained. With RCC, the constant increases as a function of b. Indeed, when b increases, the losses are more bursty (i.e. grouped) and the probability to loose a retransmission decreases. Thus, RCC algorithm do not often trigger RTO and the throughput increases. This has been confirmed with an analysis of the experiment traces. On the contrary, as RCC+ prevents RTO triggering, the constant remains stable making the model robust (at least up to b = 4). However, the slight decrease of the constant value (from 1.0 to 0.9) might be explained by the increase of the average number of losses at the top of the congestion window as previously explained in section III. VII. C ONCLUSION We have proposed a model of Relentless Congestion Control algorithm and verified its accuracy with an ns-2 implementation and simulations. We have also proposed an improvement of the basic algorithm which allows to double the maximum throughput. We now consider the use of this model in a larger performance evaluation study which aims at evaluating RCC and RCC+ with various TCP variants. R EFERENCES [1] B. Kim, D. Kim, and J. Lee. Lost retransmission detection for tcp sack. IEEE Communications Letters, 9(8), September 2004. [2] M. Mathis. Relentless congestion control. In PFLDNet, Tokyo, Japan, May 2009. [3] M. Mathis. Relentless congestion control. Internet Draft draft-mathisiccrg-relentless-tcp-00.txt, Internet Engineering Task Force, March 2009. (Work in progress). [4] M. Mathis, J. Semke, J. Mahdavi, and Teunis Ott. The macroscopic behavior of the TCP congestion avoidance algorithm. Computer Communication Review, 27(3), July 1997. [5] J. Padhye, V. Firoiu, D. Tomsley, and J. Kurose. Modeling tcp throughput: A simple model and its empirical validation. SIGCOMM Comput. Commun. Rev., 28(4):303–314, Oct. 1998.
