Networking TCP-DCR: Making TCP Robust to Non-Congestion Events Sumitha Bhandarkar A. L. Narasimha Reddy

Networking 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 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 Problem Description (Cont.) End-to-End RTT Receiver Packet Delayed Causing Reordering Sender … Retransmission and Window Reduction

Networking 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 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 Congestion Response Delay Timer Cancelled Congestion Response Delay Timer End-to-End RTT Receiver Packet Delayed Causing Reordering Sender … No Retransmission or Window Reduction Proposed Solution (Cont.)

Networking 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 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 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 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 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 Throughput Analysis

Networking 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 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 Packet Reordering TCP-DCR maintains high throughput even when large percentage of packets are delayed

Networking Wireless Channel Errors TCP-DCR maintains high throughput even at high channel error rates

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

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

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

Networking Congestion Only Sudden Changes in Traffic Time to reach (55%,45%) allocation : TCP-SACK : 3.10 s TCP-DCR : 3.67 s Response of TCP-DCR to sudden changes in traffic is similar to that of TCP-SACK

Networking Congestion Only Effect of Web-like Traffic Bulk transfer due to TCP-DCR does not effect background web- like traffic

Networking Congestion Only Background UDP traffic TCP-DCR and TCP-SACK maintain relative fairness with dynamically changing traffic

Networking Congestion Only Packet Delivery Time Time to recover lost packets : TCP-SACK : 182.7ms TCP-DCR : ms TCP-DCR has higher packet recovery time for lost packets. Packet delivery time similar to TCP-SACK during times of no congestion.

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

Networking 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 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 Thank You

Networking Extra Slides

Networking Choice of  (Wireless Scenario)

Networking 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-DCR Flows Congestion Only Fairness (Topology)

Networking Sender 1 Router Base Station Receiver 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 TCP-SACK traffic Congestion Only Sudden Changes (Topology)

Networking 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 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 Related Work References [1] E. Blanton and M. Allman, “On Making TCP More Robust to Packet Reordering,” ACM Computer Communication Review, January [2] M. Zhang, B. Karp, S. Floyd, and L. Peterson, “RR-TCP: A Reordering-Robust TCP with DSACK,” ICSI Technical Report TR , Berkeley, CA, July [3] K. Brown and S. Singh, “M-TCP: TCP for mobile cellular networks,” ACM Computer Communications Review, vol. 27, no. 5, [4] H. Balakrishnan, S. Seshan, E. Amir and R. Katz, “Improving TCP/IP performance over wireless networks,” Proc. Of ACM MOBICOM, Nov [5] H. Balakrishnan and R. H. Katz, “Explicit Loss Notification and Wireless Web Performance,” Proc. of IEEE GLOBECOM, Nov [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 [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, (See paper for other references)