Networking 2004{sumitha,reddy}@ee.tamu.edu TCP-DCR: Making TCP Robust to Non-Congestion Events Sumitha Bhandarkar A. L. Narasimha Reddy {sumitha,reddy}@ee.tamu.edu

Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu

TCP-DCR: Making TCP Robust to Non-Congestion Events

Sumitha Bhandarkar

A. L. Narasimha Reddy

{sumitha,reddy}@ee.tamu.edu


Outline

• Problem Description

• Proposed Solution

– Modifications to TCP

– Bandwidth Analysis

– Other details

• Evaluation

– Wireless networks with channel errors

– Wired networks with packet reordering

– Networks with no non-congestion events

• Conclusions


Problem Description

• TCP behavior: On receipt of three dupacks retransmit the packet and 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 in networks with non-negligible non-congestion events.

• Time to revisit the heuristic 3-dupack mechanism


Problem Description (Cont.)

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


Problem Description (Cont.)

• Satellite links with large delays adversely affected by window reduction

• Strict limit on amount of reordering constrains research in

– Multipath routing

– Parallelism in packet switching

– Differentiated Services

• We provide a simple unified solution for treating all types of non-congestion events.


Proposed Solution

• Delay the time to infer congestion by

• Allows local recovery mechanisms to recover from non-congestion events if possible

• Essentially a tradeoff between wrongly inferring congestion and promptness of response to congestion


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 (Cont.)


Proposed Solution (Cont.)

• Delay triggering of congestion response algorithms by during congestion avoidance phase.

• During the delay , send one new packet for every dupack (similar to limited transmit algorithm)

• If cumulative acknowledgment received before the delay timer expires, cancel congestion response

• Else, trigger fast retransmit/recovery.


Choice of

• Should be large enough to recover from non-congestion event.

– For the wireless network, should be atleast equal to the round trip time of the wireless portion of the network.

– For the case of reordering, no fixed lower bound.

• Should be small enough to avoid expensive RTO

• Suggested value : one RTT (end-to-end)


Other Details

• Implementation of can be

– timer based

– by changing the threshold on the number of dupacks to be received

• During times of congestion, the required buffer size at receiver is twice that of unmodified TCP

– availability of buffer space ensures maximum benefit

– lack of buffers causes no harm due to TCP flow control algorithm


Other Details (Cont.)

• During the delay , the sender is ack-clocked.

• Only one packet is sent in response to the receipt of a dupack

• This ensures

– during non-congestion events, packets continue to be sent

– during congestion, sending rate is at best the same as when the first dupack was received


Other Details (Cont.)

• Recovery from non-congestion events delegated to local recovery schemes

– For recovering from wireless channel errors, simple link level retransmission scheme or FEC can be used

– For recovery from packet reordering, nothing explicit needs to be done


Throughput Analysis


Throughput Analysis

• Assumptions

– mostly congestion avoidance during steady state

– window displays the classical saw tooth behavior

– Fixed, deterministic loss probability p

• Result 1

Throughput p

• p denotes losses due to congestion only


Simulation Results

• Evaluation conducted for three different scenarios– Networks with packet reordering– Wireless networks with channel errors– Networks with zero non-congestion events

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


Packet Reordering

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


Wireless Channel Errors

TCP-DCR maintains high throughput even at high channel error rates

Throughput Vs Channel Error Rate

0

0.2

0.4

0.6

0.8

1

1.2

0 1 2 3 4 5 6 7 8 9

Channel Error Rate (%)

Th

rou

gh

pu

t (M

bp

s)

TCP-SACK

TCP-DCR


Wireless Bandwidth

TCP-DCR scales better than TCP-SACK when available link capacity increases

Throughput Vs Wireless Bandwidth

0

2

4

6

8

10

12

0 1 2 3 4 5 6 7 8 9 10 11Wireless Bandwidth (Mbps)

Th

rou

gh

pu

t (M

bp

s)

TCP-SACK (Channel Error Rate = 0.5%)TCP-SACK (Channel Error Rate = 3.0%)TCP-SACK (Channel Error Rate = 8.0%)TCP-DCR (Channel Error Rate = 0.5%)TCP-DCR (Channel Error Rate = 3.0%)TCP-DCR (Channel Error Rate = 8.0%)


Wireless Delay

TCP-DCR maintains high throughput in networks with large wireless delays

Throughput Vs Wireless Delay

0

0.2

0.4

0.6

0.8

1

1.2

0 50 100 150 200 250Wireless Delay (ms)

Th

rou

gh

pu

t (M

bp

s)

TCP-SACK (Channel Error Rate = 0.5%)TCP-SACK (Channel Error Rate = 3.0%)TCP-SACK (Channel Error Rate = 8.0%)TCP-DCR (Channel Error Rate = 0.5%)TCP-DCR (Channel Error Rate = 3.0%)TCP-DCR (Channel Error Rate = 8.0%)


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


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


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


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


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.


Channel Errors and Congestion

In the presence of both congestion and non-congestion events, TCP-DCR improves performance as the influence of non-congestion events increases.

Throughput Vs Channel Error Rate with Congestion in the Network

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0 1 2 3 4 5 6 7 8 9Channel Error Rate (%)

Av

g P

er-

flo

w T

hro

ug

hp

ut

(Mb

ps

)

TCP-SACK (Low Congestion)TCP-SACK (Moderate Congestion)TCP-SACK (High Congestion)TCP-DCR (Low Congestion)TCP-DCR (Moderate Congestion)TCP-DCR (High Congestion)


Other Results

• RTT Estimation not affected.

• Bottleneck queue length with TCP-DCR flows similar to that with TCP-SACK flows with both Droptail and RED queues

• Bottleneck droprates with TCP-DCR flows similar to that with TCP-SACK flows with both Droptail and RED queues

• Preliminary results based on Linux implementation look good. Further evaluation being conducted.


Conclusions

• Unified solution for handling multiple issues

• Simple to implement

• Significant performance improvement with non-congestion events

• Similar to unmodified versions of TCP in the absence of non-congestion events


Thank You


Extra Slides


Choice of (Wireless Scenario)


100 Mb, 5ms

Sender 1

Router Base Station

Receiver 1

10 Mb, 5ms

1 Mb, 20ms

Receiver 24

Sender 12

Sender 13

Sender 24

TCP-DCR Flows

Receiver 12

Receiver 13

TCP-SACK Flows TCP-SACK Flows

TCP-DCR Flows

Congestion Only Fairness (Topology)


Sender 1

Router Base Station

Receiver 1

100 Mb, 5ms

10 Mb, 5ms

1 Mb, 20ms

Receiver 24

Sender 12

Sender 13

Sender 24

TCP-SACK traffic

Receiver 12

Receiver 13

Flow being evaluated

Flow being evaluated

TCP-SACK traffic

Congestion OnlySudden Changes (Topology)


Related Work (Packet Reordering)

• Focus on identifying false fast retransmit and undoing window reduction

• False fast retransmit identified using DSACK or timestamp

• Try to gauge the exact amount of reordering within the network to provide reordering robustness

• [1] and [2] are examples of previous work in this area.


Related Work (Wireless Networks)

• Solutions can be categorized as

– Split connection approaches (e.g. [3])

– TCP-aware link layer protocols (e.g. [4])

– Explicit loss notification approaches (e.g. [5])

– Receiver-based approaches (e.g. [6])

– Modifications to TCP (e.g. [7])


Related WorkReferences

[1] E. Blanton and M. Allman, “On Making TCP More Robust to Packet Reordering,” ACM Computer Communication Review, January 2002.

[2] 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.

[3] K. Brown and S. Singh, “M-TCP: TCP for mobile cellular networks,” ACM Computer Communications Review, vol. 27, no. 5, 1997.

[4] H. Balakrishnan, S. Seshan, E. Amir and R. Katz, “Improving TCP/IP performance over wireless networks,” Proc. Of ACM MOBICOM, Nov. 1995.

[5] H. Balakrishnan and R. H. Katz, “Explicit Loss Notification and Wireless Web Performance,” Proc. of IEEE GLOBECOM, Nov. 1998.

[6] N. H. Vaidya, M. Mehta, C. Perkins and G. Montenegro, “Delayed Duplicate Acknowledgement: a TCP-unaware Approach to Improve Performance of TCP over Wireless,” Journal of Wireless communications and Mobile Computing, special issue on Reliable Transport Protocols for Mobile Computing, February 2002.

[7] S. Mascolo, C. Casetti, M. Gerla, M. Sanadidi and R. Wang, “TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links ,” Proceedings of ACM MOBICOM, 2001.

(See paper for other references)

Documents

Networking 2004{sumitha,reddy}@ee.tamu.edu TCP-DCR: Making TCP Robust to Non-Congestion Events Sumitha Bhandarkar A. L. Narasimha Reddy {sumitha,reddy}@ee.tamu.edu