AD HOC NETWORKS

1
(No Transcript)
2
Overview of Transport Problems in WLANs

• Packet loss in wireless networks may be due to
• Bit errors
• Handoffs
• Congestion (rarely)
• Reordering (rarely, except for certain types of
  wireless nets)
• TCP assumes packet loss is due to
• Congestion
• Reordering (rarely)
• TCPs congestion responses are triggered by
  wireless packet loss but interact poorly with
  wireless nets

3
TCP Congestion Detection

• TCP assumes timeouts and duplicate acks indicate
  congestion or (rarely) packet reordering
• Timeout indicates packet or ACK was lost
• Duplicate ACKs may indicate packet reordering
• ACKs up through last successful in-order packet
  received
• Called a cumulative ACK
• After three duplicate ACKs, assume packet loss,
  not reordering
• Receipt of duplicate ACKs means some data is
  still flowing

4
TCP Congestion Control

• Basic timeout and retransmission
• If sender receives no ACK for data sent, timeout
  and retransmit
• Go To Slow Start (Exponential back-off)
• Timeout value based on mean and variance of RTT
• Congestion avoidance (really congestion
  control)
• Uses congestion window (cwnd) for more flow
  control
• Cwnd set to 1/2 of its value when congestion loss
  occurred
• Sender can send up to minimum of advertised
  window and cwnd
• Then, additive increase cwnd (at most 1 at each
  RTT)
• Careful way to approach limit of network

5
TCP Congestion Control (contd)

• Slow start used to initiate a connection or
  after a timeout
• Set cwnd to 1 segment
• At each ACK, increase cwnd by 1 segment
  (exponential increase)
• Aggressive way of building up bandwidth for flow
• Switch to congestion avoidance once cwnd is one
  half of what it was when congestion occurred
• Fast retransmit and fast recovery
• After three duplicate ACKs, assume packet loss,
  data still flowing
• Sender resends missing segment
• Set cwnd to ½ of current cwnd plus 3 segments
• For each duplicate ACK, increment cwnd by 1 (keep
  flow going)
• When new data acked, do regular congestion
  avoidance

6
Poor Interaction with TCP

• Packet loss due to channel noise or mobility
• Enter congestion control
• Slow increase of cwnd
• Bursts of packet loss and hand-offs
• Timeout
• Enter slow start (very painful!)
• Cumulative ACK scheme not good with bursty losses
• Missing data detected one segment at a time
• Duplicate ACKs take a while to cause
  retransmission
• TCP Reno may suffer coarse time-out and enter
  slow start!
• TCP New Reno still only retransmits one packet
  per RTT

7
Solution Categories

• Entirely new transport protocol
• Hard to deploy widely
• End-to-end protocol needs to be efficient on
  wired networks too
• Must implement much of TCPs flow control
• Modifications to TCP
• Maintain end-to-end semantics
• May or may not be backwards compatible
• Split-connection TCP
• Breaks end-to-end nature of protocol
• May be backwards compatible with end-hosts
• State on basestation may make handoffs slow
• Extra TCP processing at basestation

8
Solution Categories (Contd)

• Link-layer protocols
• Invisible to higher-level protocols
• Does not break higher-level end-to-end semantics
• May not shield sender completely from packet loss
• May adversely interact with higher-level
  mechanisms
• May adversely affect delay-sensitive applications
• Snoop protocol
• Does not break end-to-end semantics
• Like a LL protocol, does not completely shield
  sender
• Only soft state at base station not essential
  for correctness

9
End-to-end Solution Approaches

• Sender is aware of the existence of wireless
  hops.
• E2E (Reno) no support for partial ACKs
• E2E-NewReno partial ACKs allow further packet
  retransmissions
• E2E-Selective Acknowledgments (SACK) ACK
  describes 3 received non-contiguous ranges
• E2E-SMART cumulative ACK with sequence of
  packet causing ACK
• Sender uses info for bitmask of okay packets
• Ignores possibility that holes are due to
  reordering
• Easier to generate and transmit acks

10
End-to-end Solution Approaches (Contd)

• E2E-ELN Explicit Loss Notification
• Receiver gets corrupted packet
• Instead of dropping it, TCP gets it, generates
  ELN message with duplicate ACK
• Entire packet dropped?
• Base station generates ELN messages to sender
  with ACK stream

11
Performance Results of E2E Protocols

• E2E (Reno) coarse-grained timeouts really hurt
• Throughput less than 50 of maximum in local area
• Throughput of less than 25 in wide area
• E2E-New Reno avoiding timeouts helps
• Throughput 10-25 better in LAN
• Throughput twice as good in WAN
• ELN techniques avoid shrinking congestion window
• Over two times better than E2E
• E2E-ELN-RXMT (ELNFast Retransmissions) only a
  little better than E2E-ELN
• Enough data in pipe usually to get fast
  retransmit from ELN
• Bigger difference with smaller buffer size
• Not as much data in pipe (harder to get 3
  duplicate acks)

12
Performance Results of E2E Protocols (Contd)

• E2E selective acks (SACK)
• Over twice as good as E2E
• Not as good as best LL schemes (10 worse on LAN,
  35 worse in WAN)
• Problem is still shrinkage of congestion window

13
Split-connection Protocols

• Goal to hide any non-congestion-related losses
  from the TCP sender.
• Attempt to isolate TCP source from wireless
  losses
• TCP connection is split between a sender and
  receiver into two separate connections at the
  base station
• TCP connection over wired link
• Specialized protocol over wireless link.
• TCP sender over wireless link performs all
  retransmissions in response to losses
• SPLIT (I-TCP) uses TCP Reno over wireless link
• SPLIT-SMART uses SMART-based selective acks

14
Split Connection Approach

• Connection between wireless host MH and fixed
  host FH goes through base station BS
• FH-MH FH-BS BS-MH

FH
MH
BS
Fixed Host
Base Station
Mobile Host
15
Split Connection Approach

• Split connection results in independent flow
  control for the two parts
• Flow/error control protocols, packet size,
  time-outs, may be different for each part

16
I-TCP Indirect TCP
I-TCP
TCP
MSR
MH
FH

• MH Mobile Host
• MSR Mobile Support Router
• FH Fixed Host

17
Indirect-TCP Protocol

• Different flow control and congestion control for
  wireless and wired links
• Separate transport protocol supports
  disconnections, moves and other wireless related
  features
• Faster reaction to mobility due to proximity
  between MSR and MH.
• MSR manages much of the overhead

18
I-TCP Basics
move
Wireless TCP
I-TCP Handoff
MSR1 fhsocket
MSR2 fhsocket
Regular TCP
MSR-2
MSR1 mhsocket
MSR2 mhsocket
FH socket
19
I-TCP

• Built on top of a mobile IP
• MSR acts a proxy to the MH
• it fakes an image of the MH and hands this to a
  new MSR during cell switches
• Assuming no MSR failures and indefinite MH
  disconnection, I-TCP does not compromise
  end-to-end reliability.
• Well-suited for throughput intensive applications

20
Split Connection Approach

• Advantages
• Simple Implementation
• Backward compatible to TCP fixed hosts
• FH unaware of MSRs
• Separates flow and congestion control of the
  wireless and wired link
• Can optimize FH-MSR connection independently -
  different protocols, MTUs
• Can support notifications that can be used by
  link and location aware applications

21
Split Connection Approach

• Disadvantages
• Violation of end-to-end semantics
• MSR maintains state
• MSR failure can cause connection loss
• Hand-off latency increases due to state transfer
• Unless optimized, extra copying of data at MSR

22
Performance of Split Approaches

• SPLIT
• Wired goodput 100 since no retransmissions there
• Eventually stalls when wireless link times out
• Buffer space limited at base station
• SPLIT-SMART
• Throughput better than SPLIT (at least twice as
  good)
• Better performance of wireless link avoids
  holding up wired links as much
• Split connections not as effective as TCP-aware
  LL protocol, which also avoids splitting the
  connection

23
Link Layer Approaches

• LL TCP-like behavior with cumulative acks and
  retransmit granularity faster than TCPs
• LL-SMART addition of selective retransmissions
• Cumulative ack with sequence of of packet
  causing ack
• LL-TCP-AWARE Snoop protocol
• At base station cache segments
• Detect and suppress duplicate acks
• Retransmit lost segments locally
• LL-SMART-TCP-AWARE Combination of selective acks
  and duplicate ack suppression

24
Snoop Protocol

• Design Goals
• Improved Performance
• No change to TCP at fixed hosts
• No violation of end-to-end TCP semantics
• No recompiling/relinking of existing applications

25
Snoop Protocol

• Buffers data packets at the base station BS
• to allow link layer retransmission
• When dupacks received by BS from MH, retransmit
  on wireless link, if packet present in buffer
• Prevents fast retransmit at TCP sender FH by
  dropping the dupacks at BS

26
Snoop Protocol
27
Snoop Protocol

• Advantages
• High throughput can be achieved
• performance further improved using selective acks
• Local recovery from wireless losses
• Fast retransmit not triggered at sender despite
  out-of-order link layer delivery
• End-to-end semantics retained
• Soft state at base station
• loss of the soft state affects performance, but
  not correctness

28
Snoop Protocol

• Disadvantages
• Link layer at base station needs to be TCP-aware
• Not useful if TCP headers are encrypted (IPsec)
• Cannot be used if TCP data and TCP acks traverse
  different paths (both do not go through the base
  station)

29
Link Layer Approaches Results

• Simple retransmission at link layer helps, but
  not totally
• Combination of selective acks and duplicate
  suppression is best
• Real problem is link layers that allow
  out-of-order packet delivery, triggering
  duplicate acks, fast retransmission and
  congestion avoidance in TCP
• Overall, want to avoid triggering TCP congestion
  handling techniques

30
Summary

• Good TCP-aware LL shields sender from duplicate
  acks
• Avoids redundant retransmissions by sender and
  base station
• Adding selective acks helps a lot with bursty
  errors
• Split connection with standard TCP shields sender
  from losses, but poor wireless link still causes
  sender to stall
• Adding selective acks over wireless link helps a
  lot
• Still not as good as local LL improvement
• E2E schemes with selective acks help a lot
• Still not as good as best LL schemes
• Explicit loss E2E schemes help (avoid shrinking
  congestion window) but should be combined with
  SACK for multiple packet losses

31
Summary

• TCP-aware link-layer protocol (Snoop) with
  selective acknowledgments performs the best
• Split-connection approaches is not a requirement
  for good performance.
• Selective acknowledgment is very useful in lossy
  links, especially for burst losses.
• Explicit Loss Notification is worth to try.

32
Overview of Transport Problems in Ad Hoc Networks

• Effect of route reconstruction/repair
• Effect of network partitioning/merging,
  multi-path routing
• Sender mistakes the delay of ACK arrival and
  increases RTT as a sign of congestion
• Sender begins to reduce window size
• High bit error rates
• problem amplified with multiple hops
• Out-of-order packet delivery
• frequent route changes may cause out-of-order
  delivery
• Half-duplex radios
• cannot send and receive packets simultaneously
• changing mode (send or receive) incurs overhead

33
Multi-Hop Paths

• May need to traverse multiple links to reach a
  destination

34
Multi-Hop Paths

• Mobility causes route changes

35
Throughput Degradation with Route Failure
36
Throughput Degradation with Route Failure
37
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 time-outs

38
Impact of MAC - Delay Variability

• As wireless medium is shared between multiple
  sources, the round-trip delay is variable
• Also, on slow wireless networks, delay is large
• made 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

39
Out-of-Order Packet Delivery

• Route changes may result in out-of-order (OOO)
  delivery
• Significantly OOO delivery confuses TCP,
  triggering fast retransmit
• Potential solutions
• Avoid OOO delivery by ordering packets before
  delivering to IP layer
• can result in variable delay
• turn off fast retransmit
• can result in poor performance in presence of
  congestion

40
How to Solve?

• 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

41
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

42
ATCP Ad Hoc TCP

• ATCP ad hoc TCP
• Considers packet loss due to
• Bit Errors
• Route Re-computation
• Network Partitioning
• Multi-path Routing
• Maintains TCP congestion control behaviour
• Is compatible with TCP standard

43
Design of ATCP

• Transparent layer between standard TCP and IP.
• Standard TCP is unmodified.
• Nodes with and without ATCP can interoperate.
• Only used on sender-side.
• Monitors TCP and Network state based on Explicit
  Congestion Notification (ECN) and Internet
  Control Management Protocol (ICMP) messages

44
ATCP State Transition Diagram
45
Loss State

• Normal ? Loss state transition occurs when packet
  loss due to high BER channel implied
• ATCP sees that TCPs RTO is about to expire OR
• ATCP receives 3 duplicate acknowledgements.
• ATCP retransmits lost packet(s) instead of TCP.
• When new acknowledgement arrives,
• ATCP passes it to TCP
• TCP exits persist mode
• State transition from Loss ? Normal

46
Congested State

• Normal ? Congested state transition occurs when
  sender receives TCP acknowledgement with explicit
  congestion notification (ECN) bit set.
• ECN bit set in TCP acknowledgement when router
  detects congestion (instead of dropping the
  packet).
• ATCP does nothing in congested state
• Ignore imminent RTO and
• Ignore duplicate acknowledgements
• TCP would behave as normal
• When TCP transmits a new packet, ATCP transitions
  from Congested ? Normal.

47
Disconnected State

• Normal ? Disconnected state transition occurs
  when ICMP Destination Unreachable packet
  received.
• ICMP Destination Unreachable packet generated by
  network in response to a packet being sent to an
  unreachable node.
• TCP continuously transmits probe packets.
• When acknowledgement to probe packet is received,
  this means destination node is no longer
  disconnected.

48
Summary

• Much work on routing in ad hoc networks
• Some recent work on TCP for ad hoc networks
• Need to investigate many issues
• MAC-TCP interaction
• routing-TCP interaction
• impact of route changes on window size, RTO
  choice after move

49
References

• 1 Hari Balakrishnan, Srinivasan Seshan and
  Randy H.Katz, Improving Reliable Transport and
  Handoff Performance in Cellular Wireless
  Networks, ACM Wireless Networks, May 1995
• 2 Hari Balakrishnan, Venkata N. Padmanabhan,
  Srinivasan Seshan and Randy H.Katz, A Comparison
  of Mechanisms for Improving TCP Performance over
  Wireless Links, ACM SIGCOMM 1996.
• 3 A.Bakre and B.R.Badrinath, I-TCP Indirect
  TCP for Mobile Hosts,Proc. 15th Intl Conf. on
  Distributed Computing Systems, May 1995
• 4 A.Bakre and B.R.Badrinath, Implementation
  and Performance Evaluation of Indirect TCP, IEEE
  Transactions on Computers, March 1997
• 5 RFC 2001 TCP Slow Start, Congestion
  Avoidance, Fast Retransmit and Fast Recovery

50
References

• 6 J. Liu and S. Singh, "ATCP TCP for mobile ad
  hoc networks, IEEE JSAC, vol. 19, no. 7, pp.
  1300-1315, July 2001.
• 7 K. Sundaresan, V. Anantharaman, H.-Y. Hsieh,
  and R. Sivakumar, ATP A Reliable Transport
  Protocol for Ad-hoc Networks." Proc. ACM MOBIHOC
  2003, Annapolis, MD USA, June 2003.