Congestion Control Algorithms of TCP in Emerging Networks

1
Congestion Control Algorithms of TCPin Emerging
Networks

• Sumitha Bhandarkar Under the Guidance of Dr. A.
  L. Narasimha ReddySeptember 16, 2005

2
Motivation

• Why TCP Congestion Control ?
• Designed in early 80s
• Still the most predominant protocol on the net
• Continuously evolves
• IETF developing an RFC to keep track of TCP
  changes !
• Has issues in emerging networks
• We aim to identify problems and propose solutions
  for TCP in high-speed networks

3
Motivation

• Link speeds have increased dramatically
• 270 TB collected by PHENIX (Pioneering High
  Energy Nuclear Interaction eXperiment)
• Data transferred between Brookhaven National
  Laboratory, NY to RIKEN research center, Tokyo
• Typical rate 250Mbps, peak rate 600Mbps
• OC48(2.4 Gbps) from Brookhaven to ESNET,
  transpacific line (10 Gbps) served by SINET to
  Japan
• Used GridFTP (Parallel connections with data
  striping)

Source CERN Courier, Vol. 45, No.7
4
Motivation

• Historically, high-speed links present only at
  the core
• High levels of multiplexing (low per-flow rates)
• New architectures for high-speed routers
• Now, high-speed links are available for transfer
  between two endpoints
• Low levels of multiplexing (high per-flow rates)

5
Outline

• TCP on high-speed links with low multiplexing
• Design, analysis and evaluation of aggressive
  probing mechanism (LTCP)
• Impact of high RTT
• Impact on router buffers and loss rates
  (LTCP-RCS)
• TCP on high-speed links with high multiplexing
• Impact of packet reordering (TCP-DCR)
• Future Work

6
Where We are ...

• TCP on high-speed links with low multiplexing
• Design, analysis and evaluation of aggressive
  probing mechanism (LTCP)
• Impact of high RTT
• Impact on router buffers and loss rates
  (LTCP-RCS)
• TCP on high-speed links with high multiplexing
• Impact of packet reordering (TCP-DCR)
• Future Work

7
TCP in High-speed Networks
Motivation

• TCPs one per RTT increase does not scale well
• For RTT 100ms, Packet Size 1500 Byte

Source RFC 3649
8
TCP in High-speed Networks

• Design Constraints
• More efficient link utilization
• Fairness among flows of similar RTT
• RTT unfairness no worse than TCP
• Retain AIMD behavior

9
TCP in High-speed Networks

• Layered congestion control
• Borrow ideas from layered video transmission
• Increase layers, if no losses for extended period
• Per-RTT window increase more aggressive at higher
  layers

10
TCP in High-speed Networks
LTCP Concepts (Cont.)

• Layering
• Start layering when window gt WT
• Associate each layer with a step size ?K
• When window increases from previous addition of
  layer by ?K, increment number of layers
• For each layer K, increase window by K per RTT
• Number of layers determined dynamically based on
  current network conditions.

11
TCP in High-speed Networks
LTCP Concepts
K

12
TCP in High-speed Networks
Framework

• Constraint 1
• Rate of increase forflow at higher layer
  should be lower than flow at lower layer

K 2
WK2
dK1
K 1
WK1
dK
K
WK
dK-1
K - 1
WK-1
(K1 gt K2, for all K1, K2 ? 2)
Number of layers K when WK ? W ? WK1
13
TCP in High-speed Networks
Framework

• Constraint 2
• After a loss, recovery time for a larger flow
  should be more than the smaller flow

Flow 1
Slope K1'
WR1
Window
T1
Time
Flow 2
Slope K2'
WR2
Window
T2
(K1 gt K2, for all K1, K2 ? 2)
Time
14
TCP in High-speed Networks
Design Choice

• Decrease behavior
• Multiplicative decrease
• Increase behavior
• Additive increase with additive factor layer
  number
• W W K/W

15
TCP in High-speed Networks
Determining Parameters

• Analyze two flows operating at adjacent layers
• Should hold for other cases through induction
• Ensure constraints satisfied for worst case
• Should work in other cases
• After loss, drop at most one layer
• Ensures smooth layer transitions

16
TCP in High-speed Networks
Determining Parameters(Cont.)

• Before Loss Flow1 at K, Flow2 at (K-1)
• After loss four possible cases
• For worst case to happen W1 close to WK1 , W2
  close to WK-1
• Substitute worst case values in constraint on
  decrease behavior

worst case
17
TCP in High-speed Networks
Determining Parameters

• Analysis yields inequality
• Higher the inequality, slower the increase in
  aggressiveness
• We choose
• If layering starts at WT, by substitution,

18
TCP in High-speed Networks
Choice of ?

• Since after loss, at most one layer is dropped,
• By substitution and simplification,
• We choose ? 0.15

19
TCP in High-speed Networks
Other Analyses

• Time to claim bandwidth
• Window corresponding to BDP is at layer K
• .
• For TCP, T(slowstart) (W - WT) RTTs
• (Assuming slowstart ends when window WT)

20
TCP in High-speed Networks
Other Analyses

• Packet recovery time
• Window reduction is by ?
• After loss, increase is atleast by (K-1)
• Thus, time to recover from loss is
  RTTs
• For TCP, it is W/2 RTTs
• Speed up in packet recovery time

21
TCP in High-speed Networks
22
TCP in High-speed Networks
Steady State Throughput BW ND / TD

• where K' is the layer for steady state window

23
TCP in High-speed Networks
Response Curve
24
Where We are ...

• TCP on high-speed links with low multiplexing
• Design, analysis and evaluation of aggressive
  probing mechanism (LTCP)
• Impact of high RTT
• Impact on router buffers and loss rates
  (LTCP-RCS)
• TCP on high-speed links with high multiplexing
• Impact of packet reordering (TCP-DCR)
• Future Work

25
TCP in High-speed Networks
Impact of RTT

• Two-fold dependence on RTT
• Smaller the RTT, faster the growth in window
• Smaller the RTT, faster the aggressiveness
  increases
• Easy to offset this
• Scale K using RTT compensation factor KR
• Thus, increase behavior is W W (KR K) / W
• Decrease behavior is still W ? W

In collaboration with Saurabh Jain
26
TCP in High-speed Networks
Impact of RTT

• Throughput ratio in terms of RTT and KR is
• When KR ? RTT (1/3), TCP-like RTT-unfairness
• When KR ? RTT, linear RTT unfairness (window
  size independent of RTT)

In collaboration with Saurabh Jain
27
TCP in High-speed Networks

• Window Comparison

28
TCP in High-speed Networks
Related Work

• Highspeed TCP Modifies AIMD parameters based on
  different response function (no longer AIMD)
• Scalable TCP Uses MIMD
• FAST Based on Vegas core
• BIC TCP Uses Binary/Additive Increase,
  Multiplicative Decrease
• H-TCP Modifies AIMD parameters based on time
  since last drop (no longer AIMD)

29
TCP in High-speed Networks

• Link Utilization

30
TCP in High-speed Networks

• Dynamic Link Sharing

31
TCP in High-speed Networks

• Effect of Random Loss

32
TCP in High-speed Networks

• Interaction with TCP

33
TCP in High-speed Networks

• RTT Unfairness

34
TCP in High-speed Networks
Summary

• Why LTCP ?
• Current design remains AIMD
• Dynamically changes increase factor
• Simple to understand/implement
• Retains convergence and fairness properties
• RTT unfairness similar to TCP

35
Where We are ...

• TCP on high-speed links with low multiplexing
• Design, analysis and evaluation of aggressive
  probing mechanism (LTCP)
• Impact of high RTT
• Impact on router buffers and loss rates
  (LTCP-RCS)
• TCP on high-speed links with high multiplexing
• Impact of packet reordering (TCP-DCR)
• Future Work

36
TCP in High-speed Networks
Impact on Packet Losses

• Increased aggressiveness increases congestion
  events

Summary of Bottleneck Link Buffer Statistics
37
TCP in High-speed Networks
Impact on Router Buffers

• Increased aggressiveness increases stress on
  router buffers

Instantaneous Queue Length at Bottleneck Link
Buffers
38
TCP in High-speed Networks
Impact on Buffers and Losses
Motivation

• Important to be aggressive for fast convergence
• When link is underutilized
• When new flows join/leave
• In steady state, aggressiveness should be tamed
• Otherwise, self-induced loss rates can be high

39
TCP in High-speed Networks
Impact on Buffers and Losses

• Proposed solution
• In steady state, use less aggressive TCP
  algorithms
• Use a control switch to turn on/off
  aggressiveness
• Switching Logic
• ON when bandwidth is available
• OFF when link is in steady state
• ON when network dynamics change (sudden decrease
  or increase in available bandwidth)

40
TCP in High-speed Networks
Impact on Buffers and Losses
Using the ack-rate for identifying steady state

• Raw ack-rate signal for flow1

41
TCP in High-speed Networks
Impact on Buffers and Losses

• Using ack-rate for switching
• Trend of the ack rate works well for our purpose
• If (gradient 0) Aggressiveness OFFIf
  (gradient ? 0) Aggressiveness ON
• Responsiveness of raw signal does not require
  large buffers
• Noisy raw signal smoothed using EWMA

42
TCP in High-speed Networks
Impact on Buffers and Losses
Instantaneous Queue Length at Bottleneck Link
Buffers
Without Rate-based Control Switch
With Rate-based Control Switch
43
TCP in High-speed Networks
Impact on Buffers and Losses
Summary of Bottleneck Link Buffer Statistics
44
TCP in High-speed Networks
Impact on Buffers and Losses

• Convergence Properties

45
TCP in High-speed Networks
Impact on Buffers and Losses

• Other Results
• TCP Tolerance slightly improved
• RTT Unfairness slightly improved
• At higher number of flows, improvement in loss
  rate is about a factor of 2
• Steady reverse traffic does not impact
  performance
• Highly varying traffic reduces benefits,
  improvement in loss rate is about a factor of 2

46
TCP in High-speed Networks
Impact on Buffers and Losses
Summary

• Use of rate-based control switch
• provides improvement in loss rates ranging from
  orders of magnitude to a factor of 2
• low impact on other benefits of high-speed
  protocols
• Benefits extend to other high-speed protocols
  (verified for BIC and HTCP)
• Whichever high-speed protocol emerges as the next
  standard, rate-based control switch could be
  safely used with it

47
Where We are ...

• TCP on high-speed links with low multiplexing
• Design, analysis and evaluation of aggressive
  probing mechanism (LTCP)
• Impact of high RTT
• Impact on router buffers and loss rates
  (LTCP-RCS)
• TCP on high-speed links with high multiplexing
• Impact of packet reordering (TCP-DCR)
• Future Work

48
TCP with Non-Congestion Events

• TCP behavior If three dupacks
• retransmit the packet
• reduce cwnd by half.
• Caveat Not all 3-dupack events are due to
  congestion
• channel errors in wireless networks
• reordering etc.
• Result Sub-optimal performance

49
Impact of Packet Reordering

• Packet Reordering in the Internet
• Originally thought to be pathological
• caused only by route flapping, router pauses etc
• Later results claim higher prevalence of
  reordering
• reason attributed to parallelism in Internet
  components
• Newer measurements show
• low levels of reordering in most part of Internet
• high levels of reordering is localized to some
  links/sites
• is a function of network load

50
Impact of Packet Reordering

• Proposed Solution
• Delay the time to infer congestion by ?
• Essentially a tradeoff between wrongly inferring
  congestion and promptness of response to
  congestion
• ? chosen to be one RTT to allow maximum time
  while avoiding an RTO

51
Impact of Packet Reordering

• Evaluation conducted for different scenarios
• Networks with only packet reordering, only
  congestion, both
• Evaluation at multiple levels
• Flow level (Throughput, relative fairness,
  response to dynamic changes in traffic etc.)
• Protocol level (Packet delivery time, RTT
  estimates etc.)
• Network level (Bottleneck link droprate, queue
  length etc.)

52
Impact of Packet Reordering
Packet Reordering Only
TCP-DCR maintains high throughput even when
large percentage of packets are delayed
53
Impact of Packet Reordering
Packet Reordering Only
TCP-DCR maintains high throughput when packets
are delayed upto 0.8 RTT
54
Congestion Only (Fairness)
Impact of Packet Reordering
Per-flow throughput TCP-DCR is similar to that of
competing TCP-SACK flows on congested links
55
Impact of Packet Reordering
Congestion and Packet Reordering
TCP-DCR utilizes throughput given up by TCP-SACK
flows TCP-SACK flows are not starved for
bandwidth
56
Impact of Packet Reordering

• Other Results
• RTT Estimation not affected
• Packet delivery time increased only for packets
  recovered via retransmission
• Convergence properties not affected
• Bottleneck queue similar with both Droptail and
  RED
• Bottleneck droprates similar with Droptail and
  RED
• Evaluation on Linux testbed

57
Where We are ...

• TCP on high-speed links with low multiplexing
• Design, analysis and evaluation of aggressive
  probing mechanism
• Impact of high RTT
• Impact on router buffers and loss rates
• TCP on high-speed links with high multiplexing
• Impact of packet reordering
• Future Work

58
Future Work

• Further Evaluation of LTCP / LTCP-RCS
• Further Evaluation of TCP-DCR
• Exploring Congestion Avoidance Techniques

59
Future Work (1)

• Further Evaluation of LTCP / LTCP-RCS
• Impact of delaying congestion response in
  high-speed networks
• Evaluate alternate metrics for aggressiveness
  control
• Investigate different smoothing techniques for
  ackrate signal
• Experimental evaluation on Internet2 testbed
• LTCP
• Rate-based Control Switch
• Extent of reordering

60
Future Work (2)

• Further Evaluation of TCP-DCR
• Exploiting the benefits of robustness to
  reordering
• End-node multi-homing
• Network multi-homing/load balancing with
  packet-level decisions instead of flow-level
  decisions

61
Exploring Congestion Avoidance Techniques
Future Work (3)
Motivation
Yes
No
AggrControl
RCS
LTCP
TCP-SACK
TCP-SACK
Aggressive Algorithm
Non-aggressive Algorithm
62
Exploring Congestion Avoidance Techniques
Future Work (3)

• Focus on the non-aggressive algorithm component
  
• Several options available
• TCP-SACK (Loss)
• CARD (Delay Gradient)
• Tri-S (Throughput Gradient)
• DUAL (Delay)
• TCP-Vegas (Throughput)
• CIM (Delay)

63
Exploring Congestion Avoidance Techniques
Future Work (3)

• Should we use existing options ?
• Rely on changes in RTT for detecting congestion
• Research shows low correlation between RTT and
  packet loss
• High false positives reduce achieved throughput
• False positives may be due to forward or reverse
  traffic changes

64
Exploring Congestion Avoidance Techniques
Future Work (3)

• Improved delay-based metric possible ?
• Two factors effect variations in RTT
• Persistent Congestion
• Transient burstiness in traffic
• Probabilistically determine if RTT increase is
  related to congestion ?
• Modify response to compensate for unreliability
  of signal ?
• Probabilistic response
• Proportional response

65
Exploring Congestion Avoidance Techniques
Future Work (3)

• Compensation for unreliability of signal by
  modifying the response
• Deviate from current philosophy of binary
  response (Respond or NOT Respond)
• Resulting behavior similar to RED
• Response by end points eliminates deployment
  issues

66
Exploring Congestion Avoidance Techniques
Future Work (3)
Topology
67
Exploring Congestion Avoidance Techniques
Future Work (3)
68
Exploring Congestion Avoidance Techniques
Future Work (3)
69
Conclusions

• TCP on high-speed links with low multiplexing
• LTCP
• Retains AIMD, good convergence properties and
  controlled RTT-unfairness
• RCS
• Controls aggressiveness to reduce loss rates, can
  be used with other loss-based high-speed
  protocols
• Future work
• Alternate non-aggressive algorithms
• TCP on high-speed links with high multiplexing
• TCP-DCR
• Simple, yet effective

70
List of Publications

• LTCP / LTCP-RCS
• Sumitha Bhandarkar and A. L. Narasimha Reddy,
  "Rate-based Control of the Aggressiveness of
  Highspeed Protocols, Currently Under Submission.
• Sumitha Bhandarkar, Saurabh Jain and A. L.
  Narasimha Reddy, LTCP Layered Congestion
  Control for Highspeed Networks, Journal Paper,
  Currently Under Submission.
• Sumitha Bhandarkar, Saurabh Jain and A. L.
  Narasimha Reddy, "Improving TCP Performance in
  High Bandwidth High RTT Links Using Layered
  Congestion Control", Proceedings of PFLDNet 2005
  Workshop, February 2005.
• TCP-DCR
• Sumitha Bhandarkar and A. L. Narasimha Reddy,
  "TCP-DCR Making TCP Robust to Non-Congestion
  Events", Proceedings of Networking 2004, May
  2004. Also, presented as student poster at ACM
  SIGCOMM 2003, August 2003.
• Sumitha Bhandarkar, Nauzad Sadry, A. L. Narasimha
  Reddy and Nitin Vaidya, TCP-DCR A Novel
  Protocol for Tolerating Wireless Channel Errors,
  accepted for publication in IEEE Transactions on
  Mobile Computing (Vol. 4, No. 5),
  September/October 2005
• Sumitha Bhandarkar and A. L. Narasimha Reddy,
  "Improving the robustness of TCP to
  Non-Congestion Events", IETF Draft, work in
  progress, May 2005. Status Preparing for WGLC.

71
Thank You Questions ?
72
Supporting Slides
73
Work Related to LTCP

• HS-TCP
• Sally Floyd, HighSpeed TCP for Large Congestion
  Windows, RFC 3649 Dec 2003.
• Scalable TCP
• Tom Kelly, Scalable TCP Improving Performance
  in HighSpeed Wide Area
• Networks, ACM Computer Communications Review,
  April 2003.
• FAST
• Cheng Jin, David X. Wei and Steven H. Low, FAST
  TCP motivation, architecture,
• algorithms, performance, IEEE Infocom, March
  2004.
• BIC
• Lisong Xu, Khaled Harfoush, and Injong Rhee,
  Binary Increase Congestion Control for
• Fast Long-Distance Networks, IEEE Infocom, March
  2004.
• HTCP
• R. N. Shorten, D. J. Leith, J. Foy, and R.
  Kilduff, H-TCP Protocol for high-speed Long
• Distance Networks, PFLDnet 2004, February 2003.

74
Work Related to LTCP-RCS

• TCP-AFRICA
• Ryan King, Richard Baraniuk, Rudolf Riedi,
  TCP-Africa An Adaptive and Fair Rapid
• Increase Rule for Scalable TCP, IEEE Infocom,
  March 2005.

75
Work Related to Reordering
1 V. Paxson, "End-to-end Internet packet
dynamics," IEEE/ACM Transactions on Networking,
7(3)277--292, 1999. 2 Jon C. R. Bennett, Craig
Partridge, and Nicholas Shectman. Packet
reordering is not pathological network behavior,
IEEE/ACM Transactions on Networking, 1999. 3 D.
Loguinov and H. Radha, "End-to-End Internet Video
Traffic Dynamics Statistical Study and
Analysis," IEEE INFOCOM, June 2002. 4 G.
Iannaccone, S. Jaiswal and C. Diot, "Packet
Reordering Inside the Sprint Backbone," Tech.
Report, TR01-ATL-062917, Sprint ATL, Jun.
2001. 5 S. Jaiswal, G. Iannaccone, C. Diot, J.
Kurose and D. Towsley, "Measurement and
Classification of Out-of-sequence Packets in
Tier-1 IP Backbone," INFOCOM 2003 6 Yi Wang,
Guohan Lu, Xing Li, A Study of Internet Packet
Reordering, Proc. ICOIN 2004 350-359. 7
Xiaoming Zhou, Piet Van Mieghem, Reordering of
IP Packets in Internet, Proc. PAM 2004
237-246 8Ladan Gharai, Colin Perkins, Tom
Lehman, Packet Reordering, High Speed Networks
and Transport Protocol Performance, ICCCN 2004
73-78.
76
Work Related to TCP-DCR

• Blanton/Allman
• E. Blanton and M. Allman, On Making TCP More
  Robust to Packet Reordering, ACM
• Computer Communication Review, January 2002
• RR-TCP
• M. Zhang, B. Karp, S. Floyd, and L. Peterson,
  RR-TCP A Reordering-Robust TCP
• with DSACK, ICSI Technical Report TR-02-006,
  Berkeley, CA, July 2002
• TCP-DCR IETF Draft
• http//www.ietf.org/internet-drafts/draft-ietf-tcp
  m-tcp-dcr-05.txt

77
Delay-based Schemes

• CARD
• Raj Jain, "A Delay-Based Approach for Congestion
  Avoidance in Interconnected
• Heterogeneous Computer Networks," ACM CCR vol.
  19, pp. 56-71, Oct 1989.
• Tri-S
• Zheng Wang and Jon Crowcroft, "A New Congestion
  Control Scheme Slow Start and
• Search (Tri-S)," ACM Computer Communication
  Review, vol. 21, pp 32-43, Jan 1991
• DUAL
• Zheng Wang and Jon Crowcroft, "Eliminating
  Periodic Packet Losses in the 4.3-Tahoe
• BSD TCP Congestion Control Algorithm," ACM CCR
  vol. 22, pp. 9--16, Apr. 1992
• TCP-Vegas
• Lawrence S. Brakmo and Sean W. O'Malley, "TCP
  Vegas New Techniques for
• Congestion Detection and Avoidance," in SIGCOMM
  '94.
• CIM
• J. Martin, A. Nilsson, and I. Rhee, Delay-Based
  Congestion Avoidance for TCP,
• IEEE/ACM Transactions on Networking, vol. 11, no.
  3, pp. 356369, June 2003

78
References

• Measurement sites showing TCP predominance
• http//ipmon.sprint.com/packstat/viewresult.php?0
  protobreakdownsj-20.0-040206
• http//www.aarnet.edu.au/network/trafficvolume.htm
  l
• http//www.caida.org/outreach/resources/learn/traf
  ficworkload/tcpudp.xml
• TCP Roadmap
• http//tools.ietf.org/wg/tcpm/draft-ietf-tcpm-tcp-
  roadmap/draft-ietf-tcpm-tcp-roadmap-04.txt

79
Delay-based Schemes Issues
1 Ravi S. Prasad, Manish Jain, Constantinos
Dovrolis, On the Effectiveness of Delay-Based
Congestion Avoidance, PFLDnet 2004 2 S. Biaz
and N. Vaidya, Is the Round-Trip Time Correlated
with the Number of Packets in Flight?, Internet
Measurement Conference (IMC), Oct. 2003 3 J.
Martin, A. Nilsson, and I. Rhee, Delay-Based
Congestion Avoidance for TCP, IEEE/ACM
Transactions on Networking, vol. 11, no. 3, pp.
356369, June 2003. 4 Les Cottrell, Hadrien
Bullot and Richard Hughes-Jones, "Evaluation of
Advanced TCP stacks on Fast Long-Distance
production Networks PFLDNet 2004
80
References

• PHENIX Project
• http//www.phenix.bnl.gov/
• CERN Courier, Vol. 45, No.7
• http//www.cerncourier.com/main/toc/45/7

81
References

• AIMD
• D.-M. Chiu and R. Jain, Analysis of the
  increase and decrease algorithms for congestion
  avoidance in computer networks, Computer
  Networks and ISDN Systems, 17(1)1--14, June
  1989.

82
Response Curve High-speed Protocols
83
Topology

• Dynamic Link Sharing

Flow1 Start
Flow2 Start
Flow3 Start
Flow4 Start
Flow4 Stop
Flow3 Stop
Flow2 Stop
Flow1 Stop
0 300 600 900 1200
1500 1800 2100
Time (Seconds)
84
Topology

• RCS Convergence Properties

?-fair convergence Time for allocation (B,0) ?
Jain Fairness Index
85
References

• ?-fair convergence Deepak Bansal, Hari
  Balakrishnan, Sally Floyd and Scott Shenker,
  Dynamic Behavior of Slowly-Responsive Congestion
  Control Algorithms, ACM SIGCOMM 2001.
• Jain Fairness Index R.Jain, D-M. Chiu and W.
  Hawe. "A Quantitative Measure of Fairness and
  Discrimination For Resource Allocation in Shared
  Conputer Systems," Technical Report TR-301, DEC
  Research Report, September, 1984

86
TCP in High-speed Networks
Impact on Buffers and Losses

• Instantaneous Queue Length at Bottleneck Link
  Buffers
• with Rate-based Control Switch

87
TCP in High-speed Networks
Impact on Buffers and Losses

• Loss Events and Packet Loss Rate with the RCS

88
TCP in High-speed Networks
Impact on Router Buffers and Packet Loss Rates

• Convergence Properties

89
TCP in High-speed Networks
Impact on Buffers and Losses

• Convergence Properties (Cont.)

90
TCP in High-speed Networks
Impact on Buffers and Losses

• Behavior with multiple Flows

91
TCP in High-speed Networks
Impact on Buffers and Losses

• Behavior with multiple Flows

92
TCP in High-speed Networks
Impact on Buffers and Losses

• TCP Tolerance

93
TCP in High-speed Networks
Impact on Buffers and Losses

• TCP Tolerance

94
TCP in High-speed Networks
Impact on Buffers and Losses

• RTT Unfairness

95
TCP in High-speed Networks
Impact on Buffers and Losses

• RTT Unfairness

96
Topology

• RCS Impact of Steady Reverse Traffic

97
TCP in High-speed Networks
Impact on Buffers and Losses

• Impact of Reverse Traffic

98
TCP in High-speed Networks
Impact on Buffers and Losses

• Impact of Reverse Traffic

99
TCP in High-speed Networks
Impact on Buffers and Losses

• Impact of Background Traffic with High Variance

100
TCP in High-speed Networks
Impact on Buffers and Losses

• Impact of Background Traffic with High Variance

101
TCP in High-speed Networks
Impact on Buffers and Losses

• Delay-based Metric for Aggressiveness Control

Buffer Size 1/3 DBP (5000 Packets)
RCS Rate-based Control Switch OFF when
throughput gradient ? 0)DCS Delay-based
Control Switch OFF when (queuing delay
sending rate) gt ? (? 1.65)
102
Exploring Congestion Avoidance Techniques
Future Work (3)
Motivation
103
TCP in High-speed Networks

• Fairness Among Multiple Flows

Jain Fairness Index
104
TCP in High-speed Networks

• Interaction With Non-responsive Traffic

105
TCP in High-speed Networks
Impact on Buffers and Losses
Related Work

• TCP-AFRICA
• Uses delay-based metric for reducing losses in
  HS-TCP
• Requires high resolution timers
• Convergence behavior not examined
• Could potentially increase convergence time
  drastically
• TCP-FAST
• Based on Vegas Core
• Research shows issues that make it less effective
  for practical deployment

106
Congestion Only (Sudden Changes in Traffic)
Impact of Packet Reordering
Time to reach (55,45) allocation TCP-SACK
3.10 sTCP-DCR 3.67 s
Response of TCP-DCR to sudden changes in traffic
is similar to that of TCP-SACK
107
Congestion Only (Effect of Web-like Traffic)
Impact of Packet Reordering
Bulk transfer due to TCP-DCR does not effect
background web-like traffic
108
Congestion Only (Background UDP traffic)
Impact of Packet Reordering
TCP-DCR and TCP-SACK maintain relative fairness
with dynamically changing traffic
109
Congestion Only (Packet Delivery Time)
Impact of Packet Reordering
Time to recover lost packets TCP-SACK
182.7msTCP-DCR 201.3 ms
TCP-DCR has higher packet recovery time for lost
packets. Packet delivery time similar to TCP-SACK
during times of no congestion.
110
Problem Description
TCP with Non-Congestion Events
End-to-End RTT
Retransmission and Window Reduction
7 8 9 2
1 2 3 456
Sender

Receiver
2 2 2 2 2 7 8 9
10 10
Packet Delayed Causing Reordering
111
Proposed Solution
TCP with Non-Congestion Events