Subject: Re: [manet] Comment on draft-dearlove-olsrv2-metrics-02

From: Henning Rogge <[email-masked]>
Date: Fri, 1 Aug 2008 11:04:48 +0200

Am Donnerstag 31 Juli 2008 20:19:45 schrieb Hongwei Zhang:
> As far as the Internet Draft is concerned, perhaps it does not have to
> specify the specific method of estimating certain metrics, instead it
> only needs to provide the right interface for incorporating different
> estimation methods. IMHO, how to share/diffuse control information (as
> was the original focus of the MANET focus?) may well be an orthogonal
> issue w.r.t. what control information/metric to use in routing and how
> to get that information.
An optional field to specify a "collision domain" might be very useful for 
routing metrics too.

Collision aware metrics like MIC need to know the collision domain (the WLAN 
channel for example) to calculate an optimized path with multi-radio nodes.

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: [email-masked]
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

---

From: David Young <[email-masked]>
Date: Sun, 3 Aug 2008 13:49:25 -0500

> channel for example) to calculate an optimized path with multi-radio nodes.

It will also be important to express the metrics on links between virtual
nodes and, for that matter, the existence of virtual nodes.

Dave

-- 
David Young             OJC Technologies
[email-masked]      Urbana, IL * (217) 278-3933 ext 24
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 27 Aug 2008 12:08:51 +0100

> I am sceptic about the idea to reduce the transmitted TC-set to a
'routing MPR 
> set', because this reduce the amount of redundancy in the topology set
and 
> might create unstable routes on larger networks, but this have to be
tested 
> on a real MANET. If the reduced routing set creates stable routes, it
would 
> be a great way to reduce the necessary airtime of OLSRv2.

(a) This is unchanged from OLSRv2 as-is, and OLSR (except for that it
would
    be routing MPR set, rather than MPR set, but that's not an essential
    difference, the routing MPR set basically is an MPR set).

(b) What you actually advertise is the Advertised Neighbor Set. This
must
    contain all routing MPR selectors (for minimum topology) but can
contain
    more than that. How you make that decision is up to you. (OLSR had
an
    explicit parameter TC_REDUNDANCY that offers three options. It's not
    specified in OLSRv2, although my implementation current retains it.
    I have heard some people's attitude is "pick message size, put in
needed
    MPR selectors, then add other symmetric neighbours until message
full or
    run out of neighbours".)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 27 Aug 2008 12:19:42 +0100

If I understand you correctly, we do leave the lower level details
outside
OLSRv2 both for link quality and link metrics, by only specifying how
to use these, not how to create these.

--
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mullen, John
Sent: 31 July 2008 22:37
To: Hongwei Zhang; Philip Levis
Cc: Philippe Jacquet; [email-masked]
Subject: Re: [manet] Comment on draft-dearlove-olsrv2-metrics-02

*** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
Keep this in mind if you answer this message. 
	
Hi,
 
I agree that a better approach would be to provide a framework for link
quality estimation for several reasons, but I think two are especially
important.  
 
I feel a MANET protocol should not be implementation-specific. For one,
as in the case of Internet protocols, the underlying technology may be
of very different sorts, even in the same network.  Moreover, technology
is evolving very quickly. While issues that make link quality estimation
difficult, such as shadowing, multipath fading, and terrain effects,
will continue to exist, the suite of technological solutions will grow.
Specifying a particular method might make the protocol less generally
useful and prone to early obsolesce. 
 
Another issue is the nature of the application. For example, in a
military application, there would be the competing issues of rapid
communications and discovery by the enemy.  In a forest fire, terrain is
a big factor and there tend to be very large voids in the middle of the
area to be connected. Urban fire fighting, EMT, and police require
rapid, reliable communications, but deal with very complicated terrain
and may need to deal with security issues. Technological solutions that
work in one setting might be useless in another. Focusing on the
higher-level MANET issues means that user can select lower-level
solutions that best fit their needs.
 
John P. Mullen
(575) 646-2958
[email-masked]

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hongwei Zhang
Sent: Thursday, July 31, 2008 12:20 PM
To: Philip Levis
Cc: Philippe Jacquet; [email-masked]
Subject: Re: [manet] Comment on draft-dearlove-olsrv2-metrics-02

A follow up on Phil's comment on the drawbacks of beacon-based link
estimation:

we have done some detailed study on the error of beacon-based link
estimation in both mote networks and 802.11b networks. Please find below
two articles on these studies:

	http://www.cs.wayne.edu/~hzhang/group/TR/DNC-TR-08-02.pdf   
	
http://www.cs.wayne.edu/~hzhang/group/publications/LOF-journal.pdf   

Hongwei
---
http://www.cs.wayne.edu/~hzhang/

Philip Levis wrote:

	On Jul 30, 2008, at 10:59 AM, Philippe Jacquet wrote: 

		Dear Henning, 
		
		That's a great idea. Surely Freifunk experience in
metric handling  will provide a central help to this initiative. ETX is
using link  quality via hello loss rate? I would like to experiment it
on  OLSRv2. Do you have more details about it? 

	Can you be more precise by what you mean by ETX? I don't mean to
be  dense, but the acronym tends to be used in two ways. The first use
is  a metric -- Estimated Transmissions -- which can be computed in a
bunch of ways. The second use is a particular algorithm developed at
MIT for computing this value. 
	
	The ETX algorithm computes the ETX metric by measuring a sliding
window of beacons. Note that his is insufficient for 802.11b due to
variable bitrates, so you need to either run ETX on each bitrate
independently or just run it at one of them and then use a dynamic
bitrate selection algorithm. 
	
	There are several other algorithms for computing the ETX metic.
These  days, consensus seems to be that directly using data traffic is
greatly superior to beacons. You use beacons for discovery and rough
estimates, but use whether you receive L2 acks to directly measure the
estimated transmissions. One major problem with beacons is bursty  links
will perform terribly: while the PRR might be 80% (ETX = 1.25),  this
can be because there are 2-second periods of 0% PRR, leading to  huge
numbers of retransmissions. Most wireless networks tend to be  bursty. 
	
	If you're interested in this, I can send you some sample source
code  and some references. 
	
	Phil

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 27 Aug 2008 12:21:27 +0100

I believe here we are a step too far if we want to proceed 
in a reasonable timescale for standardisation. An experimental
extension would be interesting though.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 01 August 2008 10:05
To: [email-masked]
Cc: Philippe Jacquet
Subject: Re: [manet] Comment on draft-dearlove-olsrv2-metrics-02

               *** WARNING ***

Henning

---

From: Hongwei Zhang <[email-masked]>
Date: Wed, 27 Aug 2008 10:00:19 -0400

I agree.

Hongwei