Download document

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Network tap wikipedia , lookup

Airborne Networking wikipedia , lookup

Point-to-Point Protocol over Ethernet wikipedia , lookup

AppleTalk wikipedia , lookup

Net bias wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Wireless USB wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

Policies promoting wireless broadband in the United States wikipedia , lookup

Computer network wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Wireless security wikipedia , lookup

Serial digital interface wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

RapidIO wikipedia , lookup

Deep packet inspection wikipedia , lookup

UniPro protocol stack wikipedia , lookup

IEEE 1355 wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Internet protocol suite wikipedia , lookup

TCP congestion control wikipedia , lookup

Transcript
TRANSPORT PROTOCOLS FOR
WLANs and AD HOC NETWORKS
Ian F. Akyildiz
Broadband & Wireless Networking Laboratory
School of Electrical and Computer Engineering
Georgia Institute of Technology
Tel: 404-894-5141; Fax: 404-894-7883
Email: [email protected]
Web: http://www.ece.gatech.edu/research/labs/bwn
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)
 TCP’s congestion responses are triggered by
wireless packet loss but interact poorly with
wireless nets
IFA’2004
2
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
IFA’2004
3
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
IFA’2004
4
TCP Congestion Control
(cont’d)
 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
IFA’2004
5
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
IFA’2004
6
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 TCP’s 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
IFA’2004
7
Solution Categories
(Cont’d)
 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
IFA’2004
8
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
IFA’2004
– Sender uses info for bitmask of okay packets
– Ignores possibility that holes are due to
reordering
– Easier to generate and transmit acks
9
End-to-end Solution
Approaches (Cont’d)
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
IFA’2004
10
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 (ELN+Fast 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
IFA’2004
 Not as much data in pipe (harder to get 3 duplicate acks)
11
Performance Results of
E2E Protocols (Cont’d)
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
IFA’2004
12
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
IFA’2004
13
Split Connection
Approach
Connection between wireless host
MH and fixed host FH goes through
base station BS
FH-MH
FH
Fixed Host
IFA’2004
=
FH-BS
BS
Base Station
+
BS-MH
MH
Mobile Host
14
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
FH
Fixed Host
IFA’2004
BS
Base Station
MH
Mobile Host
15
I-TCP: Indirect TCP
I-TCP
TCP
MSR
MH
FH
• MH = Mobile Host
• MSR = Mobile Support Router
• FH = Fixed Host
IFA’2004
16
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
IFA’2004
17
I-TCP Basics
MH socket
MH socket
move
MH
MH
Wireless TCP
MSR-1
MSR1
fhsocket
I-TCP Handoff
MSR-1
MSR2
fhsocket
Regular TCP
MSR1
mhsocket
IFA’2004
MSR-2
MSR2
mhsocket
FH
FH socket
18
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
IFA’2004
19
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
IFA’2004
20
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
IFA’2004
21
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
IFA’2004
22
Link Layer Approaches
 LL: TCP-like behavior with cumulative acks and
retransmit granularity faster than TCP’s
 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
IFA’2004
23
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
IFA’2004
24
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
FH
IFA’2004
BS
MH
25
Snoop Protocol
Per TCP-connection state
TCP connection
application
application
application
transport
transport
transport
network
network
link
link
link
physical
physical
physical
FH
IFA’2004
BS
rxmt
wireless
network
MH
26
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
IFA’2004
– loss of the soft state affects
performance, but not correctness
27
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)
IFA’2004
28
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
IFA’2004
29
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
IFA’2004
30
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.
IFA’2004
31
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
IFA’2004
– cannot send and receive packets simultaneously
– changing mode (send or receive) incurs overhead
32
Multi-Hop Paths
May need to traverse multiple links
to reach a destination
IFA’2004
33
Multi-Hop Paths
Mobility causes route changes
IFA’2004
34
Throughput Degradation
with Route Failure
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
IFA’2004
TCP data and acks
en route discarded
35
Throughput Degradation
with Route Failure
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
No throughput
despite route repair
Larger route repair delays
especially harmful
IFA’2004
TCP data and acks
en route discarded
36
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
IFA’2004
37
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
IFA’2004
38
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
39
IFA’2004
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
IFA’2004
40
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
IFA’2004
41
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
IFA’2004
42
Design of ATCP
TCP
ATCP
TCP
IP
 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
IFA’2004
43
ATCP State Transition
Diagram
IFA’2004
44
Loss State
 Normal  Loss state transition occurs
when packet loss due to high BER channel
implied:
– ATCP sees that TCP’s RTO is about to expire OR
– ATCP receives 3 duplicate acknowledgements.
 ATCP retransmits lost packet(s) instead
of TCP.
 When new acknowledgement arrives,
IFA’2004
– ATCP passes it to TCP
– TCP exits persist mode
– State transition from Loss  Normal
45
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.
IFA’2004
46
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.
IFA’2004
47
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
IFA’2004
48
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 Int’l 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
IFA’2004
49
References
[6] J. Liu and S. Singh, "ATCP: TCP for mobile ad hoc
networks,“ IEEE JSAC, vol. 19, no. 7, pp. 13001315, 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.
IFA’2004
50