Download - Tcp Over Adhoc Networks
-
8/12/2019 Tcp Over Adhoc Networks
1/69
TCP Over Wireless Ad-hocNetworks
-
8/12/2019 Tcp Over Adhoc Networks
2/69
Vinay Sridhara
Nagendra Subramanya
-
8/12/2019 Tcp Over Adhoc Networks
3/69
In wired LANs, an address is equivalent to a
physical location. This is implicitly assumed in the
design of the wired LANs. In wireless, the
addressable unit is the station. The station is a
message destination, but not a fixed location.
Use a medium that has neither absolute nor readily
observable boundaries outside of which stations
with conformant physical transceivers are known
to be unable to receive network frames
Wired Vs Wireless
-
8/12/2019 Tcp Over Adhoc Networks
4/69
Continued..
They are unprotected from outside signals . Have dynamic topologies.
They lack full connectivity and therefore the
assumption that one station can hear every otherstation is invalid.
They have time varying and asymmetric
propagation properties.
-
8/12/2019 Tcp Over Adhoc Networks
5/69
802.11 Main purpose is to provide the MAC and physical
layer specification for wireless. Permits the operation of an IEEE 802.11
conformant device within a wireless local area
network that may coexist with multipleoverlapping IEEE 802.11 conformant devices.
Describes the requirements and procedures toprovide privacy of user information being
transferred over the wireless medium andauthentication of IEEE 802.11 conformantdevices.
-
8/12/2019 Tcp Over Adhoc Networks
6/69
802.11 in ISO/OSI Model.
-
8/12/2019 Tcp Over Adhoc Networks
7/69
A few terminologies of 802.11
STA Any mobile, portableor stationary terminal.
BSS Basic service set.
The BSS is an entity which
consists of several mobile
stations that can interact with
each other.
STA1
STA2
STA1
STA2
BSS1
BSS2
802.11 Components
-
8/12/2019 Tcp Over Adhoc Networks
8/69
Continued. A BSS maybe comprised of only two mobile
stations.
This is called a IBSS (Independent Basic Service
Set).
This is the one that is called Ad Hoc Networks.
A network composed solely of stations within mutual
communication range of each other via the wireless
medium
network is typically created in a spontaneous manner The principal distinguishing char of an Ad Hoc network
is its limited temporal and spatial extent
-
8/12/2019 Tcp Over Adhoc Networks
9/69
Continued. Instead of existing
independently,
multiple BSSs mayform a network.
The architectural
component used tointerconnect BSSs isthe Distributionsystem (DS).
The access points arethe stations used toconnect BSSs to DS.
-
8/12/2019 Tcp Over Adhoc Networks
10/69
Continued. BSSs may generally
overlap to provide
continuous coveragein physical volume.
The BSSs could be
physically disjoint.
Logically there is nolimit to the distance
between BSSs.
STA1 STA-C STA1
STA1 STA2
STA2STA1
-
8/12/2019 Tcp Over Adhoc Networks
11/69
Continued.
ESS - The DS and the
BSSs allow the IEEE
802.11 to create a wirelessnetwork of arbitrary size
and complexity.
Stations within an ESS
may communicate and
Mobile stations may move
from one BSS to anothertransparently to LLC.
-
8/12/2019 Tcp Over Adhoc Networks
12/69
Extended Service Set
The stations communicate to Access pointswhich are part of a Distribution System
Access point serves the stations in a BSS
The set of BSSs are called Extended Service
Set (ESS)
-
8/12/2019 Tcp Over Adhoc Networks
13/69
Communication with external world
Portal Is the logicalpoint at which the MSDUs
enter and leave the IEEE802.11 network.
This portal provideslogical integrationbetween the IEEE 802.11architecture and theexisting wired LANs
The stations act as bothAP and portal when theDS is a wired network.
-
8/12/2019 Tcp Over Adhoc Networks
14/69
The Big Picture
-
8/12/2019 Tcp Over Adhoc Networks
15/69
Services
The services provided by the 802.11 are dividedinto two.
Those that are part of every STA, called Station
services Authentication
De-Authentication
Privacy
MSDU Delivery
The services provided by the DS are known as the
Distribution system service.
Association
Disassociation
Distribution
Integration
Reassociation
-
8/12/2019 Tcp Over Adhoc Networks
16/69
MAC layer Services Services provided by the MAC layer
Security Services Security is provided by the WEP (Wired equivalent privacy)
The security provided is limited to Station-to-Station exchangeof data
The privacy service offered by the IEEE 802.11 WEP is theencryption of the MSDU
The security services provided are Confidentiality
Authentication
Access control in conjunction with layer management.
-
8/12/2019 Tcp Over Adhoc Networks
17/69
Continued.
Asynchronous data services
Provided by the following three primitives.
MA-UNITDATA.request generated by the LLC when anMSDU is to transmitted to the peer LLC. The format is asshow below.
MA-UNITDATA.request{
Source address,
Destination address,
Routing information,Data,
Priority,
Service class
}
-
8/12/2019 Tcp Over Adhoc Networks
18/69
MA-UNITDATA.indication generated by the MAC sublayerentity to indicate to the LLC the arrival of a MSDU.
MA-UNITDATA.indication
{
Source address,
Destination address,
Routing information,
Data,
Reception status,
Priority,
Service class
}
-
8/12/2019 Tcp Over Adhoc Networks
19/69
MA-UNITDATA-STATUS.indication - provides the LLC
sublayer with status information of the corresponding MA-
UNITDATA.request primitive.
MA-UNITDATA-STATUS.indication
{
Source address,
Destination address,
Transmission status,
Provided priority,Provided service class
}
-
8/12/2019 Tcp Over Adhoc Networks
20/69
MAC header
The four address fields in the MAC header are used to
indicate the BSSID, Source address, destination address,transmitting station address and the receiving stationaddress.
The frame control field has the following format
-
8/12/2019 Tcp Over Adhoc Networks
21/69
Collision Avoidance - 802.11 802.11 uses a protocol scheme know as carrier-sense,
multiple access, collision avoidance (CSMA/CA).
Avoidance scheme is used because it is difficult to detect
collisions in the RF media.
Hence is interoperates with the physical layer by sampling
the transmitted energy over the medium transmitting data. The physical layer uses an algorithm for clear channel
assessment (CCA) to determine if the channel is clear.
If the received signal is below a certain threshold the
channel is declared clear.
-
8/12/2019 Tcp Over Adhoc Networks
22/69
Why Do We Need RTS/CTS ? Used because of the Hidden terminal problem.
It occurs when there is a station in a service setthat cannot detect the transmission of another
station, and thus cannot detect that the media is
busy
Station C
Station A
Station B
-
8/12/2019 Tcp Over Adhoc Networks
23/69
What Does RTS/CTS Do?
Communications is established when one of thewireless nodes sends a short message RTS frame.
The message duration is known as the networkallocation vector (NAV). This alerts to back offduring the transmission time.
The receiving station issues a CTS frame whichechoes the senders address and the NAV.
If the CTS frame is not received, it is assumed thata collision occurred and the RTS process startsover.
-
8/12/2019 Tcp Over Adhoc Networks
24/69
Characteristics of Wireless Networks
Limited bandwidth
High latencies and bit-error rates
Mobility
-
8/12/2019 Tcp Over Adhoc Networks
25/69
Difference between General wireless
networks and Ad-Hoc Networks ?
Absence of a central base station
Frequent route re-computation
Network partitions
Multi-path routing algorithms
-
8/12/2019 Tcp Over Adhoc Networks
26/69
What is an Ad-Hoc Network?
AD-HOC network is a collection of mobile nodes with wireless
network infrastructure capable of organizing themselves into a
temporary network without the aid of any centralized network
manager.
According to the IETF definition, a mobile Ad Hoc network is an
autonomous system of mobile routers (and associated hosts) connected
by wireless links--the union of which form an arbitrary graph.
-
8/12/2019 Tcp Over Adhoc Networks
27/69
AD-HOC Networks
SOURCE
DESTINATION
-
8/12/2019 Tcp Over Adhoc Networks
28/69
Implications of using NormalTCP over Ad-Hoc Wireless N/W
TCP does not distinguish between congestion andpacket loss due to transmission errors and route
failures
This inability results in performance degradation
in ad hoc networks
-
8/12/2019 Tcp Over Adhoc Networks
29/69
Implications of using NormalTCP over Ad-Hoc Wireless N/W
Route re-computation takes a finite amount of time
During this time no packet can reach the destination
through the existing route
Packets and ACKs may get queued and possibly dropped
In turn leads to timeouts at the source, which ismisinterpreted as congestion
-
8/12/2019 Tcp Over Adhoc Networks
30/69
Consequences
Source retransmits unACKed packets
Invokes congestion control
Enters slow start recovery
These are undesirable because?
Why retransmit when there is no route
Retransmission wastes power and bandwidth
Low throughput as a result of slow start recovery after route restoration
(this is actually desirable. Why?)
-
8/12/2019 Tcp Over Adhoc Networks
31/69
Why use TCP at all in such cases ?
For seamless portability to applications like file
transfer, e-mail and browsers which use standard
TCP
-
8/12/2019 Tcp Over Adhoc Networks
32/69
-
8/12/2019 Tcp Over Adhoc Networks
33/69
Indirect TCP (I-TCP)
Connection between end points split into separate connections
+ No need of changes in TCP on wired hosts
+ Transmission errors on wireless link not propagated to wired network
+ Different optimal transport layer protocol between BS and MH
- Loss of E2E semantics of TCP
- Increased hand-off latency
- Copying overhead
-
8/12/2019 Tcp Over Adhoc Networks
34/69
Snoop TCP
BS caches packets from senderPerforms local re-transmissions
+ Preserves E2E TCP semantics
+ Only BS needs to be changed
- Doesnt isolate behavior of wireless link as good as I-TCP
- MH may need to be modified to accept NACKs
- Snooping and caching may fail if E2E encryption schemes are used
-
8/12/2019 Tcp Over Adhoc Networks
35/69
M-TCP
Same as I-TCP, but the BS is known as SH
SH holds back ACK to the last byte
Uses this ACK to freeze the sender when disconnection is detected
+ Maintains E2E semantics
+ Avoids useless re-transmissions and slow-starts
+ SH doesnt buffer data
- Needs a bandwidth manager to implement fair sharing over the wireless link
-
8/12/2019 Tcp Over Adhoc Networks
36/69
Freeze-TCP
The client freezes the sender when it detects possible hand-
off or predicts a temporary disconnection
+ No need of base station
+ Only mobile clients TCP needs to be changed
+ Can be used with encrypted data
- MAC has to detect future interruptions
- Freezing fails when encryption scheme uses timestamps
- Re-transmission restarted with old CWND
-
8/12/2019 Tcp Over Adhoc Networks
37/69
Network state after a while
SOURCE
DESTINATION
X
-
8/12/2019 Tcp Over Adhoc Networks
38/69
TCP-Feedback (TCP-F)
K. Chandran, S. Raghunathan, S. Venkatesan and R.
Prakash
-
8/12/2019 Tcp Over Adhoc Networks
39/69
TCP-F: Introduction
ECN is not used. Why?
Instead uses Route Failure Notification (RFN)
packet to inform source when route is disrupted
And Route Reestablishment Notification (RRN)
packet informs the source when route isreestablished
-
8/12/2019 Tcp Over Adhoc Networks
40/69
TCP-F: Protocol
Failure Point (intermediate node) detects the routedisruption
Explicitly sends RFN to source and records theevent
Each intermediate node that receives the RFN:
Invalidates the particular route
If it knows of an alternate route, that route is used forfurther communication and RFN is discarded
Else, RFN is propagated towards source
-
8/12/2019 Tcp Over Adhoc Networks
41/69
TCP-F: Protocol (contd.)
On receiving RFN, source goes into snooze state
-
8/12/2019 Tcp Over Adhoc Networks
42/69
TCP-F: Protocol (contd.)
Source when in snooze state
Stops sending further packets
All existing timers are marked invalid
Send window and other state variables (RTO, etc) are frozen
Starts a route failure timer whose timeout = worst case route
reestablishment time. Why?
Stays in this state till it receives an RRN packet
-
8/12/2019 Tcp Over Adhoc Networks
43/69
TCP-F: Protocol (contd.)
One of the intermediate nodes that had previously
forwarded RFN learns about a new route Sends an RRN to the source
Further RRNs received by this node for the same source-
destination pair are discarded
Other nodes simply forward RRN towards the source
Source on receiving RRN Changes to active state
Flushes out all unACKed packets in its current window
-
8/12/2019 Tcp Over Adhoc Networks
44/69
TCP-F: Conclusion
Communication resumes at the same rate as before theroute failure occurred There is no unnecessary loss of throughput
Is this ok?
Use of an additional packet RRN. Is it really needed?
Simulation environment
Based on a simple one-hop network Links failed/recovered according to an exponential model
Routing protocol was not simulated
-
8/12/2019 Tcp Over Adhoc Networks
45/69
TCP-F: Conclusion
Overhead on routers
Detect route failures and reestablishments
Provide feedback to the source
Store the source id after forwarding an RFN so that it
can send an RRN on finding a route
The paper does not discuss about multiple flows
Enhancements
Buffering at intermediate nodes
-
8/12/2019 Tcp Over Adhoc Networks
46/69
TCP with Explicit Link FailureNotification (ELFN)
G. Holland and N.G. Holland and N. VaidyaVaidya
-
8/12/2019 Tcp Over Adhoc Networks
47/69
ELFN: Introduction
DSR complicates the situation stale routes may be
cached and propagated
Throughput is degraded
Turning of caching works only with single TCP connection
What if there are more sources?
-
8/12/2019 Tcp Over Adhoc Networks
48/69
ELFN
Similar to TCP-F
Expected throughput throughput of a static wireless
network
ELFN is piggy-backed to DSRs route failure message
ELFN has a payload similar to that of host unreachableICMP message
-
8/12/2019 Tcp Over Adhoc Networks
49/69
ELFN: Protocol
TCP sender receives ELFN
Disables congestion control mechanism, enters stand-by
mode
Sends probes
On receiving an ACK for a probe, leaves stand-by mode
-
8/12/2019 Tcp Over Adhoc Networks
50/69
ELFN: Variations
Time interval between probe packets
greater it is, slower is the route discovery
smaller it is, causes congestion
best would be to have it as a function of RTT
-
8/12/2019 Tcp Over Adhoc Networks
51/69
ELFN: Variations
Adjusting CWND and/or RTO after route restoration no changes
CWND = 1
RTO = default initial value and CWND = 1
Resetting RTO degrades throughput due to frequent routebreaks and ARPs tendency to silently drop packets
CWND = 1 caused no significant change, because optimalwindow is relatively small Things have improved now bandwidth/delay products are larger
-
8/12/2019 Tcp Over Adhoc Networks
52/69
ELFN: Variations
Choice of probe packet First packet in congestion window
Lowest sequence numbered packet that was lost
indicated by ELFN
If forward and reverse routes are different , both
approaches are same
-
8/12/2019 Tcp Over Adhoc Networks
53/69
ELFN: Limitations
Base TCP outperforms TCP+ELFN on static networks
Why? Slow-start results in high network buffer utilization
Causes large RTT => large RTOs => long timeouts =>badthroughput
Abrupt reduction of CWND to 1 => several RTTs before sender
reaches avoidance phase
CWND worth of data lost due to route failures. What if smallernetwork buffers are used?
-
8/12/2019 Tcp Over Adhoc Networks
54/69
ELFN: Limitations
Channel characteristics of ad hoc networks Available bandwidth is greatly reduced
Packets from same flow contend with each other
Every node gets a share of the channel based on the fairnessproperties of the MAC layer
In static networks, channel contention results in frequentfalse route error messages
Time wasted in computing new route => throughputdegrades
-
8/12/2019 Tcp Over Adhoc Networks
55/69
ELFN: Limitations
Even a single flow can create enough contention
Contention among data packets
Contention caused by ACK packets
MAC contention algorithm
TCPs saw-tooth behavior during congestion avoidance
In mobile scenario, there will be lot of high priority routingpackets in the network resulting in congestion
-
8/12/2019 Tcp Over Adhoc Networks
56/69
ELFN: Limitations
Large number of routing packets force TCP packets to
reside in network buffers for long intervals
Data packets can get delayed or dropped due to change in
network configuration.
Queue management is thus very critical
-
8/12/2019 Tcp Over Adhoc Networks
57/69
ELFN: Limitation Fairness Issues
One flow reduces its CWND, allowing another to maintain
a larger window and send more packets
Short range flows have fewer timeouts and a larger CWNDcausing them to contend more aggressively.
Both ELFN and plain TCP result in unfair networkresource distribution due to congestion at intermediate
hops.
Rate control mechanisms are more suited for ad hocnetworks.
-
8/12/2019 Tcp Over Adhoc Networks
58/69
ELFN: Rate Control Methods
End-to-end rate control
could depend on network feedback
leads to large buffer buildups
longer flows reduce their sending rate when congestion is observedin any part of the path
takes a few RTTs to adjust the outgoing rate
intermediate nodes dont store state of flows
-
8/12/2019 Tcp Over Adhoc Networks
59/69
ELFN: Rate Control Methods
Hop-by-hop rate control
each node individually controls the outgoing rates of all flows
prevents buffers from getting large
congestion causes only the immediate hop to reduce sending rate
more responsive to changes in connectivity , congestion or number of
contending nodes
can reduce number of packets stored at a disconnected node in a staleroute
-
8/12/2019 Tcp Over Adhoc Networks
60/69
ATCP TCP for Mobile Ad HocNetworks
J. Liu and S. Singh
-
8/12/2019 Tcp Over Adhoc Networks
61/69
ATCP TCP for Ad Hoc Networks
Thin layer between TCP and IP
Treats loss due to congestion and medium differently
Functions efficiently even with high bit error rates
Handles network partition gracefully
Maintains end-to-end TCP semantics ?
-
8/12/2019 Tcp Over Adhoc Networks
62/69
Modes of Operation
ATCP
Normal
Congested
Loss
Disconnected
TCP Depending on its mode of operation ATCP sets TCP in one of the
following modes
Normal
Congested
Persist
-
8/12/2019 Tcp Over Adhoc Networks
63/69
-
8/12/2019 Tcp Over Adhoc Networks
64/69
Comparison with ELFN andTCP-F
Old CWND usedOne of the variations
suggests changing CWND
to 1
Reset for each new routeCWND
Not handledNot handledSender invokes
congestion control on
receiving an ECN
Congestion
Not handledNot handledATCP reorders packets so
that TCP does not
generate duplicates
Packet reordering
TCP-F freezes sender
state
ELFN freezes sender stateICMP Destination
Unreachable puts sender
into persist mode
Network Partition and
Route Changes
Not handledNot handledATCP retransmits, TCP
does not invoke
congestion control
Packet loss due to high bit
error rate
TCP-FELFNATCPEvent
-
8/12/2019 Tcp Over Adhoc Networks
65/69
Some Issues
ECNs may not reach the sender
Sender keeps re-transmitting, congesting the network
further
When would this happen?
Possible solution
-
8/12/2019 Tcp Over Adhoc Networks
66/69
Issues
RTO generally indicates congestion more than
packet loss due to high BER
Why?
-
8/12/2019 Tcp Over Adhoc Networks
67/69
References
IEEE 802.11 Specifications
H. Balakrishnan, V. N. Padmanabhan, S. Seshan and R. Katz, A Comparison
of Mechanisms for Improving TCP Performance over Wireless Links,
IEEE/ACM Transactions on Networking, Vol. 5, No. 6, December 1997.
K. Brown and S. Singh, M-TCP: TCP for Mobile Cellular Networks, ACM
Computer Communications Review, 1997.
T. Goff et al., Freeze-TCP: A True End-to-End TCP Enhancement mechanism
for Mobile environments, Proc. IEEE INFOCOM, 2000.
-
8/12/2019 Tcp Over Adhoc Networks
68/69
References
K. Chandran, S. Raghunathan, S. Venkatesan and R. Prakash, A Feedback-
Based Scheme for Improving TCP Performance in Ad Hoc WirelessNetworks, Proc. IEEE ICDCS, Amsterdam, The Netherlands, May 1998.
G. Holland and Nitin H. Vaidya, Analysis of TCP Performance over Mobile
Ad Hoc Networks, Proc. IEEE MOBICOM, Seattle, Aug 1999.
J. Monks, P. Sinha and V. Bharghavan, Limitations of TCP-ELFN for Ad
hoc Networks, MOMUC, Tokyo, Japan, October 2000.
J. Liu, S. Singh, ATCP: TCP for mobile Ad Hoc networks, IEEE Journal ofSelected Areas in Communications, July 2001.
-
8/12/2019 Tcp Over Adhoc Networks
69/69
Thank you