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.