Re: [manet] Reactive Protocol Situation

["Dearlove, Christopher (UK)" <[e-mail]>]

No, the implied statement is agreeing with you that simple disc models aren't enough, and highlighting a particularly key issue here. I have not even hinted that I'm discussing RPL, this is the MANET WG where the subject of the day is DYMO and LOADng. And I most particularly haven't even hinted at having anything to say about draft-clausen-lln-rpl-experiences.

(As for asymmetric vs. unidirectional, oddly most of what I write here uses asymmetric ;)

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: [phone] |  Fax: [phone]
[e-mail] | http://www.baesystems.com

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


-----Original Message-----
From: Philip Levis [mailto:[e-mail]] 
Sent: 01 November 2012 16:46
To: Dearlove, Christopher (UK)
Cc: Axel Colin de Verdière; <[e-mail]> List; Bo Berry (boberry)
Subject: Re: [manet] Reactive Protocol Situation

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

On Nov 1, 2012, at 9:27 AM, Dearlove, Christopher (UK) wrote:

> They can be good evidence of the failure of protocols ;)
> 
> But what is clear to me is that one important issue (and another of my posts is attempting to both be more precise, as well as going elsewhere) is the handling of unidirectional links. So any good evidence needs to consider those.

Since communication in wireless is rarely binary, I think the more common term is asymmetric links. I'm confused; I don't believe that unit disc models capture asymmetric links. Is the implied statement that RPL doesn't properly handle asymmetric links but LOADng does? I think this came up in draft-clausen-lln-rpl-experiences and there was some discussion on the ROLL list about it. The neighbor set in RPL is defined in 8.2.1:

"First, the candidate neighbor set is a subset of the nodes that can be reached via link-local multicast."

then in DIO processing (8.2.3.1) it reads:

"As DIO messages are received from candidate neighbors, the neighbors may be promoted to DODAG parents by following the rules of DODAG discovery as described in Section 8.2."

I want to be clear here; I haven't read deeply about LOADng, thought about it much, or experimented with it at all. So I have zero to say about LOADng's strengths and weaknesses. 

But just because somebody publishes (and republishes) a draft saying something doesn't mean it's true. There are, in my opinion, some very valid points in draft-clausen-lln-rpl-experiences that relate to fundamental design decisions in RPL. For example, I think that the issues raised about the state requirements of floating DODAGs and RPL message fragmentation are valid and reasonable and something we need to look at. 

However, there are others that are the result of naive mistakes anyone can make when implementing any wireless routing protocol, such as link asymmetry and protocol convergence. Unfortunately the draft doesn't distinguish the two. Implementing a protocol poorly then saying it doesn't work isn't particularly meaningful. As I said in Paris, I thought the draft is valuable because it outlines many of the basic mistakes one makes the first time you try implementing a wireless routing protocol.

Phil

********************************************************************
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.
********************************************************************