05.01.2013 Views

Ad Hoc Networks : Technologies and Protocols - University of ...

Ad Hoc Networks : Technologies and Protocols - University of ...

Ad Hoc Networks : Technologies and Protocols - University of ...

SHOW MORE
SHOW LESS

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!