1 / 17

Understanding TCP Cubic Performance in the Cloud: a Mean-field Approach

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

carsyn
Download Presentation

Understanding TCP Cubic Performance in the Cloud: a Mean-field Approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 : • 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 2.6.19

  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

  8. Network model 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: [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. 11-12, 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. 2002. • 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 • 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

  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

More Related