networking 2004{sumitha,reddy}@ee.tamu.edu tcp-dcr: making tcp robust to non-congestion events...
TRANSCRIPT
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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.
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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.)
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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.
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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)
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
Throughput Analysis
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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.)
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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%)
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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%)
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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.
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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)
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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.
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
Thank You
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
Extra Slides
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
Choice of (Wireless Scenario)
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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)
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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)
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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.
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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])
Networking 2004{sumitha,reddy}@ee.tamu.edu{sumitha,reddy}@ee.tamu.edu
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)