ECS-087: Mobile Computing TCP over wireless TCP and mobility Most of the Slides borrowed from Prof. Sridhar Iyer s lecture IIT Bombay Diwakar Yagyasen 1
Effect of Mobility on Protocol Stack Application: new applications and adaptations Transport: congestion and flow control Network: addressing and routing Link: media access and handoff Physical: transmission errors and interference Diwakar Yagyasen 2
TCP basics Reliable, ordered delivery uses sequence numbers, acknowledgements, timeouts and retransmissions End-to-end semantics (ACK after data recd) Provides flow and congestion control uses sliding window based buffers and feedback from receiver/network to adjust transmission rate Diwakar Yagyasen 3
Window based flow control Window size minimum of receiver s advertised window - determined by available buffer space at the receiver congestion window - determined by sender, based on network feedback Sender s window 1 2 3 4 5 6 7 8 9 10 11 12 13 Acks received Not transmitted Diwakar Yagyasen 4
Timeouts and retransmission TCP manages four different timers for each connection retransmission timer: when awaiting ACK persist timer: keeps window size information flowing keepalive timer: when other end crashes or reboots 2MSL timer: for the TIME_WAIT state Diwakar Yagyasen 5
timeout Seq=100 timeout Seq=92 timeout TCP: retransmission scenarios Host A Host B Host A Host B X loss lost ACK scenario premature timeout, cumulative ACKs Diwakar Yagyasen 6
RTT estimation Exponential Averaging Filter: Measure SampleRTT for segment/ack pair Compute weighted average of RTT EstimatedRTT = α PrevEstimatedRTT + (1 α) SampleRTT RTO = β * EstimatedRTT Typically α = 0.9; β = 2 Diwakar Yagyasen 7
Ideal window size Ideal size = delay * bandwidth delay-bandwidth product If window size < delay*bw Inefficiency (wasted bandwidth) If window size > delay*bw Queuing at intermediate routers (increased RTT) Potentially, packet loss Diwakar Yagyasen 8
Congestion control On detecting a packet loss, TCP sender assumes that network congestion has occurred On detecting packet loss, TCP sender drastically reduces the congestion window Reducing congestion window reduces amount of data that can be sent per RTT Diwakar Yagyasen 9
Congestion window (segments) Typical TCP behaviour 25 20 15 10 5 cwnd = 20 After timeout ssthresh = 8 ssthresh = 10 0 0 3 6 9 12 15 20 22 25 Time (round trips) Diwakar Yagyasen 10
Window size (segments) Fast retransmit and Fast recovery 10 8 6 4 2 0 0 2 4 6 8 10 12 14 Time (round trips) advertised window After fast recovery Diwakar Yagyasen 11
Typical mobile wireless scenario FH: Fixed Host MH: Mobile Host BS: Base Station (gateway) Diwakar Yagyasen 12
Burst errors may cause Timeouts If wireless link remains unavailable for extended duration, a window worth of data may be lost driving through a tunnel; passing a truck Timeout results in slow start Slow start reduces congestion window to 1 MSS, reducing throughput Reduction in window in response to errors unnecessary Diwakar Yagyasen 13
Random errors may cause Fast Retransmit or Timeout If a packet is lost due to transient link conditions Channel noise leading to CRC error Fast retransmit results in fast recovery Fast recovery reduces congestion window to 1/2 If multiple packets losses happen in a window, Results in timeout Reduction in window in response to errors unnecessary Diwakar Yagyasen 14
Example: Random errors 40 39 38 37 34 37 42 41 40 39 37 37 44 43 42 41 37 37 37 Diwakar Yagyasen 15
TCP and wireless/mobility TCP assumes congestion if packets dropped typically wrong in wireless networks often packet loss due to transmission errors mobility itself can cause packet loss nodes roam from one access point or foreign agent to another with packets in transit Diwakar Yagyasen 16
Motivation for TCP adaptation Performance of an unchanged TCP degrades severely for wireless/mobile environments TCP cannot be changed fundamentally Widely deployed in the fixed network Internet interoperability requirement TCP for wireless/mobility has to be compatible with standard TCP Diwakar Yagyasen 17
Adaptation for TCP over wireless Several proposals to adapt TCP to wireless environments Modifications to TCP implementation at Fixed Host Base Station Mobile Host Approaches Hide error losses from the sender Let sender know the cause of packet loss Diwakar Yagyasen 18
Ideal behavior Ideal TCP behavior: TCP sender should simply retransmit a packet lost due to transmission errors, without taking any congestion control actions Ideal TCP typically not realizable Ideal network behavior: Transmission errors should be hidden from the sender Errors should be recovered transparently and efficiently Proposed schemes attempt to approximate one of the above two ideals Diwakar Yagyasen 19
Link Layer mechanisms Forward Error Correction (FEC) Can be use to correct small number of errors Incurs overhead even when errors do not occur Link Level Retransmissions Retransmit a packet at the link layer, if errors are detected Retransmission overhead incurred only if errors occur Diwakar Yagyasen 20
Link Level Retransmissions Link layer state TCP connection application application application transport transport transport network link network link rxmt network link physical physical physical wireless Diwakar Yagyasen 21
Issues How many times to retransmit at the link level before giving up? What triggers link level retransmissions? How much time is required for a link layer retransmission? Should the link layer deliver packets as they arrive, or deliver them in-order? Diwakar Yagyasen 22
Split connection approach End-to-end TCP connection is broken into one connection on the wired part of route and one over wireless part of the route FH-MH = FH-BS + BS-MH FH BS MH Fixed Host Base Station Mobile Host Diwakar Yagyasen 23
I-TCP: Split connection Per-TCP connection state TCP connection TCP connection application application rxmt application transport transport transport network network network link link link physical physical physical wireless Diwakar Yagyasen 24 Source: Vaidya
I-TCP advantages No changes to TCP for FH BS-MH connection can be optimized independent of FH-BS connection Different flow / error control on the two connections Faster recovery due to relatively shorter RTT on wireless link Diwakar Yagyasen 25
I-TCP disadvantages End-to-end semantics violated ack may be delivered to sender, before data delivered to the receiver BS retains hard state Buffer space required at BS on a per-tcpconnection basis BS failure can result in permanent loss of data (unreliability) Hand-off latency increases Diwakar Yagyasen 26
Hand-off in I-TCP Data that has been ack d to sender, must be moved to new base station 39 FH 41 40 BS 38 37 37 MH 39 40 MH Hand-off New base station Diwakar Yagyasen 27
Snoop Protocol Retains local recovery of Split Connection approach and uses link level retransmission Improves on split connection end-to-end semantics retained soft state at base station, instead of hard state Diwakar Yagyasen 28
Snoop Protocol Buffers data packets at the base station BS to allow link layer retransmission When duplicate ACK received by BS from MH retransmit on wireless link, if packet present in buffer drop duplicate ACK Prevents fast retransmit at TCP sender FH FH BS MH Diwakar Yagyasen 29
Snoop Protocol TCP connection Per TCP-connection state application application application transport transport transport network link network link rxmt network link physical physical physical FH BS wireless MH Diwakar Yagyasen 30 Source: Vaidya
Snoop : Example 35 TCP state 36 maintained at link layer 37 38 FH 40 39 38 37 35 BS 37 MH Diwakar Yagyasen 31
Snoop : Example 37 38 39 40 41 42 FH 44 43 BS 37 Discard dupack 37 37 41 37 MH Diwakar Yagyasen 32
Snoop advantages Local recovery from wireless losses Fast retransmit not triggered at sender despite out-oforder link layer delivery High throughput can be achieved End-to-end semantics retained Soft state at base station loss of the soft state affects performance, but not correctness Diwakar Yagyasen 33
Snoop disadvantages Link layer at base station needs to be TCP-aware Not useful if TCP headers are encrypted (IPsec) Diwakar Yagyasen 34
Delayed Dupacks Attempts to imitate Snoop, without making the base station TCP-aware Delayed Dupacks implements the same two features at BS : link layer retransmission at MH : reducing interference between TCP and link layer retransmissions (by delaying dupacks) Diwakar Yagyasen 35
Delayed Dupacks TCP receiver delays dupacks for interval D, when out-of-order packets received Dupack delay intended to give link level retransmit time to succeed Benefit: can result in recovery from a transmission loss without triggering a response from the TCP sender Diwakar Yagyasen 36
Delayed dupacks advantages Link layer need not be TCP-aware Can be used even if TCP headers are encrypted Works well for relatively small wireless RTT (compared to end-to-end RTT) relatively small delay D sufficient in such cases Diwakar Yagyasen 37
Delayed dupacks disadvantages Right value of dupack delay D dependent on the wireless link properties Mechanisms to automatically choose D needed Delays dupacks for congestion losses too, delaying congestion loss recovery Diwakar Yagyasen 38
Mobility and handoff Hand-offs may result in temporary loss of route to MH with non-overlapping cells, it may be a while before the mobile host receives a beacon from the new BS While routes are being reestablished during handoff, MH and old BS may attempt to send packets to each other, resulting in loss of packets Diwakar Yagyasen 39
Impact of handoff Split connection approach hard state at base station must be moved to new base station Snoop protocol soft state need not be moved while the new base station builds new state, packet losses may not be recovered locally Diwakar Yagyasen 40
Handoff issues During the long delay for a handoff to complete a whole window worth of data may be lost After handoff is complete acks are not received by the TCP sender Sender eventually times out, and retransmits If handoff still not complete, another timeout will occur Performance penalty Time wasted until timeout occurs Window shrunk after timeout Diwakar Yagyasen 41
Using Fast Retransmit When MH is the TCP receiver: after handoff is complete, it sends 3 dupacks to the sender this triggers fast retransmit at the sender When MH is the TCP sender: invoke fast retransmit after completion of handoff Diwakar Yagyasen 42
Mobile TCP (M-TCP) Handling of lengthy or frequent disconnections M-TCP splits as I-TCP does unmodified TCP for FH to BS optimized TCP for BS to MH BS (Foreign Agent) monitors all packets, if disconnection detected set advertised window size to 0 sender automatically goes into persistent mode no caching, no retransmission at the BS If a packet is lost on the wireless link, it has to be retransmitted by the original sender Diwakar Yagyasen 43
M-TCP BS does not send an ack to FH, unless BS has received an ack from MH maintains end-to-end semantics BS withholds ack for the last byte ack d by MH When BS does not receive ACK for sometime, it chokes sender by setting advertise window to 0 Ack 999 Ack 1000 FH BS MH Diwakar Yagyasen 44
M-TCP When a new ack is received with receiver s advertised window = 0, the sender enters persist mode Sender does not send any data in persist mode except when persist timer goes off When a positive window advertisement is received, sender exits persist mode On exiting persist mode, RTO and cwnd are same as before the persist mode Diwakar Yagyasen 45
M-TCP Avoids reduction of congestion window due to handoff, unlike the fast retransmit scheme Is not reducing the window a good idea? When host moves, route changes, and new route may be more congested It is not obvious that starting full window after handoff is right Diwakar Yagyasen 46
FreezeTCP M-TCP needs help from base station (BS) BS withholds ack for one byte BS uses this ack to send a zero window advertisement when MH moves to another cell FreezeTCP Receiver sends zero window advertisement (ZWA), upon impending disconnection Receiver sends full window advertisement (FWA), upon reconnection Diwakar Yagyasen 47
FreezeTCP TCP receiver determines if a handoff is about to happen determination may be based on signal strength Receiver should attempt to send ZWA 1 RTT before handoff Receiver sends 3 dupacks when route is reestablished No help needed from the base station Diwakar Yagyasen 48
Multi-hop Wireless (MANET) Mobility causes route changes Diwakar Yagyasen 49
TCP Issues Route changes due to mobility Wireless transmission errors problem compounded with multiple hops Out-of-order packet delivery frequent route changes may cause out-of-order delivery Multiple access protocol choice of MAC protocol can impact TCP performance significantly Diwakar Yagyasen 50
TCP over multi hop wireless When contention-based MAC protocol is used, connections over multiple hops are at a disadvantage compared to shorter connections because they have to contend for wireless access at each hop extent of packet delay or drop increases with number of hops Diwakar Yagyasen 51
Impact of Multi-Hop Wireless Paths 1600 1400 1200 1000 800 600 400 200 0 1 2 3 4 5 6 7 8 9 10 Number of hops TCP Throughtput (Kbps) TCP Throughput using 2 Mbps 802.11 MAC Diwakar Yagyasen 52
Impact of mobility mobility causes link breakage, resulting in route failure Route is repaired TCP sender times out. Starts sending packets again No throughput No throughput despite route repair TCP data and acks en route discarded Diwakar Yagyasen 53
Positive impact of mobility C D C D C D B A B A B A 1.5 second route failure Route from A to D is broken for ~1.5 second. When TCP sender times out after 1 second, route still broken. TCP times out after another 2 seconds, and only then resumes. Throughput improves because number of hops reduced. Diwakar Yagyasen 54
Improving throughput Network feedback Inform TCP of route failure by explicit message Let TCP know when route is repaired Probing Explicit notification Reduces repeated TCP timeouts and backoff Diwakar Yagyasen 55
Network Feedback Network feedback beneficial Need to modify transport & network layer to receive/send feedback Need mechanisms for information exchange between layers Diwakar Yagyasen 56
References Bakre, A., Badrinath, B., I-TCP: Indirect TCP for mobile hosts - IEEE ICDCS 1995. Balakrishnan, H., Srinivasan, S., Amir, E., and Katz, R., Improving TCP/IP Performance over Wireless Networks ACM Mobicom 1995. Brown, K., Singh, S., M-TCP: TCP for mobile cellular networks ACM Computer Communication Review, 27 (5), 1997. Goff, T. Moronski, J. Phatak, D.S. Gupta, V. Freeze-TCP: a true end-to-end TCP enhancement mechanism for mobile environments IEEE Infocom 2000. Diwakar Yagyasen 57