CUBIC : A New TCPFriendly HighSpeed TCP Variant

1
CUBIC A New TCP-Friendly High-Speed TCP Variant
2005.1.30 v 0.2

• 2005.2.
• Injong Rhee, Lisong Xu
• Member, IEEE

2
Outline

• 1. Motivation
• 2. Introduction
• 3. Performance Evaluation
• 4. Conclusion

3
1. Motivation

• In the last few years, Many TCP variants have
  been proposed to address the under-utilization
  problem due to the slow growth of TCP congestion
  window.(e.g. FAST, HSTCP, STCP, HTCP, SQRT,
  Westwood BIC)
• While the window growth of new protocols is
  scalable, their fairness issue has remained as a
  major challenge.(e.g. TCP Friendliness, RTT
  fairness, and inter/intra protocol fairness)
• The crux of the problem is to find a suitable
  growth function.

4
2. Introduction CUBIC A New TCP Variant

• CUBIC is an enhanced version of BIC
• Simplifies the BIC window control using a cubic
  function.
• Improves its TCP friendliness RTT fairness
• The window growth function of CUBIC is based
  onreal-time (the elapsed time since the last
  loss event), so that it is independent of RTT.
• First proposed by Shorten and Leith, May 2003
  Yale workshop, and also later in HTCP.
• Window growth becomes independent on RTT
• RTT fairness and also TCP friendliness under
  low delays.
• HTCP, SQRT.

5
2. Introduction BIC function

• BIC overall performs very well in evaluation of
  advanced TCP stacks on fast long-distance
  production networks by SLAC ( Stanford Linear
  Accelerator Center).
• BIC (also HSTCP STCP) growth function can be
  still aggressive for TCP especially under
  short RTTs or low speed networks.
• Currently a default TCP stack for Redhat Linux
  2.6.
• Microsoft and Sun are considering BIC to include
  in their OS stacks.

6
2. Introduction CUBIC function
accelerate
slow down
accelerate
where C is a scaling factor, t is the elapsed
time from the last window reduction, and ß is a
constant multiplication decrease factor
7
2. Introduction CUBIC New TCP Mode

• In short RTT networks, the window growth of CUBIC
  is slower than TCP since CUBIC is independent of
  RTT. We emulate the TCP window algorithm after a
  packet loss event.

Average sending rate of AIMD
(TCP). Thus,
The size of TCP window after time t from window
reduction.
8
3.1 Testbed (Dummynet) Setup
Linux
1 Gbps link
FreeBSD
Setting RTT for each path between Senders and
Receiver RTT for Background Traffic
Exponential Distribution (Next Slide)
Bottleneck Point 800 Mbps
Sender 1
Receiver
Router 1
Router 2
Sender 2
Background TrafficGenerator 2
Background TrafficGenerator 1
9
3.1 Testbed Setup Background Traffic Generation

• TCP Flow RTT Exponential Distribution
• The mean is set to 66 ms (one-way delay), then
  the CDF is very similar to the CDF of RTT samples
  shown in paper
• Variability in TCP Roundtrip Times by J.
  Ajkat, J. Kaur, F.D. Smith, and K. Jeffay in
  SigComm Internet Measurement Conference, 2003.
• Inter-Arrival Time Between Two Successive TCP
  connections Exponential Distribution (observed
  from Floyd and Paxson)
• This is the parameter that we used to control the
  background traffic load
• TCP Flow Duration Lognormal (Body) and Pareto
  (Tail) Distribution
• Using the parameters from paper Generating
  Representative Web Workloads for Network and
  Server Performance Evaluation by Paul Barford,
  Mark Crovella in SigMetric 1998

10
3.2 TCP Friendliness

• NS simulation RTT 10 ms 20 Mbps 1 Gbps

11
3.2 TCP Friendliness (cont.)

• NS simulation RTT 100 ms 20 Mbps 1 Gbps

12
3.2 TCP Friendliness (cont.)

• Dummynet Testbed RTT 5ms 800 Mbps, 100
  router buffer of the BDP
  with 80 200 Mbps background traffic

Background traffic
80 Mbps
200 Mbps
Link Utilization ()
TCP Friendliness on short RTT - 5ms
13
3.2 TCP Friendliness (cont.)

• Dummynet Testbed RTT 10ms 800 Mbps, 100
  router buffer of the BDP
  with 80 200 Mbps background traffic

Background traffic
80 Mbps
200 Mbps
Link Utilization ()
TCP Friendliness on short RTT - 10ms
14
3.2 TCP Friendliness (cont.)

• Dummynet Testbed RTT 100ms 800 Mbps, 100
  router buffer of the BDP
  with 80 200 Mbps background traffic

Background traffic
80 Mbps
200 Mbps
Link Utilization ()
TCP Friendliness on long RTT - 100ms
15
3.2 TCP Friendliness (cont.)

• Dummynet Testbed RTT 200ms 800 Mbps, 100
  router buffer of the BDP
  with 80 200 Mbps background traffic

Background traffic
80 Mbps
200 Mbps
Link Utilization ()
TCP Friendliness on long RTT - 200ms
16
3.3 RTT Fairness
Dummynet testbed RTT 40, 120, 240 ms 800
Mbps, Router buffer 50 of the BDP with 200 Mbps
background traffic
17
3.4 Stability NS Simulation Setup

• NS simulation High-Speed TCP Variants on 220ms,
  TCP SACK on 20ms and 2.5 Gbps with 5 router
  buffer of the BDP

18
3.4 Stability NS Simulation Result (cont.)
19
3.4 Stability NS Simulation Result (cont.)
NS simulation High-Speed TCP Variants on
220ms, TCP SACK on 20ms and 2.5 Gbps, Router
buffer 5 of the BDP
HTCP have some stability issues (this needs to
be confirmed with the original authors of
HTCP).
20
3.4 Stability NS Simulation Result (cont.)

• Coefficient of Variations in the stability test
  on NS simulation

21
3.4 Stability Dummynet Testbed Setup (cont.)

• Dummynet testbed High-Speed TCP Variants on
  200ms, TCP SACK on 20ms, 800 Mbps Router
  buffer 100 of the BDP with 200Mbps background
  traffic

Linux
1 Gbps link
FreeBSD
High-Speed TCP Variant Flows
Sender 1
Receiver
Long-lived TCP Flows
Router 1
Router 2
Sender 2
Background TrafficGenerator 2
Background TrafficGenerator 1
22
3.4 Stability Dummynet Testbed Result (cont.)
BIC
CUBIC
STCP
HSTCP
23
3.4 Stability Dummynet Testbed Result (cont.)
FAST
The throughput of FAST flows was lower than
that of TCP as much as TCP Friendliness
experiments due to small alpha parameter value.
24
3.5 Evaluation Summary

• CUBIC and HTCP had good TCP Friendliness
  especially on short RTT networks. FAST needs
  alpha parameter tuning.
• CUBIC and FAST had good RTT Fairness under both
  short and long RTT paths.
• CUBIC showed the best stability.FAST requires
  tuning alpha parameter.

25
4. Discussion

• How to define TCP-friendliness.
• How to measure stability and fairness.
• The role of background traffic what is the
  realistic traffic mix?

26
5. Conclusion

• A real-time based protocol seems a good idea.
• A CUBIC seems a good simplification of BIC, but
  is there any other choice for the window growth
  function?
• What makes a cubic function better than others?
• Any odd-order function would do well?

27
Reference

• 1 H. Bullot, R. Les Cottrell, and R.
  Hughes-Jones, "Evaluation of Advanced TCP Stacks
  on Fast Long-Distance Production Networks,
  Second International Workshop on Protocols for
  Fast Long-Distance Networks, February 16-17,
  2004, Argonne, Illinois USA
• 2 C. Jin, D. X. Wei and S. H. Low, "FAST TCP
  motivation, architecture, algorithms,
  performance," In Proceedings of IEEE INFOCOM
  2004, March 2004
• 3 S. Floyd, HighSpeed TCP for large congestion
  windows, INTERNET DRAFT, draft-floyd-tcp-highspee
  d-01.txt, 2003
• 4 T. Kelly, Scalable TCP Improving
  performance in highspeed wide area networks, ACM
  SIGCOMM Computer Communication Review, Volume 33,
  Issue 2, pp. 83-91, April 2003
• 5 R. Shorten, and D. Leith, "H-TCP TCP for
  high-speed and longdistance networks, Second
  International Workshop on Protocols for Fast
  Long-Distance Networks, February 16-17, 2004,
  Argonne, Illinois USA
• 6 T. Hatano, M. Fukuhara, H. Shigeno, and K.
  Okada, "TCP-friendly SQRT TCP for High Speed
  Networks," in Proceedings of APSITT 2003,
  pp455-460, Nov 2003.
• 7 C. Casetti, M. Gerla, S. Mascolo, M. Y.
  Sanadidi, and R. Wang, "TCP Westwood Bandwidth
  Estimation for Enhanced Transport over Wireless
  Links," In Proceedings of ACM Mobicom 2001, pp
  287-297, Rome, Italy, July 16-21 2001
• 8 L. Xu, K. Harfoush, and I. Rhee, "Binary
  Increase Congestion Control (BIC) for Fast
  Long-Distance Networks," In Proceedings of IEEE
  INFOCOM 2004, March 2004