Subject: Re: [manet] #43 (aodvv2): Reliance on bidirectional paths (submitted for Chris Dearlove)

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 10 Sep 2014 14:54:32 +0200

I don't believe AODV only supports bidirectional, there are many work out
IETF done for that. I think there can be ways to make AODVv2 support
unidirectional paths as well. As links in MANET can be unidirectional
and/or bidirectional. For example, the RREQ message MUST indicate which
type of route communication it is requesting: bidirectional paths or
unidirectional paths or mix (what does authors/WG think?). We may need to
update RFC6130 for AODVv2 as well as done for OLSRv2.

On Monday, July 21, 2014, Charles E. Perkins wrote:

>
> Hello Chris,
>
> Perhaps it would be better to identify the proper protocol method as
> part of the applicability statement.  If no other means are available, then
> AODVv2 nodes could be required to use the blacklist mechanism, which
> is intended to provide bidirectionality.

Yes, ok, but I agree with Chris that the protocol needs to ensure
interoperability in all its normative body (e.g. the appendix is not
normative), so one required solution for the bidirectional issue, so all
implementations follow.

>
> It seems unwise to require additional protocol mechanisms for cases
> in which layer 2 already guarantees bidirectional links.  This could also
> be included as a statement within the applicability section.

Yes, agree.

AB

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 10 Sep 2014 15:20:31 +0200

On Sep 10, 2014, at 14:54, Abdussalam Baryun <[email-masked]> wrote:

> I don't believe AODV only supports bidirectional, there are many work out IETF done for that.

Right now, this protocol does not specify proper behavior in case links are not bidirectional. It does hand-waving of the “can do this, can do that, or can do the other thing, or can think of something else entirely”, but does not specify *one* way — which means that two implementations may do different, and non-interoperable, things.

This is one of the many examples of this protocol being way underspecified, which has been pointed out for many, many years, and which has not been addressed by the authors. If the authors truly doesn’t know how to manage uni-directional links, or do not know which of the different options they wave around would make for a good default, then that is indicative of that this document perhaps is not mature enough to be advanced on Standards Track, and that more research, experimentation is needed — thus, making an Experimental RFC in the IRTF a perhaps better publication target and venue?

> I think there can be ways to make AODVv2 support unidirectional paths as well. As links in MANET can be unidirectional and/or bidirectional. For example, the RREQ message MUST indicate which type of route communication it is requesting: bidirectional paths or unidirectional paths or mix (what does authors/WG think?). 

The use of unidirectional paths in a routing protocol is actually not trivial — there’s been a lot of research work done in this area but, as far as I know, nothing conclusive has come from it. 

The topic is not uninteresting, however, and I would suggest that:

	o	this reactive protocol, and its current specification (draft-ietf-manet-aodvv2) be 
		moved to the IRTF, for intended publication as Experimental RFC

	o	as part of the development in the IRTF, the use of unidirectional paths be explored,
		and the utility of unidirectional paths be part of the experiment?

It sounds fairly close to what you suggest, doesn’t it? 

> We may need to update RFC6130 for AODVv2 as well as done for OLSRv2. 

No, we most definitely do not need to update RFC6130 for this purpose, there has been no arguments made that even suggest that this is necessary.

Best,

Thomas

> Yes, ok, but I agree with Chris that the protocol needs to ensure interoperability in all its normative body (e.g. the appendix is not normative), so one required solution for the bidirectional issue, so all implementations follow. 
>  
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 10 Sep 2014 14:25:40 +0100

First, no, nothing you have said is in any way an argument to update 6130 (NHDP), except of course that any protocol may define new TLVs to carry when used together with NHDP. But it's not obvious what that would be - NHDP already collects unidirectional information (at the receiver end of course). I'll take that up after my second point.

Second, AODVv2 needs to either support or not support unidirectional links. If it supports them, it needs to define how. If it doesn't support them it needs to have a defined interoperable mechanism to do so.

And that's where to start. What is required. Then how to do it, including what information is needed. At the abstract level. Then you can start thinking about whether you can do that using NHDP, within existing AODVv2 messages, with new messages, etc. "We need to update 6130" isn't where to start, it's not even step two.

And there is an issue with using NHDP. It would convert AODVv2 from a reactive protocol to a hybrid one. Some of the reasons that a reactive protocol may be of interest are based on no transmissions with no data. Removing that as even an option would make the protocol less applicable. Of course I have no problem with using NHDP as an option. But the sort of option I'd want to see is one where if some routers decide to send HELLO messages and some don't then the network still works at least as well as if none did. Which should be to find routes where they are findable (maybe only using bidirectional links) and not to fail because some links are unidirectional.

(How can that be done? No, I don't have a design. I just have a requirement. Actually, summarising what the WG's reactive protocol requirements are more precisely wouldn't be a bad, probably overdue, idea. I'm not suggesting a full blown draft - though one would be really good - but just basic bullet points. To address issues like unidirectional links and pure/hybrid reactiveness. And what else? Note that my unidirectional link requirements would be: must function interoperably when some links are unidirectional, but using those unidirectional links, optional. The latter can definitely be debated. The former is necessary.)

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 10 Sep 2014, at 13:54, Abdussalam Baryun <[email-masked]> wrote:
> 
> I don't believe AODV only supports bidirectional, there are many work out IETF done for that. I think there can be ways to make AODVv2 support unidirectional paths as well. As links in MANET can be unidirectional and/or bidirectional. For example, the RREQ message MUST indicate which type of route communication it is requesting: bidirectional paths or unidirectional paths or mix (what does authors/WG think?). We may need to update RFC6130 for AODVv2 as well as done for OLSRv2. 
>

---

From: John Dowdell <[email-masked]>
Date: Wed, 10 Sep 2014 16:31:03 +0100

All

As at draft-04, AODVv2 does not support unidirectional links. It is 
clearly stated in several sections, and in fact there is a test stated 
to specifically check whether a link is bidirectional or not.

Please do not argue further over whether AODVv2 supports this or that 
feature. The draft is under major review at this time, trying to take 
into account the very many comments that you have all kindly made. I 
fully agree with Thomas that supporting unidirectional links is 
non-trivial, and there is enough to do right now with the cycles 
available to the author team without adding this feature.

John

On 10/09/14 14:20, Thomas Clausen wrote:
>
> On Sep 10, 2014, at 14:54, Abdussalam Baryun 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Right now, this protocol does not specify proper behavior in case 
> links are not bidirectional. It does hand-waving of the “can do this, 
> can do that, or can do the other thing, or can think of something else 
> entirely”, but does not specify *one* way — which means that two 
> implementations may do different, and non-interoperable, things.
>
> This is one of the many examples of this protocol being way 
> underspecified, which has been pointed out for many, many years, and 
> which has not been addressed by the authors. If the authors truly 
> doesn’t know how to manage uni-directional links, or do not know which 
> of the different options they wave around would make for a good 
> default, then that is indicative of that this document perhaps is not 
> mature enough to be advanced on Standards Track, and that more 
> research, experimentation is needed — thus, making an Experimental RFC 
> in the IRTF a perhaps better publication target and venue?
>
>> I think there can be ways to make AODVv2 support unidirectional paths 
>> as well. As links in MANET can be unidirectional 
>> and/or bidirectional. For example, the RREQ message MUST indicate 
>> which type of route communication it is requesting: bidirectional 
>> paths or unidirectional paths or mix (what does authors/WG think?). 
>
> The use of unidirectional paths in a routing protocol is actually not 
> trivial — there’s been a lot of research work done in this area but, 
> as far as I know, nothing conclusive has come from it.
>
> othis reactive protocol, and its current specification 
> (draft-ietf-manet-aodvv2) be
> oas part of the development in the IRTF, the use of unidirectional 
> paths be explored,
> No, we most definitely do not need to update RFC6130 for this purpose, 
> there has been no arguments made that even suggest that this is necessary.
>
> Best,
>
> Thomas
>
>> normative), so one required solution for the bidirectional issue, so 
>> all implementations follow.
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 10 Sep 2014 16:56:04 +0100

On unidirectional links, my point wasn't one of features, but one of necessity (use, or interoperably avoid). I'm sure that's clear to you, though the draft up to now hasn't been good in this area. It may not be clear to everyone posting.

However on whether the protocol should have a purely reactive mode of operation, I think this is quite appropriate for the WG to discuss, not just a "wait and see what we offer you". Unless you can say there will be such a mode, in which case I'll wait and see it.

> On 10 Sep 2014, at 16:31, John Dowdell <[email-masked]> wrote:
> 
> All
> 
> As at draft-04, AODVv2 does not support unidirectional links. It is clearly stated in several sections, and in fact there is a test stated to specifically check whether a link is bidirectional or not.
> 
> Please do not argue further over whether AODVv2 supports this or that feature. The draft is under major review at this time, trying to take into account the very many comments that you have all kindly made. I fully agree with Thomas that supporting unidirectional links is non-trivial, and there is enough to do right now with the cycles available to the author team without adding this feature.
> 
> John
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 10 Sep 2014 22:50:34 +0200

On Tuesday, July 22, 2014, Dearlove, Christopher (UK) wrote:

> The key thing is that two independent implementations need to interoperate
> and not use unidirectional links. At the moment that wouldn't happen.
>
>
In draft's applicability statement:

---- OLD EDIT-----

AODVv2 only supports bidirectional links.  In the case of possible
unidirectional links, either blacklists (see Section 5.2) or other
means (e.g. adjacency establishment with only neighboring routers that
have bidirectional communication as indicated by NHDP [RFC6130]) of
assuring and monitoring bidirectionality are recommended. Otherwise,
persistent packet loss or persistent protocol failures could occur.
The cost of bidirectional link L (denoted Cost(L)) may depend upon the
direction across the link for which the cost is measured.  If received
over a link that is unidirectional, metric information from incoming
AODVv2 messages SHOULD NOT be used for route table updates.

---- NEW EDIT -----

AODVv2 only supports bidirectional links.  In the case of possible
unidirectional links, the protocol MUST use blacklists (see Section
5.2), otherwise may use means (e.g. adjacency establishment with only
neighboring routers that have bidirectional communication as indicated
by NHDP [RFC6130]) of assuring and monitoring bidirectionality are
recommended. Otherwise, persistent packet loss or persistent protocol
failures could occur.

-------------

Move the below text to another suitable section which I recommend section 5.2.

{{{

The cost of bidirectional link L (denoted Cost(L)) may depend upon the
direction across the link for which the cost is measured.  If received
over a link that is unidirectional, metric information from incoming
AODVv2 messages SHOULD NOT be used for route table updates.

}}}

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 10 Sep 2014 23:05:43 +0200

Hi John,

I want progress so I will do many edits and discussion and want just to
help. Hope authors don't mind my participation.

On Wednesday, September 10, 2014, John Dowdell wrote:

> clearly stated in several sections, and in fact there is a test stated to
> specifically check whether a link is bidirectional or not.
>

IMHO, MANET use case cannot exclude unidirectional possibility, anyway let
me follow authors. The draft is not clear that is why Chris had some
confusion on interoperability.

 In the draft in section 13.4, it discusses also mechanism of multicast
RREP which describe it can be used in unidirectional link purpose. So draft
saying somehow there can be some support of unidirectional links, but not
well described how to configure. My suggest for RREQ was valid because the
draft is not excluding unidirectional links as possibility.

Any way I gave my reaction for progress and will try to wait to see what
will happen to change draft as what WG/authors decide.

AB

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 10 Sep 2014 22:20:22 +0100

That's addressed to me, but a misdirection in that regard. In this regard I've made comments, and as John said, let's see what the next draft brings. I'm not even sure which bits below have what status.

> On 10 Sep 2014, at 21:50, Abdussalam Baryun <[email-masked]> wrote:
> 
> 
> 
>> The key thing is that two independent implementations need to interoperate and not use unidirectional links. At the moment that wouldn't happen.
> 
> AODVv2 only supports bidirectional links.  In the case of possible unidirectional links, either blacklists (see Section 5.2) or other means (e.g. adjacency establishment with only neighboring routers that have bidirectional communication as indicated by NHDP [RFC6130]) of assuring and monitoring bidirectionality are recommended. Otherwise, persistent packet loss or persistent protocol failures could occur.  The cost of bidirectional link L (denoted Cost(L)) may depend upon the direction across the link for which the cost is measured.  If received over a link that is unidirectional, metric information from incoming AODVv2 messages SHOULD NOT be used for route table updates.
> 
> ---- NEW EDIT ----- 
> AODVv2 only supports bidirectional links. In the case of possible unidirectional links, the protocol MUST use blacklists (see Section 5.2), otherwise may use means (e.g. adjacency establishment with only neighboring routers that have bidirectional communication as indicated by NHDP [RFC6130]) of assuring and monitoring bidirectionality are recommended. Otherwise, persistent packet loss or persistent protocol failures could occur. 
> -------------
> The cost of bidirectional link L (denoted Cost(L)) may depend upon the direction across the link for which the cost is measured. If received over a link that is unidirectional, metric information from incoming AODVv2 messages SHOULD NOT be used for route table updates.
> }}}
> 
> AB
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 10 Sep 2014 14:44:53 -0700

Hello Abdussalam,

The usual way for reactive protocols to offer operation
over unidirectional links is to have the RREP broadcast in
addition to broadcasting the RREQ.  That's an awfully
expensive operation to require when nodes already have
bidirectional links to their neighbors.  However, broadcast
RREP could be optional (and wouldn't affect interoperability
for bidirectional links, except for congestion).

Right now the document specifies a method for detecting
and avoiding unidirectional links, and I believe that is
appropriate for the current standard.

The idea of adding a bit to RREQ to request broadcast RREP
would work, and can easily be specified if approved by the
WG members.  It would probably affect only a remarkably
few lines of actual text in the document, and since the
mechanism has been studied quite a few times in the past
the results can be considered somewhat predictable.  But,
again, the extra congestion is a high price to pay unless it is
really needed to find unidirectional links -- which, by the
way, are likely to be more fragile as well.

Regards,
Charlie P.

On 9/10/2014 5:54 AM, Abdussalam Baryun wrote:
> I don't believe AODV only supports bidirectional, there are many work 
> out IETF done for that. I think there can be ways to make AODVv2 
> support unidirectional paths as well. As links in MANET can be 
> unidirectional and/or bidirectional. For example, the RREQ message 
> MUST indicate which type of route communication it is 
> requesting: bidirectional paths or unidirectional paths or mix (what 
> does authors/WG think?). We may need to update RFC6130 for AODVv2 as 
> well as done for OLSRv2.
>

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 11 Sep 2014 00:53:46 +0200

Hi Charlie,

> appropriate for the current standard.

The subject says bidirectional paths, and my concern is also
considering unidirectional paths possibility. When draft says AODVv2 only
supports bidirectional links, I understand it as the links of the
originator router. So if originator knows its neighbours with
unidirectional then my suggestion can be valid and reasonable to solve
configuration of section 13.4.

However, I just gave my input suggestion, for this ticket.

AB

---

From: John Dowdell <[email-masked]>
Date: Thu, 11 Sep 2014 11:10:23 +0100

Abdussalam

I have already spotted that one in my review and it has been discussed 
within the author team. But thanks anyway.

John

On 10/09/14 21:50, Abdussalam Baryun wrote:
>     The key thing is that two independent implementations need to
>     interoperate and not use unidirectional links. At the moment that
>     wouldn't happen.
>
>
> AODVv2 only supports bidirectional links.  In the case of possible unidirectional links, either blacklists (seeSection 5.2) or other means (e.g. adjacency establishment with only neighboring routers that have bidirectional communication as indicated by NHDP [RFC6130]) of assuring and monitoring bidirectionality are recommended. Otherwise, persistent packet loss or persistent protocol failures could occur.  The cost of bidirectional link L (denoted Cost(L)) may depend upon the direction across the link for which the cost is measured.  If received over a link that is unidirectional, metric information from incoming AODVv2 messages SHOULD NOT be used for route table updates.
>
> ---- NEW EDIT -----

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 11 Sep 2014 15:01:33 +0200

Hi John,

I believe its WG work not author team work. My edit below was documented in
IETF for WG and is before WG editors action, because authors done their
discussion outside IETF. I will continue help the WG in this draft as it's
our work together and to making action per ticket for progress. So I
understand that authors agree with my edits action.

AB

On Thursday, September 11, 2014, John Dowdell wrote:

>> interoperate and not use unidirectional links. At the moment that wouldn't
>> happen.
>>
>>
> AODVv2 only supports bidirectional links.  In the case of possible unidirectional links, either blacklists (see Section 5.2) or other means (e.g. adjacency establishment with only neighboring routers that have bidirectional communication as indicated by NHDP [RFC6130]) of assuring and monitoring bidirectionality are recommended. Otherwise, persistent packet loss or persistent protocol failures could occur.  The cost of bidirectional link L (denoted Cost(L)) may depend upon the direction across the link for which the cost is measured.  If received over a link that is
>  u
> nidirectional, metric information from incoming AODVv2 messages SHOULD NOT be used for route table updates.
>
>
>  ---- NEW EDIT -----
>
> manet mailing [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>https://www.ietf.org/mailman/listinfo/manet
>
>
>

---

From: John Dowdell <[email-masked]>
Date: Fri, 12 Sep 2014 11:29:29 +0100

Abdussalam

Actually this is a topic that is still under discussion in the author 
team. The problem can be looked at from a number of different 
viewpoints. I proposed something similar to your edit and then something 
I had not thought of was pointed out to me by one of the other authors. 
I do not believe it is appropriate to share the raw work in progress 
with the WG if the authors do not yet have a common understanding.

On a similar note, as I posted yesterday, the document is large and I am 
having a hard time working through it all. I will defend your right to 
make suggestions and propose edits, since that is after all what the 
IETF is about, but given that there are some bigger topics I want to get 
straight in my own head, please excuse me for not including this topic 
at the moment. I will come back to it, but there are bigger issues right 
now.

John

On 11/09/14 14:01, Abdussalam Baryun wrote:
> Hi John,
>
> I believe its WG work not author team work. My edit below was 
> documented in IETF for WG and is before WG editors action, because 
> authors done their discussion outside IETF. I will continue help the 
> WG in this draft as it's our work together and to making action per 
> ticket for progress. So I understand that authors agree with my edits 
> action.
>
> AB
>
>     I have already spotted that one in my review and it has been
>     discussed within the author team. But thanks anyway.
>
>     John
>
>>         interoperate and not use unidirectional links. At the moment
>>         that wouldn't happen.
>>
>>
>>     AODVv2 only supports bidirectional links.  In the case of possible unidirectional links, either blacklists (seeSection 5.2) or other means (e.g. adjacency establishment with only neighboring routers that have bidirectional communication as indicated by NHDP [RFC6130]) of assuring and monitoring bidirectionality are recommended. Otherwise, persistent packet loss or persistent protocol failures could occur.  The cost of bidirectional link L (denoted Cost(L)) may depend upon the direction across the link for which the cost is measured.  If received over a link that is
>>       u
>>     [email-masked]  <javascript:_e(%7B%7D,'cvml',[email-masked]');>