Subject: Call for Comments on Issues ID

From: [email-masked] (Joseph P. Macker)
Date: Wed, 11 Feb 1998 14:18:28 -0500

All:

I am asking for final comments on the issues ID within the next two weeks.

"Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and
Evaluation Considerations"

ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-issues-00.txt

As discussed in DC, we will subsequently put this forward as an
informational RFC.

-Joe

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 11 Feb 1998 15:15:01 -0500

Joe,

>From a general perspective, it seems that existing proposals and 
related work for establishing routes across the ad-hoc network can 
be described as reactive or proactive.  the former relating to the 
on-demand establishment of a route when it is needed. the latter 
example being in line with how unicast routing works in today's internet 
(the a priori distribution of routing information).  and of course,
there is the hybrid of the two as realized by ZRP.

now perhaps i missed something inthe draft or in previous discussions,
but one issue that seemed to be missing is the impact on potential data 
loss caused by reactive algorithms.  by this i mean that if the depth
of the ad-hoc network (number of hops from edge to edge) is great, or
the algorithm contains a number of iterative steps to generate a route
from scratch, then it would seem some amount of packet loss can be
experienced at the first ingress router.  further, it would seem that
this type of packet loss (i.e., the first few packets in a session)
could be either inconsequential or quite disruptive depending on the
application used.

thoughts ?

-ken

---

From: Zygmunt Haas <[email-masked]>
Date: Thu, 12 Feb 1998 13:46:41 -0500 (EST)

> could be either inconsequential or quite disruptive depending on the

Hmmm. I guess it really depends on how the algorithm is implemented. In
the ZRP "philosophy" the route discovery is done by a control (not data)
packets. Data packets are sent through a route that is already discovered.
Thus, there should not be any packet loss due to the initial route
discovery. Some additional delay - yes, but packet loss - no.

Another related issue is the loss of packets due to a break in path (local
repair and route maintenance). This surely should be investigated more 
carefully. The "classical" TCP congestion control problem in mobile networks 
come in mind here.

Zygmunt.
===--=-=
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas             tel: +1-607-255-3454
Wireless Networks Laboratory
323 Frank Rhodes Hall             fax: +1-607-255-9072
School of Electrical Engineering  
Cornell University                e-mail: [email-masked]
Ithaca, N.Y. 14853                
U.S.A                             http://www.ee.cornell.edu/~haas/wnl.html
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 12 Feb 1998 17:10:14 -0500

> discovery. Some additional delay - yes, but packet loss - no.

the control packet then resembles a type of advanced probe, which is nice.
but this would also imply that one of two things exist.  a) the host is
required to buffer or hold the data until the probe sequence is finished.
or b) applications whose hosts are attached to the ad-hoc network must be
retrofitted to indicate that a MANET control message must be sent before 
any data can be sent in order to avoid any/all buffering of data (in order
to deal with installation of a route).  i assume that you are following
option A.

one could probably find those that argue option A is fine, and in fact we
had an internal discussion about that.  however, what do you do about the 
case where the ad-hoc network is attached to the current Internet?  gateway
routers used to bridge the two architectures must either buffer data or 
drop it....if the reactive route instantiation process is a long process.
and if you choose the buffering approach, then this is subject to the
number of new flows traversing a network at any given time.  

i don't wish to convey the idea that reactive routing is a killer problem,
but rather it is a subject that needs to be examined as one evaluates the
effectiveness of a MANET proposal.

-ken

---

From: "M. Scott Corson" <[email-masked]>
Date: Tue, 24 Feb 1998 19:37:20 -0500 (EST)

> effectiveness of a MANET proposal.

Ken,

Thanks for pointing out this hole in the issues draft.

You are correct that reactive (a.k.a. on-demand or source-initiated) routing 
results in latency during the route creation process.  It stems from the
desire to be bandwidth (and also energy) efficient at the networking layer.
It is similar to the concept of on-demand or polled operation
used in the design of low-power paging devices, where access and transmission
latency is traded off in order to conserve power...here one is conserving
both power and bandwidth in a networking protocol layer, part of a
possible, overall approach to low power network design.  In can also be
viewed as a form of "lazy computation" if you are familiar with the term's
usage in the context of software design.

Energy-efficient networking is an essential requirement for many
future military and commercial systems that rely on battery power.
In such systems, upper layer software and protocols should be able to
adapt to the latency variations inherent in a wireless environment
(including, at times, completely disconnected operation). 
Presently, upper layer protocols and applications are relatively
non-adaptive. If these require that the networking layer establish
and maintain connectivity between all possible source-destination
pairs in a network, energy consumption may suffer.  This may be 
the only option for some systems or applications in the near term.
Eventually, I think more adaptive protocols and architectures will
be developed.

Just about any on-demand algorithm can easily be made to function in the
traditional mode, TORA being no exception.  It just expends more
bandwidth and energy (possibly needlessly) to reduce latency.
I think on-demand or traditional operating modes should be available.
Even if power is not a concern, there is always bandwidth to consider.

-Scott

*******************************************************************************

M. Scott Corson                                 Institute for Systems Research
[email-masked]                              A.V. Williams Bldg. (115)
Phone: 301-405-6630 (Rm. 2205 AVW)              University of Maryland     
Fax:   301-314-8586                             College Park, MD  20742

*******************************************************************************