Subject: data slides on power consumption - Oslo meeting

From: Laura Feeney <[email-masked]>
Date: Wed, 4 Aug 1999 23:40:08 +0200

I've had a couple of requests, so the data slides from my presenation
in Oslo are up on my web page at http://www.sics.se/~lmfeeney.  (The
presentation slides will be in the proceedings, of course; but the
data slides were not too interesting when printed 6up in black and
white.)

There is also a pointer to some of the really cool power consumption
measurements that were done at UC Berkeley.

Regards, 
Laura

-- 
Laura Marie Feeney				[email-masked]
Visiting Researcher				http://www.sics.se/
Computer and Network Architectures Lab	 	Tel: +46 8 633 15 09 
Swedish Institute of Computer Science		Mobile: +46 70 246 56 63     
Box 1263, SE-164 29 KISTA, SWEDEN		Fax: +46 8 751 72 30

---

From: Joe Macker <[email-masked]>
Date: Wed, 04 Aug 1999 18:58:28 -0400

>measurements that were done at UC Berkeley.
Laura:

Thanks for putting these up ... a nice area of contribution ;-)  A quick
clarification question.  Is the AODV used based upon the CMU ns2 release or
the previous modified model work referenced from Ericsson Switch Lab in
previous briefs? I believe there were some differences that may effect the
results.

-Joe

---

From: Laura Feeney <[email-masked]>
Date: Thu, 5 Aug 1999 15:31:34 +0200

Hi Joe, 

Yes, I used the AODV-ll from the CMU release.  I only added tracing to
CMU ns2; the protocols didn't change at all.

Using hello messages in addition to link-layer failure discovery would
definitely affect the energy consumption results.  (Except perhaps in
the case of a MAC layer which provides neighbor discovery.)

The CMU folks found that AODV hello messages hurt performance and so
implemented AODV-ll (Mobicom'98 paper).  But in Minneapolis, I recall
that SwitchLab reported good results using hello messages.  So perhaps
there is some other difference between the two implementations. (Or
perhaps my understanding is incomplete.)

Laura

>>>>> Joe Macker <[email-masked]> writes:

Joe> At 11:40 PM 8/4/99 +0200, Laura Feeney wrote:
>>  I've had a couple of requests, so the data slides from my
>> presenation in Oslo are up on my web page at
>> http://www.sics.se/~lmfeeney.  (The presentation slides will be in
>> the proceedings, of course; but the data slides were not too
>> interesting when printed 6up in black and white.)
>> 
>> There is also a pointer to some of the really cool power
>> consumption measurements that were done at UC Berkeley.
>> 
Joe> Laura:

Joe> Thanks for putting these up ... a nice area of contribution ;-) A
Joe> quick clarification question.  Is the AODV used based upon the
Joe> CMU ns2 release or the previous modified model work referenced
Joe> from Ericsson Switch Lab in previous briefs? I believe there were
Joe> some differences that may effect the results.

Joe> -Joe

---

From: Joe Macker <[email-masked]>
Date: Thu, 05 Aug 1999 12:14:35 -0400

>perhaps my understanding is incomplete.)

Not exactly, perhaps Tony Larsson could chime in ;-), but I believe that
report concluded a hybrid approach seemed best for AODV (hello + link layer
notifications).  Hello alone did not show good results.  It was an older
version of the draft, but they implemented quite a few additional variants.

From my recollection there were 3 AODV versions implemented.
- hello only
- hello+ Mac layer notification
- Mac layer notification only

The -- limited TTL search prior to flood -- algorithms may also help reduce
energy consumption during route discovery.  Do you know whether anything of
this nature was going on in the DSR or AODV models you tested?

-Joe

---

From: Laura Feeney <[email-masked]>
Date: Thu, 5 Aug 1999 20:56:50 +0200

Joe> At 03:31 PM 8/5/99 +0200, Laura Feeney wrote:
>>  Hi Joe,
>> 
>> The CMU folks found that AODV hello messages hurt performance and
>> so implemented AODV-ll (Mobicom'98 paper).  But in Minneapolis, I
>> recall that SwitchLab reported good results using hello messages.
>> So perhaps there is some other difference between the two
>> implementations. (Or perhaps my understanding is incomplete.)

Joe> Not exactly, perhaps Tony Larsson could chime in ;-), but I
Joe> believe that report concluded a hybrid approach seemed best for
Joe> AODV (hello + link layer notifications).  Hello alone did not
Joe> show good results.  It was an older version of the draft, but
Joe> they implemented quite a few additional variants.

>> From my recollection there were 3 AODV versions implemented.
Joe> - hello only 
Joe> - hello + Mac layer notification 
Joe> - Mac layer notification only

Yes, I believe it was the combination that yielded good results for
Switchlab.  In the 802.11 context, "hello only" doesn't make too much
sense to me - you're just throwing away useful MAC layer information.
(You want to avoid repeatedly deleting and rediscovering a marginal
link, though.)

Joe> The -- limited TTL search prior to flood -- algorithms may also
Joe> help reduce energy consumption during route discovery.  Do you
Joe> know whether anything of this nature was going on in the DSR or
Joe> AODV models you tested?

I used cmu-extendedns2-1.1.0, so this reflects the state of protocols
CMU implemented as of late last year.  In particular, DSR used a
TTL=1/TTL=infinity for route discovery and AODV used TTL=infinity.

I didn't make any changes to the protocols, just to the ns trace
facility.  Part of the goal was to keep my results as comparable as
possbile to those of others.  I was curious whether a new performance
metric could provide an additional perspective.

Laura

Joe> -Joe

---

From: Joe Macker <[email-masked]>
Date: Thu, 05 Aug 1999 15:06:59 -0400

>metric could provide an additional perspective.

Thanks for the clarifications.  I didn't want to assume.

As a follow-on, it might be interesting to see energy consumption for both
protocols with modified route discovery algorithms.  I am curious.

>Joe

---

From: Per Johansson <[email-masked]>
Date: Fri, 06 Aug 1999 10:21:25 +0200

Hi Joe,

Since Tony is still on vacation I guess I should jump in here.
Yes, we introduced a combination of hello messages and link layer
notifications to AODV in our simulations and I'll try to give a short
background to why.

The AODV version using hello messages only, gave a "slow" link failure
detection as could be expected.

The AODV version using link layer notifications only, improved the reaction
link failures, but gave less a priori knowledge of the immediate
neighbourhood. This meant that routes to neighbour nodes also required a route
request (we did not use the expanding ring search in the simulations), which
gave an initial delay for packets to neighbours.

Based on those findings we combined the two cases into an AODV version with
both hello messages and link layer notifications, which mainly improved the
end-to-end delay (packet) characteristics of AODV.
Note that the hello messages also helped to report link failures on routes
that (temporarily) didn't have any data flowing and made it possible to react
(find a new route) before new packets were sent.

One conclusion here is that it may be a good idea to periodically check who
your neighbours are in a manet. (Perhaps a rule that applies to a lot more
cases than just manets ;-)

Regards
    Per

--
Per Johansson                   Phone:  +46 8 719 02 90
Ericsson Radio Systems AB       Mobile: +46 70 519 02 90
SwitchLab                       Fax:    +46 8 719 66 77
Varuvägen 9B                    E-mail: [email-masked]
S-126 25 Stockholm, Sweden

---

From: "M. Scott Corson" <[email-masked]>
Date: Fri, 6 Aug 1999 07:56:21 -0400 (EDT)

> cases than just manets ;-)

Per,

Yes...I think it's understood that in some instances, a balance of
proactivity and reactivity is desired.  Several proposed protocols
present different methods and means for striking such a balance.
I think a very interesting direction for future work is the development
of policies for dynamically tuning a protocol (i.e. perhaps the 
amount of proactivity employed) to its networking context.
The work presented several mtgs ago from Cornell, 
which begins exploring the proactive/reactive balance for ZRP, 
is representative of work in this promising direction.

-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

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