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

From: Charlie Perkins <[email-masked]>
Date: Sun, 20 Jul 2014 22:44:17 -0700

Hello Lotte and all,

To review and summarize:

The AckReq TLV is to be included with the RREP, in cases where the
the node sending the RREP must ascertain that the intended receiver
of the RREP will actually receive it.

When a node receives an RREP that includes the AckReq TLV, then that
node must send back a response.  The discussion has been about
whether or not to mandate that the RREP_Ack is to be sent as that
response.

AckReq and RREP_Ack not technically required.  The nodes can verify
bidirectionality in other ways.  Some layer 2 protocols provide
bidirectionality.  Even for cases where a layer-3 solution is desired,
additional AODVv2 protocol is not required.  Ping is a time-tested
and well understood mechanism for verifying connectivity.

Henning has suggested including and perhaps even mandating
RREP_Ack to be used in preference to existing protocol mechanisms.

For me, this is a minor issue.  It has been stated many times that
AODVv2 should be a "lean" protocol, and that sentiment had led me
to favor exclusion of RREP_Ack from the protocol.   I was later
persuaded to include it as an optional feature.  I can be persuaded
either way -- leaner versus more self-contained.  I do not really care.
I feel that the "self-contained" argument is weak, because no
protocol running on top of IP is self contained (by definition).
But whether or not the argument is weak, if AODVv2 is considered
to need this feature, I am happy to retain the specification for it,
as well as supporting text for when it should be used.

Another alternative would be to *mandate* the use of ping for
this purpose.  To me it seems unwise to mandate ping when the
link is known to be bidirectional (by way of any other mechanism,
layer 2 or layer 3).  This is perhaps especially true because, when
any mechanism (including Ping) would be mandated, is exactly
the time when congestion on the wireless link should be avoided,
and mandating unnecessary control traffic is often considered to
be improper protocol design.

But, to reiterate, the mandate can be included without serious
problem other than additional code and some small percentage
of increased congestion.

In some previous messages, there was confusion between the
AckReq TLV and the RREP_Ack response to that TLV.  I hope this
long-ish message will erase this small bit of earlier confusion.

On 5/29/2014 8:15 AM, Lotte Steenbrink wrote:
> Hello,
>
> Am 29.05.2014 um 15:43 schrieb Thomas Heide Clausen 
> <[email-masked] <mailto:[email-masked]>>:
>
>> 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.
>
> 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
>
>
>>
>> -- 
>> Thomas Heide Clausen
>> http://www.thomasclausen.org <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] 
>> <mailto:[email-masked]>> wrote:
>>
>>> Hello Yuichi,
>>>
>>> Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI 
>>> <[email-masked] 
>>> <mailto:[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.
>>>> Also, this is related to tickets #26 and #27, I think.
>>>>
>>>> Regards,
>>>> Yuichi
>>>> (2014/05/29 2:34), Charlie Perkins wrote:
>>>>>
>>>>> 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.
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>
>>>> -- 
>>>> Hitachi, Ltd., Yokohama Research Laboratory
>>>> Yuichi Igarashi
>>>> Mail: [email-masked] 
>>>> <mailto:[email-masked]>
>>>> Tel : +81-(0)50-3135-3457
>>>
>>> _______________________________________________
>>> manet mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Lotte Steenbrink <[email-masked]>
Date: Mon, 21 Jul 2014 22:42:45 +0200

Hello Charlie,

> and well understood mechanism for verifying connectivity.

As far as I can recall, the argument was that this stands in the way of interoperability, which is why having a lowest common denominator makes sense. Also, it takes the burden of picking the right mechanism away from those who don't know exactly what they're doing (or leaves them a bit more time to think about it). As somebody who had to learn the hard way that using RFC 6775 is maybe not the best idea, I'd support the cause for *one* mandatory minimal solution.

Cheers,
Lotte

>> Am 29.05.2014 um 15:43 schrieb Thomas Heide Clausen <[email-masked]>:
>> 
>>> 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. 
>> 
>> 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
>> 
>> 
>>> 
>>> -- 
>>> Thomas Heide Clausen
>>> http://www.thomasclausen.org
>>> 
>>> On 29 mai 2014, at 15:05, Lotte Steenbrink <[email-masked]> wrote:
>>> 
>>>> 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
>>>> 
>>>>> AODVv2 requires all routes to implement other protocol for verifying bi-directionality of links? I am sure that would cause interoperability problems.
>>>>>>>  In Section 13.5., the AODVv2 Draft briefly describes a mechanism called
>>>>>>>  While RFC 3561, which is referenced in section 13.5., explains that a
>>>>> Mail： [email-masked]
>>>>> Tel ： +81-(0)50-3135-3457
>>>>

---

From: "manet issue tracker" <[email-masked]>
Date: Tue, 22 Jul 2014 18:09:08 -0000

#41: AckReq vs RREP_ACK

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]

-- 
-------------------------------------------+-------------------------------
 Reporter:  [email-masked]  |       Owner:
     Type:  defect                         |  [email-masked]
 Priority:  minor                          |      Status:  new
Component:  aodvv2                         |   Milestone:
 Severity:  Active WG Document             |     Version:
 Keywords:                                 |  Resolution:
-------------------------------------------+-------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/41#comment:1>
manet <http://tools.ietf.org/manet/>