congestion control algorithms of tcp in emerging networks

1Texas A&M University

Congestion Control Algorithms of TCPin Emerging Networks

Sumitha Bhandarkar Under the Guidance of Dr. A. L. Narasimha Reddy

September 16, 2005


Why TCP Congestion Control ?

• Designed in early ’80’s– 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

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

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)

Motivation


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






• Future Work

Where We are ...


TCP in High-speed Networks

TCP’s one per RTT increase does not scale well

* For RTT = 100ms, Packet Size = 1500 Byte

Motivation

*Source : RFC 3649


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



• 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



• Layering– Start layering when window > 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.

LTCP Concepts (Cont.)



K

K + 1

K

K - 1

LayerNumber

WK-1

Minimum Window Corresponding to the layer

Number of layers = K when WK W WK+1

WK

WK+1

LTCP Concepts



Constraint 1 :

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

Framework


K + 2

K

K - 1 WK-1

Number of layers = K when WK W WK+1

WK

WK+2

K + 1

WK+1

(K1 > K2, for all K1, K2 2)


Constraint 2 :

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

Framework


(K1 > K2, for all K1, K2 2)

Flow 1 :

Flow 2 :

Window WR1

Slope = K1'

T1

Time

Window WR2

Slope = K2'

T2

Time


• Decrease behavior : – Multiplicative decrease

• Increase behavior :– Additive increase with additive factor = layer

number

W = W + K/W

Design Choice



• 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

Determining Parameters



– Before Loss : Flow1 at K, Flow2 at (K-1)– After loss four possible cases

– For worst case to happen W1 close to WK+1 , W2 close to WK-1

– Substitute worst case values in constraint on decrease behavior

Determining Parameters(Cont.)


worst case


– Analysis yields inequality

• Higher the inequality, slower the increase in aggressiveness

– We choose

– If layering starts at WT, by substitution,

Determining Parameters



Since after loss, at most one layer is dropped,

By substitution and simplification,

We choose = 0.15

Choice of




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)



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


where K' is the layer for steady state window

Steady State Throughput

BW = ND / TD



Response Curve


1.00E+00

1.00E+01

1.00E+02

1.00E+03

1.00E+04

1.00E+05

1.00E+06

1.00E-08

1.00E-07

1.00E-06

1.00E-05

1.00E-04

1.00E-03

1.00E-02

Loss Rate (p)

Win

do

w (

Pa

cke

ts/R

TT

)

TCP

LTCP






• Future Work

Where We are ...


• 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

Impact of RTT*


* In collaboration with Saurabh Jain


– 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)

Impact of RTT*


* In collaboration with Saurabh Jain


Window Comparison




– 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)

Related Work


Link Utilization



Dynamic Link Sharing



Effect of Random Loss



Interaction with TCP



RTT Unfairness



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

Summary







• Future Work

Where We are ...


Increased aggressiveness increases congestion events

Summary of Bottleneck Link Buffer Statistics


Impact on Packet Losses


Increased aggressiveness increases stress on router buffers


Instantaneous Queue Length at Bottleneck Link Buffers

Impact on Router Buffers


• 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


Impact on Buffers and Losses

Motivation

0

200

400

600

800

1000

1200

0 500 1000 1500

Time (Seconds)

Lin

k U

tiliza

tio

n (

Mb

ps)

(5-s

eco

nd

Ave

rag

e)

flow1

flow2


• 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)




Using the ack-rate for identifying steady stateRaw ack-rate signal for flow1




• 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





Without Rate-based Control Switch With Rate-based Control Switch




Summary of Bottleneck Link Buffer Statistics




Convergence Properties




• 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




• 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

Summary








• Future Work

Where We are ...


• 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

TCP with Non-Congestion Events


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


• 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



• 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.)



TCP-DCR maintains high throughput even when large percentage of packets are delayed

Throughput Vs Percentage of Delayed Packets (Normally Distributed Packet Delay, mean 25ms, stddev 8ms)

0

1

2

3

4

5

6

7

8

0 5 10 15 20 25 30 35

Percentage of Packets Delayed

Th

rou

gh

pu

t (M

bp

s)

TCP-SACK

TCP-DCR

Packet Reordering Only



TCP-DCR maintains high throughput when packets are delayed upto 0.8 * RTT

Packet Reordering OnlyThroughput Vs Packet Delay

2% of Packets Delayed

0

1

2

3

4

5

6

7

8

0 0.2 0.4 0.6 0.8 1 1.2 1.4

Packet Delay (Fraction of RTT)

Th

rou

gh

pu

t (M

bp

s) TCP-SACK

TCP-DCR



Congestion Only (Fairness)

Per-flow throughput TCP-DCR is similar to that of competing TCP-SACK flows on congested links

Throughput Vs Link Droprate due to Congestion

0

0.1

0.2

0.3

0.40.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7

Link Droprate due to Congestion

Th

rou

gh

pu

t (M

bp

s)

TCP-SACK

TCP-DCR



TCP-DCR utilizes throughput given up by TCP-SACK flows TCP-SACK flows are not starved for bandwidth

Congestion and Packet ReorderingThroughput Vs Percentage of Delayed Packets

(Normally Distributed Packet Delay, mean 25ms, stddev 8ms)Congestion Droprate : 0.2 to 2%

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0 5 10 15 20 25 30 35

Percentage of Packets Delayed

Th

rou

gh

pu

t (M

bp

s)

TCP-Sack

TCP-Dcr



• 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




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

Where We are ...


Future Work

• Further Evaluation of LTCP / LTCP-RCS

• Further Evaluation of TCP-DCR

• Exploring Congestion Avoidance Techniques


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


• 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

Future Work (2)


Exploring Congestion Avoidance Techniques

Future Work (3)

AggressiveAlgorithm

Non-aggressiveAlgorithm

AggrControl

Yes No

LTCP TCP-SACK

RCS

Motivation

TCP-SACK


• 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)


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


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


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


Future Work (3)



Future Work (3)

Topology



Future Work (3)

00.10.20.30.40.50.60.70.80.9

11.1

0.06 0.08 0.1 0.12 0.14RTT (seconds)

Cum

ulat

ive

Pro

babi

lity

Case 1

Case 2

Case 3

Case 4

Case 5



Future Work (3)


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


• 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.

List of Publications


Thank You

Questions ?


Supporting Slides


• HS-TCPSally Floyd, “HighSpeed TCP for Large Congestion Windows”, RFC 3649 Dec 2003.

• Scalable TCPTom Kelly, “Scalable TCP: Improving Performance in HighSpeed Wide AreaNetworks”, ACM Computer Communications Review, April 2003.

• FASTCheng Jin, David X. Wei and Steven H. Low, “FAST TCP: motivation, architecture,algorithms, performance”, IEEE Infocom, March 2004.

• BICLisong Xu, Khaled Harfoush, and Injong Rhee, “Binary Increase Congestion Control forFast Long-Distance Networks”, IEEE Infocom, March 2004.

• HTCPR. N. Shorten, D. J. Leith, J. Foy, and R. Kilduff, “H-TCP Protocol for high-speed LongDistance Networks”, PFLDnet 2004, February 2003.

Work Related to LTCP


Work Related to LTCP-RCS

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


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

[8]Ladan Gharai, Colin Perkins, Tom Lehman, “Packet Reordering, High Speed Networks and Transport Protocol Performance,” ICCCN 2004: 73-78.


Work Related to TCP-DCR

• Blanton/AllmanE. Blanton and M. Allman, “On Making TCP More Robust to Packet Reordering,” ACMComputer Communication Review, January 2002

• RR-TCPM. 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 Drafthttp://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-05.txt


• CARDRaj Jain, "A Delay-Based Approach for Congestion Avoidance in Interconnected Heterogeneous Computer Networks," ACM CCR vol. 19, pp. 56-71, Oct 1989.

• Tri-SZheng 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-VegasLawrence S. Brakmo and Sean W. O'Malley, "TCP Vegas: New Techniques forCongestion Detection and Avoidance," in SIGCOMM '94.

• CIMJ. Martin, A. Nilsson, and I. Rhee, “Delay-Based Congestion Avoidance for TCP,” IEEE/ACM Transactions on Networking, vol. 11, no. 3, pp. 356–369, June 2003

Delay-based Schemes


References

• Measurement sites showing TCP predominancehttp://ipmon.sprint.com/packstat/viewresult.php?0:protobreakdown:sj-20.0-040206:

http://www.aarnet.edu.au/network/trafficvolume.html

http://www.caida.org/outreach/resources/learn/trafficworkload/tcpudp.xml

• TCP Roadmaphttp://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-tcp-roadmap/draft-ietf-tcpm-tcp-roadmap-04.txt


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. 356–369, June 2003.

[4] Les Cottrell, Hadrien Bullot and Richard Hughes-Jones, "Evaluation of Advanced TCP stacks on Fast Long-Distance production Networks” PFLDNet 2004


References

• PHENIX Projecthttp://www.phenix.bnl.gov/

• CERN Courier, Vol. 45, No.7http://www.cerncourier.com/main/toc/45/7


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.


Response Curve High-speed Protocols


Topology

Dynamic Link Sharing

Time (Seconds)0 300 600 900 1200 1500 1800 2100

Flow1 Start

Flow2 Start

Flow3 Start

Flow4 Start

Flow4 Stop

Flow3 Stop

Flow2 Stop

Flow1 Stop

1Gbps, 40ms

2.4Gbps, 10ms

2.4Gbps, 10ms


Topology

RCS : Convergence Properties

0

200

400

600

800

1000

1200

0 200 400 600 800 1000 1200 1400

Time (Seconds)

Lin

k U

tilizati

on

(M

bp

s)

(5-s

eco

nd

Avera

ge)

flow1

flow2

Region 1 Region 2 Region 3

-fair convergence :

Time for allocation (B,0)

Jain Fairness Index :


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



with Rate-based Control Switch




Loss Events and Packet Loss Rate with the RCS




Impact on Router Buffers and Packet Loss Rates


Convergence Properties


Convergence Properties (Cont.)




Behavior with multiple Flows



1E-07

1E-06

1E-05

1E-04

1E-03

0 5 10 15Number of Flows

Pa

cke

t L

oss R

ate

LTCP (1BDP)

LTCP-RCS (1BDP)

LTCP (1/3 BDP)

LTCP-RCS (1/3 BDP)


Behavior with multiple Flows




TCP Tolerance




RTT Unfairness




Topology

RCS : Impact of Steady Reverse Traffic

1Gbps, 40ms2.4Gbps,

10ms

2.4Gbps, 10ms

High-speed Flow

UDP Flow

Time (Seconds)0 200 400 600 800 1000

100755025

Link Util by UDP Flow


Impact of Reverse Traffic




Impact of Background Traffic with High Variance



100

Texas A&M University

Impact of Background Traffic with High Variance



101


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) >

( = 1.65)

102



Future Work (3)

Motivation

103


Fairness Among Multiple Flows


Jain Fairness Index :

104


Interaction With Non-responsive Traffic


105




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)

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

Response of TCP-SACK to Sudden Change in Traffic

0

2

4

6

8

10

12

0 50 100 150 200Time (seconds)

Th

rou

gh

pu

t (M

bp

s)(1

sec

on

d b

ins)

TCP-SACK

FTP Traffic

Response of TCP-DCR to Sudden Change in Traffic

0

2

4

6

8

10

12

0 50 100 150 200Time (seconds

Th

rou

gh

pu

t (M

bp

s)

(1 s

eco

nd

bin

s)TCP-DCR

FTP Traffic


107


Congestion Only (Effect of Web-like Traffic)Interaction of TCP-SACK with Web-like Traffic

0

2

4

6

8

10

0 50 100 150 200Time (Seconds)

Th

rou

gh

pu

t (M

bp

s)(in

1 s

ec b

ins)

TCP-SACK

Traffic

Interaction of TCP-DCR with Web-like Traffic

0

2

4

6

8

10

0 50 100 150 200

Time (Seconds)

Th

rou

gh

pu

t (M

bp

s)(in

1 s

ec b

ins)

TCP-DCR

Traffic

TCP-SACK TCP-DCRAggregate

Throughput4.76 Mbps 4.73 Mbps

Throughput ofWeb-Traffic

4.84 Mbps 4.82 Mbps

Bulk transfer due to TCP-DCR does not effect background web-

like traffic


108


Congestion Only (Background UDP traffic)Response to UDP Traffic

0

1

2

3

4

5

6

7

0 25 50 75 100 125 150 175 200Time (seconds)

Th

rou

gh

pu

t (M

bp

s)

(1

se

co

nd

bin

s)

TCP-SACK

TCP-DCR

UDP

TCP-DCR and TCP-SACK maintain relative fairness with dynamically changing traffic


109


Congestion Only (Packet Delivery Time)Packet Delivery Time for TCP-SACK

0

0.05

0.1

0.15

0.2

0.25

0.3

0 5000 10000 15000Packet Sequence Number

Pac

ket d

eliv

ery

Tim

e (s

eco

nd

s)

Packet Delivery Time for TCP-DCR

0

0.05

0.1

0.15

0.2

0.25

0.3

0 5000 10000 15000Packet Sequence Number

Pac

ket d

eliv

ery

Tim

e (s

eco

nd

s)

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

End-to-End RTT

Receiver

Packet Delayed Causing Reordering

Sender

…

Retransmission andWindow Reduction

7 8 9 2 1 2 3 456

2 2 2 2 2 7 8 9 10 10


111


Congestion Response Delay Timer Cancelled

Congestion Response Delay TimerEnd-to-End RTT

Receiver

Packet Delayed Causing Reordering

Sender

…

No Retransmission or Window Reduction

7 8 9 10 11

1 2 3 456

2 2 2 2 2 7 8 9 10 11 12

Proposed Solution


congestion control algorithms of tcp in emerging networks

Documents