Ad Hoc Networks : Technologies and Protocols - University of ...
Ad Hoc Networks : Technologies and Protocols - University of ...
Ad Hoc Networks : Technologies and Protocols - University of ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Modified TCP 137<br />
MAC layers without changing TCP, some <strong>of</strong> the inherent problems resulting<br />
from TCP’s key design elements cannot be addressed.<br />
Finally, the third approach is to consider a transport layer design that is<br />
drawn from scratch, <strong>and</strong> tailored specifically for the characteristics <strong>of</strong><br />
an ad-hoc network. We refer to this approach as the <strong>Ad</strong>-hoc Transport<br />
Protocol approach. An obvious drawback <strong>of</strong> such an approach is that<br />
hosts in the ad-hoc network will now possess a transport layer protocol<br />
that is different from TCP. While this is not a problem in st<strong>and</strong>-alone<br />
dedicated ad-hoc networks such as those in military applications, it is an<br />
issue when ad-hoc networks are seen to “hang-<strong>of</strong>f” from the Internet. As<br />
we show later in the chapter, such an approach can provide connections<br />
with the best possible performance. Such an approach can also be used<br />
as a bench-mark for the earlier two approaches.<br />
Figure 5.5 illustrates the layers that exhibit changes in the protocol stack<br />
for the three classes <strong>of</strong> approaches. In the following sections, we present one<br />
instance <strong>of</strong> each <strong>of</strong> the above classes <strong>of</strong> approaches in detail. We also discuss<br />
other related work under the three approach categories.<br />
5.4 Modified TCP<br />
The first approach involves effecting changes to the TCP protocol with support<br />
from the underlying layers in order to mask out the problems arising from<br />
mobility. A protocol that falls in this class is the ELFN (Explicit Link Failure<br />
Notification) protocol proposed by Holl<strong>and</strong> et al. [2]. ELFN employs simple<br />
support from the network <strong>and</strong> lower layers to achieve the purpose. The bulk<br />
<strong>of</strong> the mechanisms in ELFN reside in the transport layer, <strong>and</strong> can be viewed as<br />
being additional to those already present in TCP. The objective <strong>of</strong> ELFN is to<br />
provide the TCP sender with information about link <strong>and</strong> route failures so that it<br />
can avoid responding to the failures as if congestion occurred, <strong>and</strong> consequently<br />
reduce any unnecessary degradation in performance. In the rest <strong>of</strong> the paper<br />
we refer to this approach as simply TCP-ELFN.<br />
Mechanisms<br />
The salient features <strong>of</strong> TCP-ELFN are:<br />
When a link failure occurs, the node upstream <strong>of</strong> the failure link sends<br />
back an ELFN message to the source <strong>of</strong> every TCP connection using that<br />
link. A link failure is said to occur when the MAC layer is unable to<br />
successfully deliver a packet across the link after trying for a threshold<br />
number <strong>of</strong> times. The notification message is sent by modifying DSR’s<br />
route failure message to carry a payload similar to the “host unreachable”<br />
ICMP message.