Improving the Robustness of TCP to Non-Congestion Events

Transcription

1 Improving the Robustness of TCP to Non-Congestion Events Presented by : Sally Floyd floyd@acm.org For the Authors: Sumitha Bhandarkar A. L. Narasimha Reddy {sumitha,reddy}@ee.tamu.edu

2 Problem Statement Proposed Solution Modifications to TCP Choice of t Other details Evaluation Outline Wireless networks with channel errors Wired networks with packet reordering Conclusions 2

3 Problem Statement TCP s behavior: On receipt of three dupacks retransmit the packet and reduce cwnd by half. Caveat : Not all 3-dupack events are due to congestion (Ex: channel errors in wireless networks, reordering etc.) Result : Sub-optimal performance in networks with non-negligible non-congestion events. 3

4 Problem Statement / Proposed Solution End-to-End RTT Congestion Response Delay Timer Sender No Retransmission or Window Reduction Congestion Response Delay Timer Cancelled Receiver Packet Delayed Causing Reordering 4

5 Proposed Solution TCP s 3-dupack mechanism a heuristic Allows mild reordering Time to revisit this heuristic in new networks Proposal: Change this delay to one window (RTT) Allows enough time for underlying mechanisms to recover from non-congestion events. Essentially a tradeoff between wrongly inferring congestion and promptness of response to congestion. 5

6 Proposed Solution (Modifications to TCP) Delay triggering of congestion response algorithms by t during congestion avoidance phase. During the delay t, send one new packet for every dupack (similar to limited transmit algorithm) If cumulative acknowledgment received before the delay timer t expires, cancel congestion response Else, trigger fast retransmit/recovery. 6

7 Proposed Solution (Choice of t) Should be large enough to recover from noncongestion 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) 7

8 Proposed Solution (Other Details) t can be implemented based on a timer or by changing the dupthresh. 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 During the delay t the sender is ack-clocked, uses limited transmit 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 8

9 Wireless Channel Errors -- Topology Explanation for next slide (To be removed from final version) Sender Router Base Station Receiver 100 Mb, 5ms 100 Mb, 5ms 1 Mb, 20ms 9

10 Wireless Channel Errors Throughput (Mbps) Throughput Vs Channel Error Rate TCP-SACK TCP-DCR Channel Error Rate (%) 10

11 Wireless Channel Errors (cont.) TCP-SACK reduces sending rate for channel errors Result : Degraded performance as channel error rate increases Other concerns : When available wireless bandwidth is large, TCP-SACK cannot utilize it well When wireless delay is large, it takes larger time to recover from window reduction fi degradation in performance more drastic 11

12 Packet Reordering -- Topology Explanation for next slide (To be removed from final version) Sender Router 1 Router 2 Receiver 10 Mb, 1ms 8 Mb, 50ms 10 Mb, 1ms 12

13 Packet Reordering 1 Throughput Vs Percentage of Packets Delayed Throughput (Mbps) TCP-SACK TCP-DCR Percentage of Packets Delayed 13

14 Packet Reordering (cont.) TCP-SACK wrongly infers delayed packet as congestion Result : Degraded performance in networks with non-negligible packet reordering Other concerns : Requirement of near in-order delivery imposes limitations on new routing schemes. 14

15 Congestion Only -- Fairness (Topology) Explanation for next slide (To be removed from final version) Sender 1 Receiver 1 TCP-SACK Flows Sender Mb, 5ms Sender 13 Router 10 Mb, 5ms Base Station TCP-SACK Flows Receiver 12 1 Mb, 20ms Receiver 13 TCP-DCR Flows TCP-DCR Flows Receiver 24 Sender 24 15

16 Congestion Only -- Fairness 0.5 Throughput Vs Bottleneck Link Congestion Drop Rate 0.4 Average per-flow Throughput (Mbps) TCP-SACK TCP-DCR Bottleneck Link Congestion Drop Rate (%) 16

17 Congestion Only -- Fairness (cont.) During the delay period TCP-DCR is still ackclocked Limited Transmit is used during the delay period Overall protocol behavior is still AIMD fi Overall performance of TCP-DCR similar to competing TCP-SACK flows for different congestion rates 17

18 Congestion Only -- Sudden Changes in Traffic Explanation for next slide (To be removed from final version) Sender 1 Receiver 1 Flow being evaluated Sender 12 Sender Mb, 5ms Router 10 Mb, 5ms Base Station Flow being evaluated Receiver 12 1 Mb, 20ms Receiver 13 TCP-SACK traffic Sender 24 TCP-SACK traffic Receiver 24 18

19 Congestion Only -- Sudden Changes in Traffic Response of TCP-SACK to Sudden Changes in Network Traffic 12 Aggregate Throughput (Mbps) (in 1 sec bins) TCP-SACK Traffic Response of TCP-DCR to Sudden Changes in Network Traffic Time (Seconds) 12 Aggregate Throughput (Mbps) (in 1 sec bins) TCP-DCR Traffic Time (Seconds) 19

20 Congestion Only -- Sudden Changes in Traffic (cont.) TCP-DCR relinquishes and reclaims bandwidth in similar fashion to TCP-SACK 20

21 Channel Errors and Congestion -- Topology (To be removed from final version) Same as Congestion Only -- Fairness 21

22 Channel Errors and Congestion 0.7 Throughput Vs Channel Error Rate with Congestion in the Network Average Per-flow Throughput (Mbps) TCP-SACK (Low Congestion) TCP-SACK (Moderate Congestion) TCP-SACK (High Congestion) TCP-DCR (Low Congestion) TCP-DCR (Moderate Congestion) TCP-DCR (High Congestion) Channel Error Rate (%) 22

23 Channel Errors and Congestion (cont.) For both TCP-SACK and TCP-DCR, T µ 1/p In case of TCP-SACK, p = (congestion loss rate + channel error rate) In case of TCP-DCR, p = congestion loss rate For lower congestion rate, competing TCP-DCR flows get better throughput As congestion increases, difference in throughput between TCP-DCR and TCP-SACK flows decreases 23

24 Conclusions Significant performance improvement with noncongestion events Similar to unmodified versions of TCP in the absence of non-congestion events Simple to implement Linux implementation - less than 10 lines of code changed Unified solution, handling multiple issues 24

25 For Further Details. TCP-DCR: Making TCP Robust to Non- Congestion Losses TCP-DCR: A Novel Protocol for Tolerating Wireless Channel Errors 25