Wireless TCP

1. Wireless TCP

2. References • Hari Balakrishnan, Venkat Padmanabhan, Srinivasan Seshan and Randy H. Katz, " A Comparison of Mechanisms for Improving TCP Performance over Wireless Links , " IEEE/ACM Transactions on Networking, December 1997.

3. application: supporting network applications FTP, SMTP, STTP transport: host-host data transfer TCP, UDP network: routing of datagrams from source to destination IP, routing protocols link: data transfer between neighboring network elements PPP, Ethernet physical: bits “on the wire” application transport network link physical Network protocol stack

4. Problem • TCP layered on top of IP • IP interface provided to TCP is independent of physical layer • Implementation dependent on physical layer • Wireless just another physical Layer • Problem?

5. Tuning problem • Working correctly not an issue • Working efficiently is more of a problem • On wire links losses (normally) due to congestion • On wireless losses can be due to • Unreliable physical medium • Intermittent connectivity • Handoff losses • Can be reduced • With old base station buffering messages • With adjacent base stations joining a multicast group and buffering messages • Reduces delay • TCP/IP policies for wired links will mistake wireless losses and delays for router congestion

6. Traditional TCP Loss Detection • Timeout • average round trip time + 4*mean deviation • Duplicate acks from receiver • Ack indicates cumulative sequence number of next expected message • If message mi gets lost then acks of subsequent messages will have sequence # i

7. TCP/IP Response to Losses • Assume losses due to congestion • Drops transmission window size • Window size determines how many packets can be sent before waiting for ack • TCP Tahoe: Reduces window size to one • TCP Reno: Reduces window size by half • Both use slow start up (increase window size linearly) when window sizes are to be increased. • If losses due to unreliable physical layer then there may be a needless reduction of throughput

8. TCP/IP Response to Losses • TCP’s response to losses results in a reduction in the load on intermediate links. • In networks with wireless networks, not all loss is due to congestion. • Communication over wireless links are often characterized by sporadic high bit-error rates and intermittent connectivity due to handoffs. • There are suggested TCP enhancements (described on the next two slides).

9. Selective Acknowledgement • Selective acknowledgements (SACKs) were added as an option to TCP. • Each acknowledgement should contain information about up to 3 non-contiguous blocks of data that have been received successfully by the receiver. • Each block of data is described by its starting and ending sequence number.

10. SMART • Use acknowledgements that contain the cumulative acknowledgement and the sequence number of the packet that caused the receiver to generate the acknowledgement. • This implicitly acknowledges the packet that caused the most recent acknowledgement.

11. What is Needed? • Distinguish between congestion and other losses • Do not reduce window in response to non- congestion losses

12. Issues • Where in the path from sender to receiver to solve problem? • How to distinguish between the two reasons for losses?

13. Issues

14. Possible Adaptations • Where in the path from sender to receiver to solve problem? • End-to-end • Sender and receiver together addresses problem • They address congestion loss • They should also address medium loss • Link layer addresses problem • Problem occurred in the link and thus should be solved there. • Split connection • One TCP connection from wired end to base, another from base to wireless end • Problem solved locally • But solved at TCP layer (more semantics)

15. E2E: Explicit Loss Notification (ELN) • This is an end-to-end approach • Adds an Explicit Loss Notification (ELN) option to TCP acknowledgements. • Upon receiving this information with duplicate acknowledgements, the sender may perform retransmissions without invoking the associated congestion-control procedures. • When packet dropped over wireless • Subsequent acknowledgements indicate non-congestion related loss occurred

16. E2E: Explicit Loss Notification (ELN) • How loss detected in Wireless LAN • If corrupted packet • Receiver detects CRC errors • Passes to transport layer • If entire packet (meaning link headers are lost) is lost • Base station observes duplicate acks • Attaches ELN to them • What if wireless link is sending? • Congestion vs. loss not easy to detect.

17. Other E2E schemes • Adding SACKS or SMART acknowledgements to the basic TCP algorithm allows the sender to handle multiple losses more efficiently. • However, the sender still assumes that losses are a result of congestion.

18. Problem with End-to-End • Un-necessary duplicate acknowledgements sent all the way to source • Un-necessary retransmissions from source to destination • Does not address wireless sender • The last two schemes are not addressing the problem; rather they are trying to make TCP more efficient.

19. Link Level • Handle the problem at the link level, that is where the loss occurred. Local retransmission instead of end-to-end retransmission • Link-level timer much smaller (~20ms) • TCP timers larger (multiples of 500 ms) • Depends on end-to-end delay • Take advantage of the smaller link-level timer; it can be used to retransmit several times before the TCP timer goes off.

20. Link Level • Potential problems: • “Incompatible” timers cause retransmission by both parties. • Unless the packet loss rate is high (more than about 10%), competing retransmissions by the link and transport layers often lead to significant performance degradation. • When packets are lost, link-layer protocols do not attempt in-order delivery across the link. • Packets may reach TCP receiver out-of-order. This causes unnecessary invocations of the retransmission mechanism due to out-of-order delivery messages.

21. Link Layer • Potential Solution • The link level protocol should be TCP aware. • A packet loss is detected by the arrival of a small number of duplicate acknowledgements (TCP) from the receiver or by a local timeout. • It shields the sender from duplicate acknowledgements caused by wireless losses. • Suppresses duplicate acknowledgements.

22. Link Level • A more sophisticated link-layer protocol uses selective retransmissions to improve performance by using SMART acknowledgements. • Sender retransmits a packet when it receives a SMART acknowledgement only if the same packet was not retransmitted within the last round-trip time. • If no further SMART acknowledgements arrive, the sender falls back to the coarse timeout mechanism to recover from the loss.

23. Split Connection Algorithm • Break a single TCP connection from wired end to wireless end into • TCP connection from wired end to base station • TCP connection from base station to wireless end • The TCP sender of the second, wireless connection performs all the retransmissions in response to wireless losses. • End-to-end out of order delivery does not occur • Sender never gets duplicate acks • Two TCP stacks encountered • Sharing of pointers between stacks at base station helps

24. Split Connection Algorithm • End to end semantics violated • Sender can get ack before receiver gets message • Buffer space at base station bounded • Does not acknowledge wired end when this happens.

25. Results of Experiments • Studies imply that link level protocols that are TCP aware provide better performance than a link level protocols that are not TCP aware. • TCP-aware link-layer protocols with selective acknowledgements had the best performance. • The split-connection approach shields sender from wireless loss but sender often stalls due to timeouts on the wireless connection resulting in poor end-to-end throughput. • Adding a SMART-based selective acknowledgement mechanism for split-connection approaches yields good throughput but not quite as good as for TCP-aware link-layers.

26. Results of Experiments • The SMART-based selective acknowledgement scheme added to regular TCP is effective in the presence of lossy links, especially when losses occur in bursts. • E2E schemes are not as effective as local techniques; however significant gains can be achieved without any extensive support from intermediate nodes.