CMPE 257: Wireless and Mobile Networking

1
CMPE 257 Wireless and Mobile Networking

• Spring 2002
• Week 7

2
Announcements

• Grades up to report 3 are out.
• Midterm next class.
• Reading assignment 4 due May 17.

3
Today

• Transport layer (contd).
• TCP over satellite.
• TCP over MANETs.
• Reliable multicast.

4
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
TCP Over Satellite
6
Satellite Links

• High bandwidth-delay product.
• Higher error rates than terrestrial links.

7
Improving TCP over Satellite

• Extension of sequence number space with timestamp
  option.
• Larger congestion window (window scale option)
• Maximum window size up to 230 (instead of 216)
  bytes.
• Acknowledge every packet (do not delay acks).
• Selective acks
• Allow multiple packet recovery per RTT and avoid
  slow-start.

8
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
Some Proposals (Contd)

• 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
Some Proposals (Contd)

• 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
TCP in Mobile Ad Hoc Networks
12
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
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
Analysis of TCP Performance over MANETs
Holland99

• Impact of mobility.
• Simulation study.
• Performance metric throughput.
• Baseline ideal (expected) throughput.
• Upper bound.
• Static network.

15
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 S f(i) T(i)

16
Throughput versus Hops
TCP throughput over 2 Mbps 802.11 MAC, fixed,
linear MANET.
17
Throughput versus speed
Throughput decreases with speed
Ideal
Average Throughput Over 50 runs
Actual
Speed (m/s)
18
Throughput versus Speed
But not always
30 m/s
20 m/s
Actual throughput
Mobility pattern
19
Impact of MobilityTCP Throughput
2 m/s
10 m/s
Actual throughput
Ideal throughput (Kbps)
20
Impact of Mobility
20 m/s
30 m/s
Actual throughput
Ideal throughput
21
Why Throughput Degrades
22
Why Throughput Degrades?
23
Why Throughput Improves?Low Speed Scenario
D
D
D
C
C
C
B
B
B
A
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.
24
Why Throughput Improves?Higher Speed Scenario
D
D
D
C
C
C
B
B
B
A
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.
25
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
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
Performance Improvement
Without network feedback
With feedback
Actual throughput
Ideal throughput 2 m/s speed
28
Performance Improvement
Without network feedback
With feedback
Actual throughput
Ideal throughput 30 m/s speed
29
Performance with Explicit Notification
30
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
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
To Cache or Not to Cache
Actual throughput (as fraction of expected
throughput)
Average speed (m/s)
33
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.

34
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
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
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
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
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
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
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 TCPs
  performance.

41
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.
• Unackd packet retransmitted.
• No RTO backoff in the second (and ) timeout.
• RTO remains fixed until retransmission is ackd.

42
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
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
Detecting OOO

• Sender detects OOO ACKs.
• Receiver detects OOO data packets.
• How would you classify their scheme?

45
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
OOO Data Packets

• At receiver.
• Why comparing sequence numbers doesnt 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
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
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
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
DSR Caching

• With DSR caching enabled, lower performance
  improvements.
• Claim TCP performance was better than when
  caching was off.
• Why?

51
Reliable Mutlicast in MANETs
52
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
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
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
Primitives

• rbcast (msg, group-id)
• Caller blocks until message received by
  clusterhead.
• deliver(msg)
• Notification of mssage reception by all other
  nides.

56
Entities
Gateway
Cluterhead
57
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
Protocol (Contd)

• 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 its the leaf for that message.
• Prevents loops, allows multi-path, reduces
  duplicates.
• Reverse path is recorded ACKs flow back.

59
Failures and Mobility

• Timeouts and retransmissions.
• Recovery by clusterheads gateways.

60
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
Issues

• Larger networks?
• High delays.
• Target smaller groups (10-gt100???).
• What happens when clusterheads and gateways
  fail/move?
• Satisfying liveness is tricky.
• Heavy duty protocol.
• State at nodes.
• ACKs for reliability.

62
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
Gossip Round

• Node A randomly chooses node B.
• A and B exchange information on messages they
  have and dont have.
• A and B exchange missing messages.

64
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
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
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 panon otherwise
  cached gossip.
• Why cached gossip?

67
Performance Evaluation

• Simulations using GloMoSim.
• M-AODV.
• Single source.
• Random way-point.
• Parameters range, number of nodes, and maximum
  node speed.

68
Results

• Improves packet delivery ratio.
• Overhead?
• Delay?
• Comparison with flooding?

69
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
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
CALMs State Machine
72
Evaluation

• Simulations using QualNet.
• Comparison between CALM, SRM, and (multicast)
  UDP.
• ODMRP.
• Metrics packet delivery, overhead, delay,
  goodput.

73
Results

• CALM outperforms SRM.
• UDP performs surprisingly well, except under high
  traffic loads.
• Proves need for congestion control.
• SRMs main problem is extra load caused by its
  control packets.
• Congestion control helps but still need
  relaibility.

74
Ongoing Work

• RALM reliabilitycongestion 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.
• .