Download Wireless TCP(September 20)

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 biterror 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 noncongestion 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 noncongestion 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.