Ad Hoc Networks : Technologies and Protocols - University of ...
Ad Hoc Networks : Technologies and Protocols - University of ...
Ad Hoc Networks : Technologies and Protocols - University of ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
TCP-aware Cross-layered Solutions 143<br />
currently being used. This would prevent the retransmission timers at<br />
the TCP sender from firing out during route computations <strong>and</strong> leading to<br />
a degradation in throughput or in the worst case resulting in connection<br />
stalls due to repeated timeouts. The prediction mechanism is merely a<br />
heuristic <strong>and</strong> can fail either by predicting link failure wrongly or failing<br />
to predict an actual link failure. In the first scenario, the throughput <strong>of</strong> the<br />
corresponding connection is left unaffected since the source will continue<br />
to use the current path until a new alternate path is computed or the current<br />
path fails. Since the current path will not fail, the source will switch its<br />
connection only upon the recomputation <strong>of</strong> an alternate path. Further, if<br />
the current path is the best path, it will again be recomputed as the alternate<br />
path thus preventing any sub-optimality because <strong>of</strong> wrong predictions.<br />
The drawback <strong>of</strong> wrong predictions is the route recomputation overhead<br />
that is incurred. On the other h<strong>and</strong>, if a route failure is not predicted<br />
successfully, the performance <strong>of</strong> the connection will be only as bad as<br />
the scenario wherein no prediction mechanism is employed.<br />
Finally, the prediction mechanism will successfully predict only mobility<br />
related route failures. Other possibilities such as congestion based route<br />
failures will not be captured by the prediction mechanism <strong>and</strong> will trigger<br />
normal route errors as usual.<br />
Proactive Route Errors (PRE):<br />
If a link failure occurs either due to congestion, or due to mobility but<br />
has not been successfully predicted by the prediction mechanism, the<br />
third mechanism in Atra tries to minimize the latency involved in the<br />
route failure information being carried to the source(s) using the link <strong>of</strong><br />
failure. In the default set-up, DSR will issue a route error to only the<br />
source <strong>of</strong> the packet that triggered the link failure detection at the MAC<br />
layer. If multiple sources are using the same link, packets will have to<br />
arrive from them at that node before route errors will be sent back to<br />
them increasing the latency between the link failure detection <strong>and</strong> the<br />
time at which the sources are informed. This latency is further inflated<br />
because subsequently arriving packets from other sources will have to<br />
go through the MAC failure detection time cycle before the link failure<br />
is inferred. However, in Atra each node maintains a cache <strong>of</strong> the source<br />
identifiers <strong>of</strong> TCP connections that have used a particular link in the past<br />
T seconds. When a link failure is detected, all sources that have used<br />
the link in the past T seconds are informed about the link failure through<br />
normal route errors. This reduces the latency involved in the route failure<br />
information delivery which consequently reduces the number <strong>of</strong> losses<br />
<strong>and</strong> also triggers earlier alternate route computations.