2 MotivationPreliminary: TCP is (obviously) the dominant transport protocol in cloud and data center scenariosWe focus on the following scenario: N long-lived TCP connections sharing a bottleneck linkTwo flavors of TCP:TCP Cubic (default CC of Linux)TCP NewReno as a legacy reference
3 ContributionsMean field approach -> fluid model of interactions of TCP connectionsValidation against ns-2 simulationsExtensive comparison between Cubic and New Reno in cloud scenarios
4 TCP CubicFor large BDP (bandwidth delay product) network – long fat pipewhere:t is the time since the last lossC is a constantwmax 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 lossFast increase until last max congestion window followed by smooth probing for additional bandwidthLinux kernel since
6 TCP Cubic Cubic can also operate in low BDP networks: where R(t) is the estimated RTT at time tIn 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 DCScenario B: intra DCScenario C: inter DCClouds: most traffic stays within a rack (75%)Colocation of apps and dependent componentsOther DCs: > 50% leaves the rackBandwidthRTTBDPBuffer sizeFTTH client100 Mbps20 ms166 pkts50 pktsintra DC1 Gbps1 ms83 pktsinter DC50 ms4150 pkts500 pkts
8 Network model The state of a connection is The state of the queue is Buffer size: NBThe state of a connection isThe state of the queue isThe current RTT isThe current loss probability isCapacity : NL pkts/sN TCP Cubicconnections
9 Performance analysis State of the system: is a mean-field interaction system with N objectsThe 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 ﬁeld 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 analysisFormer model derived from the model for NewReno proposed inF. 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, SepOur extensions :Extension to Cubic whose window growth rate depends on timeNeed 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 startVery good accuracy for FTTH DC and intra DC scenarios
13 Numerical validation Less accuracy for inter-DC Only scenario in pure Cubic modeThe 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 scenariosQuestion 2 : how efficient is TCP Cubic with small buffer sizes?[Lei07] observed through experimentation detrimental effects of small buffers for CubicHence 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 beaucoupReno remplit souvent pas du tout => Cubic plus performants quand buffers petits, et c’est ce qu’on veutCoV (std/mean) of congestion windowCoV close to 0 : very good fairnessThe 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 cxCubic is more greedy than New RenoTCP New Reno is clearly less efficient than Cubic for buffer sizes smaller than 60% of the BDPOur model suggests that Cubic is able to survive with buffer sizes as small as 20% of the BDPCubic remplit tout le temps et beaucoupReno 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 sizesFuture work:Introduction of heterogeneity - mix of short and long-lived connections, different RTT, other versions (Compound)Need to investigate synchronization effects of Cubic mode