Subject: [manet] A few more AODVv2 comments

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 12 Mar 2015 16:07:44 +0000

Still piecemeal, and still seeing if I want to come back to some summary comments when I've read details. And I'll reserve overall comments until I'm done (and when I know what they are).

Section 6.2 reasons to recognise bidirectionality could include L2 information.

I would have explicitly said NHDP HELLO message, not just message later in that section (though it is the only NHDP message).

Blacklist removal seems to be MAY at one point, and SHOULD at another. Also that's discussing things that trigger additions to blacklists (e.g. failure to receive RREP_Ack) and removals due to timeouts. Might there not also be specific reasons to remove from blacklists (e.g. receiving NHDP HELLO that indicates that if using that option)?

It seems rather a lack of progress that we are still at the only form of metric that an implementation will know what to do with is a hop count. Well, almost. Most of the discussion of metrics appears to require only an increasing function. Except the penultimate bullet in the first list in Section 8.1 appears to be explicitly additive. Once you decide on additive, you can make the whole metrics decision much more open. I'd go with Henning's suggestion to fix a single data type (32 bit integer perhaps) which would replace the second paragraph of 7.4 and make things much more easily extensible. (I haven't got as far as seeing how the suggestion of varying data types in that paragraph fits into the required data structures.)

Section 8.1, from the numbered points onwards, appears to give three descriptions of how you handle competing routes. One is good, if completely rigorous. Two is fine if the other one is more human readable (and possibly belongs in an earlier section). Three appears more than is wanted. (I also note the use of both AND and && in the second.) Note that I haven't actually checked if all three are consistent (that's not trivial when they switch between formulae and terms like stale) let alone if they work. (I recall someone has done some work on the latter point, is that published/referenceable?)

Section 8.3 first paragraph I think would be better separating out AODVv2 from IP. Whether to forward a packet is a decision made consulting IP's table, not AODVv2's use of invalid. I think that means you should indicate that invalid routes should be struck from IP's table.

Third paragraph in 8.3 precursor table appears from left field. (Unless I've missed an earlier reference, I haven't done an electronic search). While postponing details is fine, the fact that there is such a thing, related to a route, and might matter, wants flagging up earlier. At the least indicated as a possible addition in Section 6.1.

Section 8.4 invalid route may be expunged. What's the intended status of the least recently used comment? Is that a may within a may, or a should within a may (you may do this, if you do, you should do it that way), or just a suggestion?

The binary exponential backoff on page 25 needs more about what is and is not proposed (and how its parameters - not specified - relate to other parametesr).

I'm not at all sure about the packet queuing comments. Do we have good experience here? Is  affixed buffer right? Is that "usually positive" comment known to be so? I know enough about buffering to know I don't know enough about buffering, and  that there are some counterintuitive results in the field.

I haven't read section 9 in any detail yet, but I will note that figure 1 is really about message contents, not message structure (or format).

--
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked]<mailto:[email-masked]> | 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

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Thu, 12 Mar 2015 17:19:04 +0100

On Thu, Mar 12, 2015 at 5:07 PM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> It seems rather a lack of progress that we are still at the only form of
> metric that an implementation will know what to do with is a hop count.
> Well, almost. Most of the discussion of metrics appears to require only an
> increasing function. Except the penultimate bullet in the first list in
> Section 8.1 appears to be explicitly additive. Once you decide on additive,
> you can make the whole metrics decision much more open. I’d go with
> Henning’s suggestion to fix a single data type (32 bit integer perhaps)
> which would replace the second paragraph of 7.4 and make things much more
> easily extensible. (I haven’t got as far as seeing how the suggestion of
> varying data types in that paragraph fits into the required data
> structures.)

32 bit Path-Cost would also allow AODVv2 to share link-metric
RFCs/algorithms with OLSRv2...

Henning Rogge

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 24 Mar 2015 21:33:14 -0700

Hello again Chris,

More follow-up below...

On 3/12/2015 9:07 AM, Dearlove, Christopher (UK) wrote:
> I would have explicitly said NHDP HELLO message, not just message 
> later in that section (though it is the only NHDP message).
>

Text has been added for these purposes.

> Blacklist removal seems to be MAY at one point, and SHOULD at another.
>

Fixed as SHOULD.

> Also that’s discussing things that trigger additions to blacklists 
> (e.g. failure to receive RREP_Ack) and removals due to timeouts. Might 
> there not also be specific reasons to remove from blacklists (e.g. 
> receiving NHDP HELLO that indicates that if using that option)?
>

Text has been added for this purpose.

> It seems rather a lack of progress that we are still at the only form 
> of metric that an implementation will know what to do with is a hop 
> count. Well, almost. Most of the discussion of metrics appears to 
> require only an increasing function. Except the penultimate bullet in 
> the first list in Section 8.1 appears to be explicitly additive. Once 
> you decide on additive, you can make the whole metrics decision much 
> more open. I’d go with Henning’s suggestion to fix a single data type 
> (32 bit integer perhaps) which would replace the second paragraph of 
> 7.4 and make things much more easily extensible. (I haven’t got as far 
> as seeing how the suggestion of varying data types in that paragraph 
> fits into the required data structures.)
>

We have revamped the way of indicating the Metric Type according to 
recent discussion on the list.

> Section 8.1, from the numbered points onwards, appears to give three 
> descriptions of how you handle competing routes. One is good, if 
> completely rigorous. Two is fine if the other one is more human 
> readable (and possibly belongs in an earlier section). Three appears 
> more than is wanted. (I also note the use of both AND and && in the 
> second.) Note that I haven’t actually checked if all three are 
> consistent (that’s not trivial when they switch between formulae and 
> terms like stale) let alone if they work. (I recall someone has done 
> some work on the latter point, is that published/referenceable?)
>

The pseudo-code has been collected in the appendix for that purpose, and 
the other description is a summary that should help with understanding.

> Section 8.3 first paragraph I think would be better separating out 
> AODVv2 from IP. Whether to forward a packet is a decision made 
> consulting IP’s table, not AODVv2’s use of invalid. I think that means 
> you should indicate that invalid routes should be struck from IP’s table.
>

It is possible, although not required, to implement AODV using IP's 
route table and this should be considered a viable option.  That's the 
way we did it a while back.

> Third paragraph in 8.3 precursor table appears from left field. 
> (Unless I’ve missed an earlier reference, I haven’t done an electronic 
> search). While postponing details is fine, the fact that there is such 
> a thing, related to a route, and might matter, wants flagging up 
> earlier. At the least indicated as a possible addition in Section 6.1.
>

Precursors are introduced before that section, but all of the normative 
text should be kept together I think.

> Section 8.4 invalid route may be expunged. What’s the intended status 
> of the least recently used comment? Is that a may within a may, or a 
> should within a may (you may do this, if you do, you should do it that 
> way), or just a suggestion?
>

It is a MAY and a SHOULD within a MAY, and text has been added to spell 
that out.

> The binary exponential backoff on page 25 needs more about what is and 
> is not proposed (and how its parameters – not specified – relate to 
> other parametesr).
>

Text has been added as suggested.

> I’m not at all sure about the packet queuing comments. Do we have good 
> experience here? Is  affixed buffer right? Is that “usually positive” 
> comment known to be so? I know enough about buffering to know I don’t 
> know enough about buffering, and  that there are some counterintuitive 
> results in the field.
>

It is indeed important to allow packet buffering.  The purposes for 
doing so are out of scope for AODVv2.  Do you think some examples are 
needed?  The times when buffering is not positive mainly have to do with 
real-time packet delivery scheduling.

> I haven’t read section 9 in any detail yet, but I will note that 
> figure 1 is really about message contents, not message structure (or 
> format).
>

The wording has been changed.

Regards,
Charlie P.