Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK

From: Charlie Perkins <[email-masked]>
Date: Wed, 28 May 2014 10:34:32 -0700

Hello Lotte,

I am O.K. with removing the RREP_ACK from the draft.  There was
some discussion a while back about compatibility, but I have not
seen anyone defending the RREP_ACK in this discussion and it was
not present in the previous DYMO drafts.

If anyone would prefer to keep RREP_ACK, then I will try to fashion
some more detailed specification for handling it, which will be
basically the way it was handled by AODV.

Regards,
Charlie P.

On 4/22/2014 12:39 PM, manet issue tracker wrote:
> #41: AckReq vs RREP_ACK
>
>   In Section 13.5., the AODVv2 Draft briefly describes a mechanism called
>   RREP_ACK, which seems to serve a similar purpose as the AckReqs described
>   in section 5.2.
>   While RFC 3561, which is referenced in section 13.5., explains that a
>   RREP-ACK is sent when a packet with the 'A' bit set is received, the
>   AODVv2 does not describe how a RREP_ACK is triggered.
>   Additionally, the draft does not specify how a RREP_ACK should be handled.
>   If the feature of a RREP_ACK is really needed, a more thorough explanation
>   should be added. Otherwise, removing it could be a step towards de-
>   cluttering the draft.
>

---

From: Yuichi IGARASHI <[email-masked]>
Date: Thu, 29 May 2014 04:03:36 +0900

Hi Charlie,

It says in sec.4 that "AODVv2 only supports bidirectional links”. But, 
if you remove RREP_ACK from the spec, how does AODVv2 itself ensure all 
links are bi-directional? AODVv2 requires all routes to implement other 
protocol for verifying bi-directionality of links? I am sure that would 
cause interoperability problems.
Also, this is related to tickets #26 and #27, I think.

Regards,
Yuichi
(2014/05/29 2:34), Charlie Perkins wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

-- 
  Hitachi, Ltd., Yokohama Research Laboratory
  Yuichi Igarashi
  Mail： [email-masked]
  Tel ： +81-(0)50-3135-3457

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 28 May 2014 14:41:50 -0700

Hello Yuishi,

Bidirectionality can be tested in various ways, even by
just using ping (which is required by IP and thus always
available).  This is discussed briefly at the top of
page 9 in the current revision, but I will be happy to
expand the discussion.  Please let me know how I can
improve the description.  I will cite include a citation
for ping (i.e., ICMP Echo Request/Reply).

Regards,
Charlie P.

On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote:
> if you remove RREP_ACK from the spec, how does AODVv2 itself ensure 
> all links are bi-directional? AODVv2 requires all routes to implement 
> other protocol for verifying bi-directionality of links? I am sure 
> that would cause interoperability problems.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 28 May 2014 23:59:05 +0200

Hi Charlie,

so you plan to remove the "AODVv2 does only support bidirectional links" part?

Henning Rogge

On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins
<[email-masked]> wrote:
>> It says in sec.4 that "AODVv2 only supports bidirectional links”. But, if
>> you remove RREP_ACK from the spec, how does AODVv2 itself ensure all links
>> are bi-directional? AODVv2 requires all routes to implement other protocol
>> for verifying bi-directionality of links? I am sure that would cause
>> interoperability problems.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 28 May 2014 15:48:36 -0700

Hello Henning,

No, just the parts about RREP_ACK.  In order to support
bidirectional links, more protocol is needed.  This is well
known from past efforts, but not part of the current
reactive protocol.

Instead, the document will suggest other methods for
testing bidirectionality (for example, ping).

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 29 May 2014 00:56:57 +0200

> testing bidirectionality (for example, ping).

Sorry, but I don't think this makes sense.

If your routing protocol does ONLY support bidirectional links, it
needs to make sure not to setup routes over non-bidirectional links.

Just to make this clear, will AODVv2 setup routes over links that are
asymmetric? Or do you plan to call external programs for checking
links to be bidirectional during the routing processing?

Henning Rogge

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 28 May 2014 15:58:03 -0700

Hello again Henning,

Oops...     I meant, "In order to support
unidirectional links, more protocol is needed." ...

Regards,
Charlie P.

---

From: Jiazi YI <[email-masked]>
Date: Thu, 29 May 2014 01:03:00 +0200

Hi Charlie,

In my opinion, the handling of uni-directional links is very important for
MANET protocols.
Giving several possible options without specification doesn't look like a
standard track protocol.

best

Jiazi

On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins <
[email-masked]> wrote:

>>>> if

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 28 May 2014 16:05:58 -0700

Hello Jiazi,

Do you mean to say that you think AODVv2 should provide routes
whenever they exist even in networks with unidirectional links?

Regards,
Charlie P.

On 5/28/2014 4:03 PM, Jiazi YI wrote:
> Hi Charlie,
>
> In my opinion, the handling of uni-directional links is very important 
> for MANET protocols.
> Giving several possible options without specification doesn't look 
> like a standard track protocol.
>
> best
>
> Jiazi
>
>
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>
>     Hello Henning,
>
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Hello Yuishi,
>
>                            In Section 13.5., the AODVv2 Draft briefly
>                         describes a mechanism
>                         called
>                            RREP_ACK, which seems to serve a similar
>                         purpose as the AckReqs
>                         described
>                            in section 5.2.
>                            Additionally, the draft does not specify
>                         how a RREP_ACK should be
>                         handled.
>                            If the feature of a RREP_ACK is really
>                         needed, a more thorough
>                         explanation
>                     [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Jiazi YI <[email-masked]>
Date: Thu, 29 May 2014 01:12:03 +0200

Hi Charlie,

No exactly what I meant.
Unidirectional links are common in MANET - I think we agree on this.
Therefore, the routing protocol should be able to build provide routes
considering the fact given above.
It can be, for example, avoid using such kind of links -- or other smarter
ways.
But not matter which way to take, it should be clearly specified.

best

Jiazi

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 28 May 2014 16:13:46 -0700

Hello Henning,

There are several methods by which bidirectionality can
be assured, including the use of blacklists for RREQ/RREP,
NHDP, ping, and others.  DYMO had left this choice up
to the implementation, and other implementations in the
past have shown that was feasible.  The only reason for the
more recent inclusion of RREP_ACK was upon suggestion for
compatibility with other proposals, and I am O.K. with
either taking out RREP_ACK or leaving it in with additional
specification.

I don't think "ping" qualifies as an external program.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 28 May 2014 16:40:50 -0700

Hello Jiazi,

On 5/28/2014 4:12 PM, Jiazi YI wrote:
> It can be, for example, avoid using such kind of links -- or other 
> smarter ways.

Check.

> But not matter which way to take, it should be clearly specified.

Also check.  However, different implementations may have various
differences about which method is best.

Regards,
Charlie P.

>
> best
>
> Jiazi
>
>
>
> On Thu, May 29, 2014 at 1:05 AM, Charlie Perkins 
>>     In my opinion, the handling of uni-directional links is very
>>     important for MANET protocols.
>>     Giving several possible options without specification doesn't
>>     look like a standard track protocol.
>>
>>     best
>>
>>     Jiazi
>>
>>
>>                                In Section 13.5., the AODVv2 Draft
>>                             briefly describes a mechanism
>>                             called
>>                                RREP_ACK, which seems to serve a
>>                             similar purpose as the AckReqs
>>                             described
>>                                in section 5.2.
>>                                Additionally, the draft does not
>>                             specify how a RREP_ACK should be
>>                             handled.

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 29 May 2014 00:54:34 +0100

The important thing is that implementations interoperate and work.
- Multiple options that don't interoperate is not going to fly as a standards track protocol.
- Multiple options where each router could pick a different option really needs to justify that this will work, and still is going to have an uphill struggle to be acceptable.

It would be useful to know what here makes things not really reactive, but partially proactive, and what here adds to reactive route discovery delay.

What's been implemented here - even in simulation?

On 29 May 2014, at 00:40, Charlie Perkins wrote:

>> Therefore, the routing protocol should be able to build provide routes considering the fact given above. 
>> It can be, for example, avoid using such kind of links -- or other smarter ways.
> 
> Check.
> 
>> On Thu, May 29, 2014 at 1:05 AM, Charlie Perkins <[email-masked]> wrote:
>> 
>> Hello Jiazi,
>> 
>>> In my opinion, the handling of uni-directional links is very important for MANET protocols. 
>>> Giving several possible options without specification doesn't look like a standard track protocol. 
>>> 
>>> best
>>> 
>>> Jiazi
>>> 
>>> 
>>> On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins <[email-masked]> wrote:
>>> 
>>> Hello Henning,
>>>

---

From: Yuichi IGARASHI <[email-masked]>
Date: Thu, 29 May 2014 11:44:41 +0900

Hi Charlie,

I understand there are some ways(ping, etc) to verify that. But what you 
mentioned seems that specifying a way to check that is out of scope of 
this draft( depends on implementations), although AODVv2 supports 
bidirectional links.

My suggestion is to describe details of RREP_ACK processing/generating 
parts additionally in order to interoperate easily with multi vendors, 
instead of removing RREP_ACK part. Also,it should be removed MAY and 
various options.

Regards,
Yuichi

---

From: Henning Rogge <[email-masked]>
Date: Thu, 29 May 2014 09:51:31 +0200

> I don't think "ping" qualifies as an external program.

Hi,

ICMP/ICMP-Reply might be the only one with a good chance of
interoperability if you remove the RREP_ACKs. Because otherwise both
sides of the connection have to agree to a mechanism.

Still, I don't like the idea of a routing protocol that says "it only
supports bidirectional links" but does not make sure itself that it
ignores links that are not.

Henning Rogge

---

From: Lotte Steenbrink <[email-masked]>
Date: Thu, 29 May 2014 15:05:45 +0200

Hello Yuichi,

Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI <[email-masked]>:

> Hi Charlie,
> 
> It says in sec.4 that "AODVv2 only supports bidirectional links”. But, if you remove RREP_ACK from the spec, how does AODVv2 itself ensure all links are bi-directional?

AODVv2 proposes the inclusion of an AckReq TLV to ensure bidirectional connectivity. My point was that, given the existence of this AckReq mechanism, the additional inclusion of RREP_ACK seems redundant.

Cheers,
Lotte

[1] http://tools.ietf.org/html/draft-ietf-manet-dymo-26#section-5.2

> AODVv2 requires all routes to implement other protocol for verifying bi-directionality of links? I am sure that would cause interoperability problems.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 29 May 2014 15:43:20 +0200

It would be interesting to understand why AckReq was included in the first place - given that that seems redundant with the well-known rrep_ack mechanism, and given that (it seems to me) that there are potential huge downsides to AckReq. 

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

> On 29 mai 2014, at 15:05, Lotte Steenbrink <[email-masked]> wrote:
> 
> Hello Yuichi,
>

---

From: Lotte Steenbrink <[email-masked]>
Date: Thu, 29 May 2014 17:15:35 +0200

Hello,

> It would be interesting to understand why AckReq was included in the first place - given that that seems redundant with the well-known rrep_ack mechanism, and given that (it seems to me) that there…

Of course. I forgot to check whether my E-Mail client messed up the order of my mails again before I sent my reply, that's why my reply was a bit redundant. Sorry about that.

The reason I opted for a removal of RREP_ACKs instead of AckReqs was that, to me, the description of RREP_ACKs in the AODVv2 draft seemed like an afterthought. Being somewhat new to the topic, I'm as familiar with RREP_ACKs as I am with AckReqs, with the difference being that I'd have no idea how to implement RREP_ACKs, at least not from the AODVV2 specification:
How do I set the 'A' flag in RFC5444 RREPs correctly? One could assume that, because Section 5.2. demands that AckReqs should be requested by adding an appropriate message TLV, the same applies to RREP_ACKs, but that kind of guesswork could lead to interoperability issues.
Why doesn't the draft remind me that (and how) a RREP "with the 'A' flag set" should be handled? Why doesn't it remind me that (and how) a RREP_ACK should be handled?

Using other sources, i'd probably be able to cobble *something* together, but I'd guess that the probability that another programmer will come up with the same interpretation is not that high.

So, what I was basically saying is just: Having two ways of ensuring bidirectionality is confusing (and maybe standing in the way of interoperability?), and one of the ways is confusing in itself, and I think that needs to be sorted out-- by ditching one of the approaches and being more specific in case RREP_ACKs are here to stay.

Cheers,
Lotte Steenbrink

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 30 May 2014 22:16:01 +0200

Lotte,
> On 29 mai 2014, at 17:15, Lotte Steenbrink <[email-masked]> wrote:
> 
> Hello,
> 

Lotte, my question was actually not as much directed as you, as it was to the authors of the protocol....RREP_ACK is well-known, there's operational experiences with it, etc., whereas AckReq seems "new" (and, as I indicated, I think - without having analyzed it in details - that there are potential issues with it that we do not fully understand) and without operational experience supporting its existence....

That said, as I have pointed out over the previous many years, this protocol is quite underspecified, and this is but one of the areas in which this is the case. I am comforted by the fact that you agree with that sentiment (although, also, saddened by the state of the specification and protocol.)

> How do I set the 'A' flag in RFC5444 RREPs correctly? One could assume that, because Section 5.2. demands that AckReqs should be requested by adding an appropriate message TLV, the same applies to…

Yes, very much so.

> Why doesn't the draft remind me that (and how) a RREP "with the 'A' flag set" should be handled? Why doesn't it remind me that (and how) a RREP_ACK should be handled?

Agree completely.

> So, what I was basically saying is just: Having two ways of ensuring bidirectionality is confusing (and maybe standing in the way of interoperability?), and one of the ways is confusing in itself,…

Yes having ambiguities and underspecified bits and pieces on a protocol specification is bad. As is having possibly non-interoperable options specified. 

So, I think that we are in violent agreement that the protocol & specification has serious problems here...

Best,

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 31 May 2014 00:08:00 +0200

I usually like to wait for authors defend, but I do defend. I don't think
removing them is required, IMHO each of the items have advantages to the
protocol, I don't see what is the problem in them from reading this ticket
41, my reply below,

> not present in the previous DYMO drafts.

As RFC3561 has it this will need it as will.

> basically the way it was handled by AODV.

Yes, it is easy to add details which should be details of the optional
used as was in RFC3561.

>>   RREP_ACK, which seems to serve a similar purpose as the AckReqs
I don't agree they have exactly similar effects if they were used
separately or jointly. Furthermore, RREP_ACK is a message and the AckReq is
not a message, so it is not correct to compare them as if they are similar
items to see verses.

>>   AODVv2 does not describe how a RREP_ACK is triggered.
I agree that it needs to be added.

>>   Additionally, the draft does not specify how a RREP_ACK should be
Same as to be from RFC3561.

>>   should be added. Otherwise, removing it could be a step towards de-
This RREP_ACK message is optional used as was done in RFC3561.

 AB

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 30 May 2014 19:56:33 -0700

Hello Abdussalam,

On 5/30/2014 3:08 PM, Abdussalam Baryun wrote:
> I usually like to wait for authors defend, but I do defend.

In most cases, I don't have much to defend.  I want to synthesize
all constructive commentary and suggestions to make a satisfactory
resolution.

> I don't think removing them is required, IMHO each of the items have 
> advantages to the protocol, I don't see what is the problem in them 
> from reading this ticket 41, my reply below,

The case for removing RREP_ACK is to simplify the protocol.

The case for including RREP_ACK is to have an AODVv2-specific
mechanism and, along the way, to enable better compatibility
with previous approaches.

I do not have any strong preference.  So far, most people seem
to want to keep RREP_ACK, so for the upcoming revision I will
supply additional text as needed to clarify the specification.

In *general*, I don't like having redundant mechanisms, because
it's confusing to explain the differences, and it's more places to
put bugs in the implementation and in the specification.  But that
is a *general* guideline, and each case has to be judged on the
claimed merits for the various approaches.

A small bit of follow-up below...

>     I am O.K. with removing the RREP_ACK from the draft.  ...
>
>

I don't agree that presence of a feature in RFC 3561 means that
the feature has to be present also in AODVv2.

> Same as to be from RFC3561.

Roughly speaking, RREP_ACK is a mechanism for managing the blacklist.

Regards,
Charlie P.

---

From: Jiazi YI <[email-masked]>
Date: Sat, 31 May 2014 21:57:02 +0200

On Sat, May 31, 2014 at 4:56 AM, Charlie Perkins <
[email-masked]> wrote:

> <snip>

<snip>

Maybe I missed something here. By saying "better compatibility with
previous approaches", do you mean RFC 3561?

Jiazi