1. CMPE 257 Spring 20021 CMPE 257: Wireless and Mobile Networking Spring 2002 Week 7

2. CMPE 257 Spring 20022 Announcements Grades up to report 3 are out. Midterm next class. Reading assignment 4 due May 17.

3. CMPE 257 Spring 20023 Today Transport layer (cont’d). TCP over satellite. TCP over MANETs. Reliable multicast.

4. CMPE 257 Spring 20024 Transport Layer: Outline TCP/IP basics. Impact of transmission errors on TCP performance. Approaches to improve TCP performance. Classification. Discussion of selected approaches. TCP over satellite. Issues in MANETs.

5. CMPE 257 Spring 20025 TCP Over Satellite

6. CMPE 257 Spring 20026 Satellite Links High bandwidth-delay product. Higher error rates than terrestrial links.

7. CMPE 257 Spring 20027 Improving TCP over Satellite Extension of sequence number space with timestamp option. Larger congestion window (window scale option) Maximum window size up to 2^30 (instead of 2^16) bytes. Acknowledge every packet (do not delay acks). Selective acks Allow multiple packet recovery per RTT and avoid slow-start.

8. CMPE 257 Spring 20028 Some Proposals Space Communications Protocol Standard- Transport Protocol (SCPS-TP) [Durst96]. During link outage, TCP sender freezes itself, and resumes when link is restored Outage assumed to occur in both directions simultaneously Ground station can detect outage of incoming link (for instance, by low signal levels). Sender does not unnecessarily timeout or retransmit until it is informed that link has recovered. Sack to recover losses quickly.

9. CMPE 257 Spring 20029 Some Proposals (Cont’d) Satellite Transport Protocol (STP) [Henderson98] Uses split connection approach. Protocol on satellite channel different from TCP. Sacks when receiver detects losses. Transmitter periodically requests receiver to ack received data. Reduces reverse channel bandwidth usage when losses are rare.

10. CMPE 257 Spring 200210 Some Proposals (Cont’d) TCP Spoofing Early ACKing. A la Snoop TCP. Ground station acks packets Should take responsibility for delivering packets. Early acks from ground station result in faster congestion window growth.

11. CMPE 257 Spring 200211 TCP in Mobile Ad Hoc Networks

12. CMPE 257 Spring 200212 Issues Route changes due to mobility. Route change frequency. Route establishment delay. Wireless transmission errors. Problem compounded due to multiple hops. Out-of-order packet delivery. Frequent route changes may cause OOO delivery. MAC. MAC protocol can impact TCP performance.

13. CMPE 257 Spring 200213 Throughput over Multi-Hop Wireless Paths [Gerla99] When contention-based MAC protocol is used, connections over multiple hops are at a disadvantage compared to shorter connections. They have to contend for wireless access at each hop. Delay or drop probability increases with number of hops.

14. CMPE 257 Spring 200214 Analysis of TCP Performance over MANETs [Holland99] Impact of mobility. Simulation study. Performance metric: throughput. Baseline: ideal (expected) throughput. Upper bound. Static network.

15. CMPE 257 Spring 200215 Ideal Throughput f(i) = fraction of time for which shortest path length between sender and destination is I. T(i) = throughput when path length is I (no mobility). Ideal throughput =  f(i) * T(i)

16. CMPE 257 Spring 200216 Throughput versus Hops TCP throughput over 2 Mbps 802.11 MAC, fixed, linear MANET.

17. CMPE 257 Spring 200217 Throughput versus speed Speed (m/s) Average Throughput Over 50 runs Ideal Actual Throughput decreases with speed…

18. CMPE 257 Spring 200218 Throughput versus Speed Mobility pattern # Actual throughput 20 m/s 30 m/s But not always…

19. CMPE 257 Spring 200219 Impact of Mobility TCP Throughput Ideal throughput (Kbps) Actual throughput 2 m/s10 m/s

20. CMPE 257 Spring 200220 Impact of Mobility Ideal throughput Actual throughput 20 m/s 30 m/s

21. CMPE 257 Spring 200221 mobility causes link breakage, resulting in route failure TCP data and acks en route discarded Why Throughput Degrades TCP sender starts sending packets again Route is repaired No throughput despite route repair

22. CMPE 257 Spring 200222 mobility causes link breakage, resulting in route failure TCP data and acks en route discarded Why Throughput Degrades? TCP sender times out. Backs off timer. Route is repaired TCP sender resumes sending Larger route repair delays especially harmful No throughput despite route repair

23. CMPE 257 Spring 200223 Why Throughput Improves? Low Speed Scenario C B D A C B D A C B D 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.

24. CMPE 257 Spring 200224 Why Throughput Improves? Higher Speed Scenario C B D A C B D A C B D 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.

25. CMPE 257 Spring 200225 Why Throughput Improves? General Principle TCP timeout interval somewhat independent of speed. Network state at higher speed, when timeout occurs, may be more favorable than at lower speed. Network state: Link/route status. Route caches. Congestion.

26. CMPE 257 Spring 200226 How to Improve Throughput Network feedback. Inform TCP of route failure explicitly. Let TCP know when route is repaired. Probing. Explicit notification. Reduces repeated TCP timeouts and backoff.

27. CMPE 257 Spring 200227 Performance Improvement Without network feedback Ideal throughput 2 m/s speed With feedback Actual throughput

28. CMPE 257 Spring 200228 Performance Improvement Without network feedback With feedback Ideal throughput 30 m/s speed Actual throughput

29. CMPE 257 Spring 200229 Performance with Explicit Notification

30. CMPE 257 Spring 200230 Issues: Network Feedback Network knows best (why packets are lost). + Network feedback beneficial. - Need to modify transport & network layer to receive/send feedback Need mechanisms for information exchange between layers.

31. CMPE 257 Spring 200231 Impact of Caching Route caching has been suggested as a mechanism to reduce route discovery overhead (e.g., DSR). Each node may cache one or more routes to given destination. When route from S to D detected as broken, node S may: Use another cached route from local cache, or Obtain a new route using cached route at another node.

32. CMPE 257 Spring 200232 To Cache or Not to Cache Average speed (m/s) Actual throughput (as fraction of expected throughput)

33. CMPE 257 Spring 200233 Why Performance Degrades With Caching When a route is broken, route discovery returns cached route from local cache or from nearby node. Cached routes may also be broken. timeout due to route failure timeout, cached route is broken timeout, second cached route also broken

34. CMPE 257 Spring 200234 To Cache or Not to Cache Caching can result in faster route “repair”. But, faster does not necessarily mean correct. If incorrect repairs occur often enough, caching performs poorly. Need mechanisms for determining when cached routes are stale.

35. CMPE 257 Spring 200235 Caching and TCP Performance Caching can reduce overhead of route discovery even if cache accuracy is not very high. But if cache accuracy is not high enough, gains in routing overhead may be offset by loss of TCP performance due to multiple timeouts.

36. CMPE 257 Spring 200236 Window Size After Route Repair When route breaks: may be too optimistic or may be too conservative. Better be conservative than overly optimistic Reset window to small value after route repair. TCP needs to be aware of route repair (Route Failure and Route Re-establishment Notifications). Impact low on paths with small delay-bw product.

37. CMPE 257 Spring 200237 RTO After Route Repair If new route longer, RTO may be too small, leading to timeouts. New RTO = function of old RTO, old route length, and new route length. Example: new RTO = old RTO * new route length / old route length Not evaluated yet.

38. CMPE 257 Spring 200238 Impact of MAC - Delay Variability Shared wireless medium (and contention MACs) causes RTT to be highly variable. On slow wireless networks, delay is larger. Large and variable RTTs result in larger RTO. On packet loss, timeout takes much longer to occur. Idle source (waiting for timeout to occur) lowers TCP throughput.

39. CMPE 257 Spring 200239 Impact of MAC - Delay Variability [Balakrishnan97] Basic idea: minimize ack transmissions. Reduce frequency of send-receive turnaround and contention between acks and data. Piggybacking link layer acks with data. Sending fewer TCP acks - ack every d-th packet (d may be chosen dynamically). Ack filtering - older acks in the queue, if new ack arrives.

40. CMPE 257 Spring 200240 TCP Over Different Routing Protocols [Dyer2001] Impact of routing algorithm on TCP performance. Metrics: connect time, throughput and overhead. On-demand versus proactive. Proactive routing protocol outperforms reactive ones. Why? Sender-based heuristic to improve TCP’s performance.

41. CMPE 257 Spring 200241 Fixed-RTO TCP does not exponentially backoff the RTO. Uses sender-based heuristic to distinguish between congestion and “route failure” losses. Route failure assumed if 2 consecutive timeouts. Unack’d packet retransmitted. No RTO backoff in the second (and +) timeout. RTO remains fixed until retransmission is ack’d.

42. CMPE 257 Spring 200242 Out-of-Order Packet Delivery Route changes may result in out-of-order (OOO) delivery. Significantly OOO delivery confuses TCP, triggering fast retransmit or… Potential solutions: Avoid OOO delivery by ordering packets before delivering to IP layer Turn off fast retransmit. Can result in poor performance in presence of congestion

43. CMPE 257 Spring 200243 TCP DOOR [Wang2002] Detect and respond to out-of-order (OOO) packets. Differentiate between OOO and congestion losses. OOO delivery caused by: Retransmissions. Route changes.

44. CMPE 257 Spring 200244 Detecting OOO Sender detects OOO ACKs. Receiver detects OOO data packets. How would you classify their scheme?

45. CMPE 257 Spring 200245 OOO ACKs Sequence number of packet being ACKed: monotonically increasing. Why? ACKs are not re-transmitted. When would this not work? For DUPACKs, add 1-byte to count DUPACKs. ADSN: ACK duplication sequence number. TCP header option. Each DUPACK carries different ADSN.

46. CMPE 257 Spring 200246 OOO Data Packets At receiver. Why comparing sequence numbers doesn’t work? Retransmissions: higher sequence #’s can arrive earlier. Out-of-sequence event. Use extra sequence number: incremented with every data packet, including retransmissions. 2-byte TCP packet sequence number (TPSN) as TCP option. Or timestamp. Sender needs to be notified.

47. CMPE 257 Spring 200247 OOO Response At sender. 2 types of response: Temporary disable congestion control for fixed time interval T1. If in congestion avoidance mode in the last T2 time interval, go back to prior state.

48. CMPE 257 Spring 200248 Evaluation Simulation environment: ns-2 + CMU extensions. Mobility: random way-point. Comments? Workload: single TCP between fixed S and R with and without congestion. Comments? What other info will be useful in analysis?

49. CMPE 257 Spring 200249 Results Significant goodput improvement (~50%) when 2 response mechanisms used. Sender versus receiver detection. Seem to perform the same. Correlation between OOO ACKs and data. Response mechanisms. Both in place show better performance.

50. CMPE 257 Spring 200250 DSR Caching With DSR caching enabled, lower performance improvements. Claim TCP performance was better than when caching was off. Why?

51. CMPE 257 Spring 200251 Reliable Mutlicast in MANETs

52. CMPE 257 Spring 200252 Motivation Group communication services as important application class for key MANET scenarios: special operations, exploration, etc. E.g., teleconferencing and data dissemination. Multicast: efficient way of delivering many-to-many data.

53. CMPE 257 Spring 200253 Challenges Achieve reliability in the presence of constant mobility, route changes, transmission errors over multi-hop wireless routes. MANETs are very sensitive to load and congestion. Contention-based MACs. Hidden terminal problems. Not much has been done…

54. CMPE 257 Spring 200254 Reliable Broadcast [Pagani1997] Special case: all nodes are receivers. Reliable broadcast: all nodes deliver same set of messages to application. “Exactly-once” semantics. Assumes underlying clustering algorithm.

55. CMPE 257 Spring 200255 Primitives rbcast (msg, group-id) Caller blocks until message received by clusterhead. deliver(msg) Notification of mssage reception by all other nides.

56. CMPE 257 Spring 200256 Entities Gateway Cluterhead

57. CMPE 257 Spring 200257 Protocol Sender sends message to its clusterhead. Clusterhead broadcasts message within cluster and waits for ACKs. Nodes reply with ACK. Gateways forward message to directly connected clusters (through clusterheads). Gateway delays its ACK until it gets ACK from corresponding clusterheads.

58. CMPE 257 Spring 200258 Protocol (Cont’d) If same message received over multiple paths: clusterhead selects one; piggybacks the sender id in the message and broadcasts. Non-selected gateway receives the broadcast and records it’s the leaf for that message. Prevents loops, allows multi-path, reduces duplicates. Reverse path is recorded: ACKs flow back.

59. CMPE 257 Spring 200259 Failures and Mobility Timeouts and retransmissions. Recovery by clusterheads & gateways.

60. CMPE 257 Spring 200260 Summary 2 phases: Diffusion: message diffused from source to destinations. Gathering: source collects ACKs. On-demand forwarding tree rooted at source. If “virtual” links break, flooding is used. Clusterheads buffer messages until ACK comes back. Reliability guaranteed as long as “liveness” property holds. Topology is stable enough.

61. CMPE 257 Spring 200261 Issues Larger networks? High delays. Target smaller groups (10->100???). What happens when clusterheads and gateways fail/move? Satisfying “liveness” is tricky. Heavy duty protocol. State at nodes. ACKs for reliability.

62. CMPE 257 Spring 200262 Anonymous Gossip [Chandra2001] Approach: Use of underlying “best-effort” multicast routing mechanism. Repair losses through gossip-based propagation. Gossip propagation is well-known! Examples?

63. CMPE 257 Spring 200263 Gossip Round Node A randomly chooses node B. A and B exchange information on messages they have and don’t have. A and B exchange missing messages.

64. CMPE 257 Spring 200264 Anonymity No need for membership information. gossip-message and gossip-reply. Node selects random neighbor and sends gossip-message. If node is not group member, selects neighbor and forwards; if member, decides to accept or forward. If accepts, unicasts gossip-reply back.

65. CMPE 257 Spring 200265 Locality Choosing closer-by or farther members. Why is this an issue? Choose near members with higher probability. Need to keep extra state: nearest-member. Extra overhead to maintain this information. Dependence on the underlying routing protocol!

66. CMPE 257 Spring 200266 Cached Gossip Gossip with known members. member-cache keeps information on known members. Updated when messages are received (data, gossip-reply, RREQ, etc.). Node uses AG with probability p anon ; otherwise cached gossip. Why cached gossip?

67. CMPE 257 Spring 200267 Performance Evaluation Simulations using GloMoSim. M-AODV. Single source. Random way-point. Parameters: range, number of nodes, and maximum node speed.

68. CMPE 257 Spring 200268 Results Improves packet delivery ratio. Overhead? Delay? Comparison with flooding?

69. CMPE 257 Spring 200269 CALM [Tang2002] Like AG, e2e approach. Initial study comparing SRM to UDP showed SRM performs badly in MANETs. Why? SRM is heavy duty. No congestion control!

70. CMPE 257 Spring 200270 Impact of Congestion Control on Reliability? CALM uses “rate-based” CC. Data is sent at application rate. If congestion, sender clocks sending rate based on receivers experiencing congestion. Congested receivers kept in receiver- list. Feedback is unicast to the source. Generated after N consecutive packets are missing.

71. CMPE 257 Spring 200271 CALM’s State Machine IDLE TX WF_ACK No packets to send Send packet, Receiver List empty Has packet to send Timeout, keep receiver in Receiver List Send packet, Receiver List not empty (addressed to a receiver in list) Recv ACK, remove receiver from Receiver List * ACK, remove receiver from Receiver List * ACK, remove receiver from Receiver List * ACK, remove receiver from Receiver List

72. CMPE 257 Spring 200272 Evaluation Simulations using QualNet. Comparison between CALM, SRM, and (multicast) UDP. ODMRP. Metrics: packet delivery, overhead, delay, goodput.

73. CMPE 257 Spring 200273 Results CALM outperforms SRM. UDP performs surprisingly well, except under high traffic loads. Proves need for congestion control. SRM’s main problem is extra load caused by its control packets. Congestion control helps but still need relaibility.

74. CMPE 257 Spring 200274 Ongoing Work RALM: reliability+congestion control. Make control mechanisms scalable. Select smaller set of receivers (maybe 1). Use rate-based CC instead of stop-and-go. Interaction with MAC layer. Comparison with AG and use different routing protocols. ….