1. *Orange Labs, Sophia Antipolis, France
Understanding TCP Cubic Performance in the Cloud: a Mean-field Approach
Sonia Belhareth*, Lucile Sassatelli◊, Denis Collange*,
Dino Lopez-Pacheco ◊, Guillaume Urvoy-Keller ◊
*Orange Labs, Sophia Antipolis, France
◊ Laboratoire I3S, Université Nice Sophia Antipolis – CNRS, France
IEEE Cloudnet 2013

2. Motivation
Preliminary: TCP is (obviously) the dominant transport protocol in cloud and data center scenarios
We focus on the following scenario: N long-lived TCP connections sharing a bottleneck link
Two flavors of TCP:
TCP Cubic (default CC of Linux)
TCP NewReno as a legacy reference

3. Contributions
Mean field approach -> fluid model of interactions of TCP connections
Validation against ns-2 simulations
Extensive comparison between Cubic and New Reno in cloud scenarios

4. TCP Cubic
For large BDP (bandwidth delay product) network – long fat pipe
where:
t is the time since the last loss
C is a constant
wmax is the largest congestion window prior to last loss

5. TCP Cubic Advantages of Cubic : Linux kernel since 2.6.19
Window growth independent from RTT but only time t since last loss
Fast increase until last max congestion window followed by smooth probing for additional bandwidth
Linux kernel since

6. TCP Cubic Cubic can also operate in low BDP networks:
where R(t) is the estimated RTT at time t
In practice: w(t)=max(wc(t),wtcp(t)) and the state of Cubic connection is < w(t),wmax>
Key remark: for a given scenario (latency, capacity and buffer size), Cubic is either in Cubic or TCP mode
[See paper for details]

7. Target scenarios : FTTH, intra-DC and inter-DC
Scenario A: FTTH client  DC
Scenario B: intra DC
Scenario C: inter DC
Clouds: most traffic stays within a rack (75%)
Colocation of apps and dependent components
Other DCs: > 50% leaves the rack
Bandwidth
RTT
BDP
Buffer size
FTTH client
100 Mbps
20 ms
166 pkts
50 pkts
intra DC
1 Gbps
1 ms
83 pkts
inter DC
50 ms
4150 pkts
500 pkts

8. Network model The state of a connection is The state of the queue is
Buffer size: NB
The state of a connection is
The state of the queue is
The current RTT is
The current loss probability is
Capacity : NL pkts/s
N TCP Cubic
connections

9. Performance analysis State of the system:
is a mean-field interaction system with N objects
The occupancy measure is the fraction of connections in each state at time t:
Theorem 3.1 of [K70] ensures that converges uniformly almost surely to the solution of coupled ODE:
Y is a homogeneous Markov chain
[K70] T. G. Kurtz, Solutions of Ordinary Differential Equations as Limits of Pure Jump Markov Processes, Journal of Applied Probability, vol. 7, no. 1, pp. 49–58, 1970.
[BL08] M. Benaïm and J.-Y. Le Boudec, A class of mean field interaction models for computer and communication systems, Performance Evaluation, vol. 65, no , pp. 823–838, 2008.

10. Performance analysis The cx detects a loss The cx gets the ACK
Input rate

11. Performance analysis
Former model derived from the model for NewReno proposed in
F. Baccelli, D. R. McDonald, and J. Reynier, “A mean-field model for multiple TCP connections through a buffer implementing red,” Perform. Eval., vol. 49, no. 1-4, Sep
Our extensions :
Extension to Cubic whose window growth rate depends on time
Need to account for loss time (loss process is assumed Poisson as in Baccelli et al.)

12. Numerical validation Comparison against ns-2 simulations
Note that we do not model the slow start
Very good accuracy for FTTH  DC and intra DC scenarios

13. Numerical validation Less accuracy for inter-DC
Only scenario in pure Cubic mode
The synchronization also studied by Hassayoun et al. through simulations.
Persists even with RED, traffic on reverse path or multiplexing level.

14. Performance Analysis Question 1: is TCP Cubic as fair as NewReno?
At least for TCP mode of Cubic in first two scenarios
Question 2 : how efficient is TCP Cubic with small buffer sizes?
[Lei07] observed through experimentation detrimental effects of small buffers for Cubic
Hence the question : is it due to (early) implementation of Cubic or is it intrinsic to Cubic itself?

15. Fairness CoV (std/mean) of congestion window
Cubic remplit tout le temps et beaucoup
Reno remplit souvent pas du tout => Cubic plus performants quand buffers petits, et c’est ce qu’on veut
CoV (std/mean) of congestion window
CoV close to 0 : very good fairness
The larger the CoV, the smaller the fairness
(CoV related to Jain Fairness index)
Take-away: Cubic is more fair than TCP (in TCP mode)

16. Impact of buffer size Better utilization by Cubic
Both Cubic and New Reno are greedy  not good for newly arriving cx
Cubic is more greedy than New Reno
TCP New Reno is clearly less efficient than Cubic for buffer sizes smaller than 60% of the BDP
Our model suggests that Cubic is able to survive with buffer sizes as small as 20% of the BDP
Cubic remplit tout le temps et beaucoup
Reno remplit souvent pas du tout => Cubic plus performants quand buffers petits, et c’est ce qu’on veut

17. Conclusions and future work
Model for TCP mode of Cubic (and NewReno)
Valid for a large set of cloud related scenarios
(for 1 Gb/s link, need 16 ms or RTT for triggering Cubic mode)
Allow to investigate some fundamental features related to fairness and impact of buffer sizes
Future work:
Introduction of heterogeneity - mix of short and long-lived connections, different RTT, other versions (Compound)
Need to investigate synchronization effects of Cubic mode