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

2. Networking 2004{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

3. Networking 2004{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

4. Networking 2004{sumitha,reddy}@ee.tamu.edu Problem Description (Cont.) End-to-End RTT Receiver Packet Delayed Causing Reordering Sender … Retransmission and Window Reduction 7 8 9 2 1 2 3 456 2 2 2 2 2 7 8 9 10 10

5. Networking 2004{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.

6. Networking 2004{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

7. Networking 2004{sumitha,reddy}@ee.tamu.edu Congestion Response Delay Timer Cancelled Congestion Response Delay Timer End-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.)

8. Networking 2004{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.

9. Networking 2004{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)

10. Networking 2004{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

11. Networking 2004{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

12. Networking 2004{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

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

14. Networking 2004{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

15. Networking 2004{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.)

16. Networking 2004{sumitha,reddy}@ee.tamu.edu Packet Reordering TCP-DCR maintains high throughput even when large percentage of packets are delayed

17. Networking 2004{sumitha,reddy}@ee.tamu.edu Wireless Channel Errors TCP-DCR maintains high throughput even at high channel error rates

18. Networking 2004{sumitha,reddy}@ee.tamu.edu Wireless Bandwidth TCP-DCR scales better than TCP-SACK when available link capacity increases

19. Networking 2004{sumitha,reddy}@ee.tamu.edu Wireless Delay TCP-DCR maintains high throughput in networks with large wireless delays

20. Networking 2004{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

21. Networking 2004{sumitha,reddy}@ee.tamu.edu 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

22. Networking 2004{sumitha,reddy}@ee.tamu.edu Congestion Only Effect of Web-like Traffic Bulk transfer due to TCP-DCR does not effect background web- like traffic

23. Networking 2004{sumitha,reddy}@ee.tamu.edu Congestion Only Background UDP traffic TCP-DCR and TCP-SACK maintain relative fairness with dynamically changing traffic

24. Networking 2004{sumitha,reddy}@ee.tamu.edu Congestion Only Packet Delivery Time Time to recover lost packets : TCP-SACK : 182.7ms TCP-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.

25. Networking 2004{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.

26. Networking 2004{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.

27. Networking 2004{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

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

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

30. Networking 2004{sumitha,reddy}@ee.tamu.edu Choice of  (Wireless Scenario)

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

32. Networking 2004{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 TCP-SACK traffic Congestion Only Sudden Changes (Topology)

33. Networking 2004{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.

34. Networking 2004{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])

35. Networking 2004{sumitha,reddy}@ee.tamu.edu Related Work References [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)