Wireless TCP
Wireless TCP
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.
Network protocol stack 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
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?
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
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
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
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).
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.
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.
What is Needed?
Distinguish between congestion and other losses
Do not reduce window in response to non- congestion losses
Issues
Where in the path from sender to receiver to solve problem?
How to distinguish between the two reasons for losses?
Issues
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)
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.