Wireless TCP

References r 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.A Comparison of Mechanisms for Improving TCP Performance over Wireless Links

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

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

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

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

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

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

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

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

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

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

Issues

Possible Adaptations r Where in the path from sender to receiver to solve problem? m End-to-end Sender and receiver together addresses problem They address congestion loss They should also address medium loss m Link layer addresses problem Problem occurred in the link and thus should be solved there. m 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)

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

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

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

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

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

Link Level r Potential problems: m “Incompatible” timers cause retransmission by both parties. m 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. m 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.

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

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

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

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

Results of Experiments r Studies imply that link level protocols that are TCP aware provide better performance than a link level protocols that are not TCP aware. r TCP-aware link-layer protocols with selective acknowledgements had the best performance. r 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. r 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.

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