TCP over Wireless II Based on a presentation

TCP over Wireless (II) Based on a presentation by Nitin Vaidya 1

Last Time g Ideal TCP behavior: Ideally, the TCP sender should simply retransmit a packet lost due to transmission errors, without taking any congestion control actions i. Such a TCP referred to as Ideal TCP i. Ideal TCP typically not realizable g Ideal network behavior: Transmission errors should be hidden from the sender -- the errors should be recovered transparently and efficiently g Proposed schemes attempt to approximate one of the above two ideals 2

Various Schemes g g g g Link-layer retransmissions Split connection approach TCP-Aware link layer TCP-Unaware approximation of TCP-aware link layer Explicit notification Receiver-based discrimination Sender-based discrimination Change TCP’s congestion handling algorithms 3

TCP in Presence of Transmission Errors Summary g Many techniques have been proposed, and several approaches perform well in many environments g Balakrishnan’s paper (any comments? ) Cleanest Solution: end-to-end techniques g i. End-to-end techniques are those which do not require TCP-Specific help from lower layers i. Lower layers may help improve TCP performance without taking TCP-specific actions. Examples: Semi-reliable link level retransmission schemes Explicit notification • • 4

Discussion g Basic Problem: TCP getting confused by dropped packets i. TCP relies on packet loss/reorder as a measure of congestion i. As we’ll see soon, mobility another source for packet loss g Is TCP-Reno the right protocol for wireless? i. Will TCP-Vegas work? i. Is it realistic to change it? 5

Bandwidth Aware TCP g Rely on intermediate routers to determine the share of bandwidth for each connection [Gerla 00] i. Suggested in the context of Internet TCP connections g Fair share value is piggybacked on TCP ACK packets g Source sets its congestion window accordingly i. Similar to Christian’s idea regarding path capacity discovery using ICMP packets g Requires significant support from the network 6

TCP Westwood [Casseti 01] g Sender estimates bandwidth by observing ACK rate g Uses that to set congestion window and slow start thresh. i. Contrast to TCP reno which blindly halves window when it thinks packet is lost g Is not overly sensitive to packet losses or reordering g Requires no changes other than sender g Does not require intermediate nodes to examine TCP headers g 550% improvement over TCP-Reno in their simulations! 7

Impact of Mobility on TCP Performance 8

Impact of Mobility g Hand-offs occur when a mobile host starts communicating with a new base station (in cellular wireless systems) 9

Impact of Mobility g Mobility supported at IP level (Invisible to TCP) i. Need Mobile IP [Johnson 96] ipackets may be lost while a new route is being established reliability despite handoff g We consider this case 10

Hand-off g Hand-offs may result in temporary loss of route to MH iwith non-overlapping cells, it may be a while before the mobile host receives a beacon from the new BS g While routes are being reestablished during handoff, MH and old BS may attempt to send packets to each other, resulting in loss of packets 11

Impact of Handoffs on Schemes to Improves Performance in Presence of Errors g Split connection approach ihard state at base station must be moved to new base station g Snoop protocol/End-to-End isoft state need not be moved iwhile the new base station builds new state, packet losses may not be recovered locally g Frequent handoffs a problem for schemes that rely on significant amount of hard/soft state at base stations ihard state should not be lost isoft state needs to be recreated to benefit performance 12

Techniques to Improve TCP Performance in Presence of Mobility 13

Classification g Hide mobility from the TCP sender g Make TCP adaptive to mobility 14

Using Fast Retransmits to Recover from Timeouts during Handoff [Caceres 95] g g g 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 i. Time wasted until timeout occurs i. Window shrunk after timeout 15

0 -second Rendezvous Delay : Beacon arrives as soon as cell boundary crossed Cell crossing + beacon arrives Handoff complete Routes updated Last timed transmit Retransmission timeout 1. 0 0 0. 15 Packet loss 0. 8 sec Idle sender 16

1 -second Rendezvous Delay : Beacon arrives 1 second after cell boundary crossed Cell crossing Beacon arrives Timeout 1 Last timed transmit Handoff complete 2. 0 1. 0 0 Retransmission timeout 2 0. 8 1. 0 Packet loss 1. 15 2. 8 sec Idle sender 17

Performance [Caceres 95] Four environments 1. No moves 2. Moves (once per 8 sec) between overlapping cells 3. Moves between non-overlapping cells, 0 sec delay 4. Moves between non-overlapping cells, 1 sec delay Experiments using 2 Mbps Wave. Lan 18

TCP Performance 19

TCP Performance g Degradation in case 2 (overlapping cells) is due to encapsulation and forwarding delay during handoff g Additional degradation in cases 3 and 4 due to packet loss and idle time at sender 20

Mitigation Using Fast Retransmit g When MH is the TCP receiver: after handoff is complete, it sends 3 dupacks to the sender ithis triggers fast retransmit at the sender iinstead of dupacks, a special notification could also be sent g When MH is the TCP sender: invoke fast retransmit after completion of handoff 21

0 -second Rendezvous Delay Improvement using Fast Retransmit Cell crossing + beacon arrives Handoff complete Routes updated Retransmission timeout does not occur Fast retransmit Last timed transmit 1. 0 0 0. 15 Packet loss 0. 8 Idle sender 22

TCP Performance Improvement 23

TCP Performance Improvement g No change in cases 1 and 2, as expected g Improvement for non-overlapping cells g Some degradation remains in case 3 and 4 ifast retransmit reduces congestion window 24

Improving Performance by Smooth Handoffs [Caceres 95] g Provide sufficient overlap between cells to avoid packet loss or g Buffer packets at BS i. Discard the packets after a short interval i. If handoff occurs before the interval expires, forward the packets to the new base station i. Prevents packet loss on handoff 25

M-TCP [Brown 97] g In the fast retransmit scheme [Caceres 95] g M-TCP attempts to avoid shrinkage in the congestion window isender starts transmitting soon after handoff i. BUT congestion window shrinks 26

M-TCP Uses TCP Persist Mode g When a new ack is received with receiver’s advertised window = 0, the sender enters persist mode g Sender does not send any data in persist mode g When a positive window advertisement is received, sender exits persist mode g On exiting persist mode, RTO and cwnd are same as before the persist mode iexcept when persist timer goes off 27

M-TCP g Similar to the split connection approach, M-TCP splits one TCP connection into two logical parts ithe two parts have independent flow control as in I-TCP g The BS does not send an ack to MH, unless BS has received an ack from MH imaintains end-to-end semantics g BS withholds ack for the last byte ack’d by MH Ack 999 FH Ack 1000 BS MH 28

M-TCP g g g Withheld ack sent with window advertisement = 0, if MH moves away (handoff in progress) Sender FH put into persist mode during handoff Sender exits persist mode after handoff, and starts sending packets using same cwnd as before handoff FH BS MH 29

M-TCP g The last ack is not withheld, if BS does not expect any other ack from the MH ithis happens when the BS has no other unack’d data buffered locally ithis is required to prevent a sender timeout at the end of a transfer (or end of a burst of data) 30

M-TCP g Avoids reduction of congestion window due to handoff, unlike the fast retransmit scheme isimulation-based performance results look good g Important Question unanswered : Is not reducing the window a good idea? When host moves, route changes, and new route may be more congested than before. It is not obvious that starting full speed after handoff is right. 31

Freeze. TCP [Goff 99] g M-TCP needs help from base station i. Base station withholds ack for one byte i. The base station uses this ack to send a zero window advertisement when a mobile host moves to another cell g Freeze. TCP requires the receiver to send zero window advertisement (ZWA) Mobile TCP receiver FH BS MH 32

Freeze. TCP [Goff 99] g TCP receiver determines if a handoff is about to happen idetermination may be based on signal strength g g g Ideally, 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 ian end-to-end enhancement FH BS Mobile TCP receiver MH 33

Using Multicast to Improve Handoffs [Ghai 94, Seshan 96] g Define a group of base stations including g Address packets destined to the mobile host to the group Only one base station transmits the packets to the mobile host g icurrent cell of a mobile host icells that the mobile host is likely to visit next iif rest of them buffer the packets, then packet loss minimized on handoff 34

Using Multicast to Improve Handoffs g Static group definition [Ghai 94] igroups can be defined taking physical topology into account istatic definition may not take individual user mobility pattern into account g Dynamic group definition [Seshan 96] iimplemented using IP multicast groups ieach user’s group can be different ioverhead of updating the multicast groups is a concern with a large scale deployment 35

Using Multicast to Improve Handoffs g Buffering at multiple base stations incurs memory overhead g Trade-off between buffering overhead and packet loss g Buffer requirement can be reduced by starting buffering only when a mobile host is likely to leave current cell soon 36

TCP in Mobile Ad Hoc Networks 37

Mobile Ad Hoc Networks (MANET) g May need to traverse multiple links to reach a destination 38

Mobile Ad Hoc Networks [IETF-MANET] g Mobility causes route changes 39

TCP in Mobile Ad Hoc Networks Issues g Route changes due to mobility Wireless transmission errors g Out-of-order packet delivery g Multiple access protocol g iproblem compounded with multiple hops ifrequent route changes may cause out-of-order delivery i. TCP does not perform well if packets are significantly OOO ichoice of MAC protocol can impact TCP performance significantly g Half-duplex radios icannot send and receive packets simultaneously ichanging mode (send or receive) incurs overhead 40

Throughput over Multi-Hop Wireless Paths [Gerla 99] g 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 iextent of packet delay or drop increases with number of hops i. This study used CSMA only i. Agree with reservation being better for TCP over ad hoc? g With reliable MAC, still have problems [Xu 02] 41

Impact of Multi-Hop Wireless Paths [Holland 99] TCP Throughput using 2 Mbps 802. 11 MAC 42

Ideal Throughput g f(i) = fraction of time for which shortest path length between sender and destination is I g T(i) = Throughput when path length is I g Ideal throughput = S f(i) * T(i) i. From previous figure 43

Impact of Mobility TCP Throughput 10 m/s Actual throughput 2 m/s Ideal throughput (Kbps) 44

Impact of Mobility 20 m/s Actual throughput 30 m/s Ideal throughput 45

Throughput generally degrades with increasing speed … Ideal Average Throughput Over 50 runs Actual Speed (m/s) 46

But not always … 30 m/s 20 m/s Actual throughput Mobility pattern # 47

Why Does Throughput Degrade? mobility causes link breakage, resulting in route failure Route is repaired TCP sender times out. Starts sending packets again No throughput despite route repair TCP data and acks en route discarded 48

Why Does Throughput Degrade? mobility causes link breakage, resulting in route failure TCP sender times out. Backs off timer. Route is repaired TCP sender times out. Resumes sending No throughput despite route repair Larger route repair delays especially harmful TCP data and acks en route discarded 49

Why Does Throughput Improve? Low Speed Scenario C B D C D B A A 1. 5 second route failure Route from A to D is broken for ~1. 5 second. When TCP sender times after 1 second, route still broken. TCP times out after another 2 seconds, and only then resumes. 50

Why Does Throughput Improve? Higher (double) Speed Scenario C B D C D B A A 0. 75 second route failure Route from A to D is broken for ~ 0. 75 second. When TCP sender times after 1 second, route is repaired. 51

Why Does Throughput Improve? General Principle g g g TCP timeout interval somewhat (not entirely) independent of speed Network state at higher speed, when timeout occurs, may be more favorable than at lower speed Network state i. Link/route status i. Route caches i. Congestion 52

How to Improve Throughput (Bring Closer to Ideal) g Network feedback g Inform TCP of route failure by explicit message g Let TCP know when route is repaired g Reduces repeated TCP timeouts and backoff i. Probing i. Explicit notification 53

Performance Improvement With feedback Actual throughput Without network feedback Ideal throughput 2 m/s speed 54

Performance Improvement With feedback Actual throughput Without network feedback Ideal throughput 30 m/s speed 55

Performance with Explicit Notification [Holland 99] 56

Issues Network Feedback g Network knows best (why packets are lost) + Network feedback beneficial - Need to modify transport & network layer to receive/send feedback g Need mechanisms for information exchange between layers 57

Actual throughput (as fraction of expected throughput) To Cache or Not to Cache Average speed (m/s) 58

Why Performance Degrades With Caching g When a route is broken, route discovery returns a cached route from local cache or from a nearby node g After a time-out, TCP sender transmits a packet on the new route. However, the cached route has also broken after it was cached timeout due to route failure g g timeout, cached timeout, second cached route is broken route also broken Another route discovery, and TCP time-out interval Process repeats until a good route is found 59

Issues To Cache or Not to Cache g Caching can result in faster route “repair” g Faster does not necessarily mean correct g If incorrect repairs occur often enough, caching performs poorly g Need mechanisms for determining when cached routes are stale g Better yet, need mechanisms to make caches more consistent 60

Caching and TCP performance g Caching can reduce overhead of route discovery even if cache accuracy is not very high g Effect of cumulative stale paths g But if cache accuracy is not high enough, gains in routing overhead may be offset by loss of TCP performance due to multiple time-outs 61

Issues Window Size After Route Repair g Same as before route break: may be too optimistic g Same as startup: may be too conservative g Better be conservative than overly optimistic i. Reset window to small value after route repair i. Impact low on paths with small delay-bw product 62

Issues RTO After Route Repair g Same as before route break i. If new route long, this RTO may be too small, leading to timeouts • Except when RTT small compared to clock granularity g Same as TCP start-up (6 second) g Proposal: new RTO = function of old RTO, old route length, and new route length i. May be too large i. Will result in slow response to future losses i. Example: new RTO = old RTO * new route length / old route length i. Not evaluated yet 63

Impact of MAC - Delay Variability g g g As wireless medium is shared between multiple sources, the round-trip delay is variable Also, on slow wireless networks, delay is large imade larger by send-receive turnaround time Large and variable delays result in larger RTO On packet loss, timeout takes much longer to occur Idle source (waiting for timeout to occur) lowers TCP throughput 64

Impact of MAC - Delay Variability [Balakrishnan 97] Several techniques may be used to mitigate problem, based on minimizing ack transmissions ito reduce frequency of send-receive turnaround and contention between acks and data g g Piggybacking link layer acks with data Sending fewer TCP acks - ack every d-th packet (d may be chosen dynamically) • but need to use rate control at sender to reduce burstiness (for large d) g Ack filtering - Gateway may drop an older ack in the queue, if a new ack arrives ireduces number of acks that need to be delivered to the sender 65

Out-of-Order Packet Delivery g Route changes may result in out-of-order (OOO) delivery g Significantly OOO delivery confuses TCP, triggering fast retransmit g Potential solutions: i. Avoid OOO delivery by ordering packets before delivering to IP layer can result in variable delay iturn off fast retransmit can result in poor performance in presence of congestion • • 66

Other Topics 67

Header Compression for Wireless Networks [Degermark 96] g g g In TCP packet stream, most header bits are identical Van Jacobson’s scheme exploits this observation to compress headers, by only sending the “delta” between the previous and current header Packet losses result in inefficiency, as headers cannot be reconstructed due to lost information Packet losses likely on wireless links [Degermark 96] proposes a technique that works well despite single packet loss i“twice” algorithm iif current packet fails TCP checksum, assume that a single packet is lost iapply delta for the previous packet twice to the current header, and test checksum again 68

Twice Algorithm : Example delta 2 delta 69

Channel State Dependent Packet Scheduling [Bhagwat 96] g Head-of-the Line blocking can occur with FIFO (firstin-first-out) scheduling, if sender attempts to retransmit packets on a channel in a bad state M 1 M 2 M 3 M 1 Wireless card M 2 M 3 70

Channel State Dependent Packet Scheduling g g Separate queue for each destination Channel state monitor somehow determines if a channel is in burst error state M 1 M 1 M 2 scheduler Wireless card M 2 Per M 3 destination queues Channel status monitor M 3 71

Channel State Dependent Packet Scheduling g Packets transmitted on bad channels, only if packets for no other channels present in queues M 1 M 1 M 2 scheduler Wireless card M 2 Per M 3 destination queues Channel status monitor M 3 72

Channel State Dependent Packet Scheduling g Needs a reasonably good Channel State Monitor M 1 M 1 M 2 scheduler Wireless card M 2 Per M 3 destination queues Channel status monitor M 3 73

Automatic TCP Buffer Tuning [Semke 98] g Using too small buffers can yield poor performance g Using too large buffers can limit number of open connections g Automatic mechanisms to choose buffer size dynamically would be useful 74

Issues for Further Investigation 75

Link Layer Protocols g “Pure” link layer designs that support higher transport performance isome recent work in this area as noted earlier g Identifying scenarios where link layer solutions are inadequate g If TCP-awareness is absolutely needed, provide an interface that can be used by other transport protocols too 76

End-to-End Techniques g g g Existing techniques typically require cooperation from intermediate nodes. Such techniques often not applicable iencrypted TCP headers i. TCP data and acks do not go through same base station End-to-end techniques would rely on information available only at end nodes i. Harder to design due to lack of complete information about errors i. Explicit Notifications may make that easier 77

Impact of Congestion Losses g Past work typically evaluates performance in absence of congestion g Relative performance improvement may change substantially when congestion occurs iperformance improvement may reduce if congestion is dominant, or if RTO becomes larger due to wireless errors 78

Multiple TCP Transfers g Past work typically measures a single TCP connection over wireless i. TCP throughput is the metric of choice g When multiple connections share a wireless link, other performance metrics may make sense ifairness iaggregate throughput g Relative performance improvements of various schemes may change when multiple connections are considered 79

TCP Window & RTO Settings After a Move g g Congestion window & RTO size at connection open are chosen to be conservative When a route change occurs due to mobility, which values to use? i. Same as before route change i. Same as at connection open g ---- may be too aggressive ---- may be too conservative Answer unclear isome proposals attempt to use same values as before route change, but not clear if that is the best alternative g Mobicom 2001 (Noble) discussing “filters” for quickly adapting in a highly dynamic environment 80

TCP for Mobile Ad Hoc Networks g g g Much work on routing in ad hoc networks Some recent work on TCP for ad hoc networks Need to investigate many issues i. MAC-TCP interaction irouting-TCP interaction iimpact of route changes on window size, RTO choice after move 81