Subject: [manet] draft-ietf-manet-aodvv2-12 and draft-ietf-manet-dlep-17

From: "Ratliff, Stanley" <[email-masked]>
Date: Mon, 9 Nov 2015 17:10:17 +0000

Hello WG participants -

The above referenced drafts were posted Oct. 13 (for AODVv2), and Oct. 16 (DLEP). The co-authors and the chairs ask that you please take some time to review and comment on the new submissions.

Regards,
Stan

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 18 Nov 2015 10:35:00 +0900

Dear all,

I have started looking through the recently updated draft-ietf-manet-aodvv2-12. A lot has changed, and I regret not to have had a blow-by-bow comeback to the previous review comments  - would have made it a somewhat easier task to check if all have been addressed or not.

But, I will work through it and produce a detailed review - but from my first quick read-through there're a couple of issue that jumped at me as worth bringing forward on a more global level already.

The first relates to  how RREQs are forwarded -- or, more generally, are not.

The protocol currently talks about "message is regenerated" rather than "forwarded". I have understood that this means that a RREQ is actually not an "end to end" entity, but is a "hop by hop" entity. 

First, that is a curious design choice, is there any reason why this is so considered?

Second, if a RREQ message is hop-by-hop only, then I do not think that the use of the RFC5444 hop-limit/hop-count fields is appropriate.

Third, the statement in section 6.5 on the use of RFC6621 is incorrect in two ways: RFC6621 does specify how messages are *forwarded* (but, as discussed above, you are not forwarding messages).

More seriously, this paragraph is incorrect:

> "Implementations MAY choose to employ techniques to reduce the number of multicast messages sent. Use of [RFC6621] in deployments is recommended. Employing [RFC6621] in a subset of the operational AODVv2 routers in a network, or configuring different algorithms on different routers, will not cause interoperability issues, but will reduce the effectiveness of the multicast reduction scheme."

Different routers using different relay selection algorithms in the same network will not *just* cause loss of efficiency, but *will* cause interoperability issues.

For example if "router A" decides to suppress its message relaying because it estimates that "router B" provides sufficient coverage - and conversely "router B" suppresses relaying for the same reason: neither A nor B would relay, and so any routers reachable only via A and B would not be covered.

This is not a far-sought example: it can be as simple as A and B simply using self-selecting relay algorithms with different tie-breakers.

In short: I think that the whole message flooding/regeneration part requires serious work.

The second issue is that I also suspect that there is some issue with buffering, or rather with how it is specified; starting in section 6.6, I am not sure that leaving that as "a matter of policy at each router" is entirely right. 

Also on buffering, I am wondering if the "start delivering buffered packets" conditions (penultimate paragraph in 6.6, and of course through the processing sections) is sufficient; I suspect that the condition "When a valid route is installed" is not sufficient - that there are situations where a routing table entry is installed, but the complete route is not available or is not bidirectional?This obviously is related to RREP_Ack being hop-by-hop and not end-to-end....

Either way, the parts of the specification that relate to buffering contain a mixture of normative and non-normative verbiage (a lot of "can" but also a lot of MUST/SHOULD) which I think could do with a tightening up. 

But....is buffering even something that should be specified by this document? It does not impact interoperability and it interferes substantially with transport and congestion control, and I am not sure that we understand the consequences (I am not convinced that the claims in the document on benefits to TCP are substantiated or even true).

As I indicated, a complete review will follow, but I thought that these was a global enough topics to call out and get engineered right.

Thomas

PS: I remain convinced that the security considerations section is insufficient ; I will try to articulate my thoughts on why that is, but for starters looking at the recently raised (by somebody else, the Chris replied) AODV security questions would probably be helpful

> On 10 Nov 2015, at 02:10, Ratliff, Stanley <[email-masked]> wrote:
> 
> Hello WG participants –
>  
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 18 Nov 2015 08:49:50 +0000

I've not had time to look at either yet, though I hope to review DLEP very soon.

But this has made me think about the RFC 6621 reference in AODVv2. It's always been clear this has been rather a throwaway comment that needed thought, but until now I hadn't really given it any.

And it doesn't work. RFC 6621 is fundamentally unusable here. Let's consider each on turn. 

AODVv2 is in the RFC 5444 structure. As has been noted on many occasions, AOVDVv2 gets to use messages, but packets are not in its competence.

RFC 6621 is about packets. But not even RFC 5444 packets but IP packets. It's about whether or not to forward them. But RFC 5444 packets aren't just not forwarded in unchanged IP packets, they aren't even forwarded at all. They are each a single hop construct, and if a message is forwarded (which is by the routing protocol, as far as RFC 5444 is concerned, it's a new message) it will be in a new packet, with possibly new companions.

If AODVv2 wants to use a more efficient flooding process, it needs one at the message level. Now an example of that exists - the mechanism on RFC 7181. Unfortunately we didn't break that out as a separate draft (we would have liked to, but there were reasons we didn't).

And even if (by reference or other means) it were used - or some related mechanism such as a CDS - that processing/forwarding mechanism assumes you have defined MPRs (or similarly, that you have defined a CDS). And that needs a local exchange of information, such as NHDP's HELLO messages (and the rest of NHDP) augmented with RFC 7181's MPR TLV (though only the flooding bit is needed).

In other words, taking some real work to define. And also raising a question for the WG - why do we want a reactive protocol? The main attraction as I see it is the "if you're not doing anything, you're not transmitting" property. Which adding this voids. Of course maybe the WG doesn't value that. Or it is acceptable as an option. But if so it needs to be an option that all routers use, or none. And if all, compatibly. (MPR flooding allows different MPR selection algorithms - but only as long as they satisfy the fundamental MPR algorithm properties.)

In short, RFC 6621 must go. The alternative is nothing, or significant work.

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

> On 18 Nov 2015, at 01:35, Thomas Clausen <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Victoria Mercieca <[email-masked]>
Date: Thu, 19 Nov 2015 16:09:02 +0000

Hi Thomas and Christopher,

Thank you for your comments.  If I may address just one point for starters
- regeneration vs forwarding. We use the term regeneration since forwarding
seems inappropriate when the message content changes at each hop.

The changes we make to the message content are:

1) We change the metric so that each router along the path learns a route
from the message, with the metric associated with the path up to that point
2) AckReq only applies between hops, so needs to be removed at each hop,
and a new AckReq element may need to be added for the next hop.
3) ValidityTime could potentially be added by any intermediate router that
wishes to limit the time it will forward packets on the route.
4) Stripping out Unreachable Addresses from RERR which did not affect our
route set.

Can we really use the term "forwarding" if we are changing the metric
value, adding a validity time, adding/removing AckReq or removing addresses
and their associated TLVs?

Further, in reply to the comment about use of the msg-hop-count and
msg-hop-limit fields, I think it does not matter that a message only
travels one hop in that particular form, with that exact set of information
enclosed. Hop limit and hop count are part of the message and used by the
routing protocol, and so they refer to the multi-hop path that the AODVv2
message will follow, indicating when not to regenerate any further. So
AODVv2 uses these fields as suggested in RFC5444 Appendix B, to limit the
number of hops across which it will regenerate a packet so as to "prevent
messages from endlessly circulating in a MANET".

Kind regards,
Victoria.

On Wed, Nov 18, 2015 at 8:49 AM, Christopher Dearlove <
[email-masked]> wrote:

> But this has made me think about the RFC 6621 reference in AODVv2. It's
> always been clear this has been rather a throwaway comment that needed
> thought, but until now I hadn't really given it any.
>
> AODVv2 is in the RFC 5444 structure. As has been noted on many occasions,
> AOVDVv2 gets to use messages, but packets are not in its competence.
>
> RFC 6621 is about packets. But not even RFC 5444 packets but IP packets.
> It's about whether or not to forward them. But RFC 5444 packets aren't just
> not forwarded in unchanged IP packets, they aren't even forwarded at all.
> They are each a single hop construct, and if a message is forwarded (which
> is by the routing protocol, as far as RFC 5444 is concerned, it's a new
> message) it will be in a new packet, with possibly new companions.
>
> If AODVv2 wants to use a more efficient flooding process, it needs one at
> the message level. Now an example of that exists - the mechanism on RFC
> 7181. Unfortunately we didn't break that out as a separate draft (we would
> have liked to, but there were reasons we didn't).
>
> And even if (by reference or other means) it were used - or some related
> mechanism such as a CDS - that processing/forwarding mechanism assumes you
> have defined MPRs (or similarly, that you have defined a CDS). And that
> needs a local exchange of information, such as NHDP's HELLO messages (and
> the rest of NHDP) augmented with RFC 7181's MPR TLV (though only the
> flooding bit is needed).
>
> In other words, taking some real work to define. And also raising a
> question for the WG - why do we want a reactive protocol? The main
> attraction as I see it is the "if you're not doing anything, you're not
> transmitting" property. Which adding this voids. Of course maybe the WG
> doesn't value that. Or it is acceptable as an option. But if so it needs to
> be an option that all routers use, or none. And if all, compatibly. (MPR
> flooding allows different MPR selection algorithms - but only as long as
> they satisfy the fundamental MPR algorithm properties.)
>
> I have started looking through the recently
> updated draft-ietf-manet-aodvv2-12. A lot has changed, and I regret not to
> have had a blow-by-bow comeback to the previous review comments  - would
> have made it a somewhat easier task to check if all have been addressed or
> not.
>
> But, I will work through it and produce a detailed review - but from my
> first quick read-through there're a couple of issue that jumped at me as
> worth bringing forward on a more global level already.
>
> The protocol currently talks about "message is regenerated" rather than
> "forwarded". I have understood that this means that a RREQ is actually not
> an "end to end" entity, but is a "hop by hop" entity.
>
> Second, if a RREQ message is hop-by-hop only, then I do not think that the
> use of the RFC5444 hop-limit/hop-count fields is appropriate.
>
> Third, the statement in section 6.5 on the use of RFC6621 is incorrect in
> two ways: RFC6621 does specify how messages are *forwarded* (but, as
> discussed above, you are not forwarding messages).
>
> "Implementations MAY choose to employ techniques to reduce the number
>    of multicast messages sent.  Use of [RFC6621 <https://tools.ietf.org/html/rfc6621>] in deployments is
>    recommended.  Employing [RFC6621 <https://tools.ietf.org/html/rfc6621>] in a subset of the operational
>    AODVv2 routers in a network, or configuring different algorithms on
>    different routers, will not cause interoperability issues, but will
>    reduce the effectiveness of the multicast reduction scheme."
>
>
> Different routers using different relay selection algorithms in the same
> network will not *just* cause loss of efficiency, but *will* cause
> interoperability issues.
>
> For example if "router A" decides to suppress its message relaying because
> it estimates that "router B" provides sufficient coverage - and conversely
> "router B" suppresses relaying for the same reason: neither A nor B would
> relay, and so any routers reachable only via A and B would not be covered.
>
> This is not a far-sought example: it can be as simple as A and B simply
> using self-selecting relay algorithms with different tie-breakers.
>
> The second issue is that I also suspect that there is some issue with
> buffering, or rather with how it is specified; starting in section 6.6, I
> am not sure that leaving that as "a matter of policy at each router" is
> entirely right.
>
> Also on buffering, I am wondering if the "start delivering buffered
> packets" conditions (penultimate paragraph in 6.6, and of course through
> the processing sections) is sufficient; I suspect that the condition "When
> a valid route is installed" is not sufficient - that there are situations
> where a routing table entry is installed, but the complete route is not
> available or is not bidirectional?This obviously is related to RREP_Ack
> being hop-by-hop and not end-to-end....
>
> Either way, the parts of the specification that relate to buffering
> contain a mixture of normative and non-normative verbiage (a lot of "can"
> but also a lot of MUST/SHOULD) which I think could do with a tightening up.
>
> But....is buffering even something that should be specified by this
> document? It does not impact interoperability and it interferes
> substantially with transport and congestion control, and I am not sure that
> we understand the consequences (I am not convinced that the claims in the
> document on benefits to TCP are substantiated or even true).
>
> As I indicated, a complete review will follow, but I thought that these
> was a global enough topics to call out and get engineered right.
>
> Thomas
>
> PS: I remain convinced that the security considerations section is
> insufficient ; I will try to articulate my thoughts on why that is, but for
> starters looking at the recently raised (by somebody else, the Chris
> replied) AODV security questions would probably be helpful
>
> The above referenced drafts were posted Oct. 13 (for AODVv2), and Oct. 16
> (DLEP). The co-authors and the chairs ask that you please take some time to
> review and comment on the new submissions.
>
>
>
> Regards,
>
> Stan
>
>
>
>
>

---

From: Victoria Mercieca <[email-masked]>
Date: Mon, 23 Nov 2015 16:59:44 +0000

Hi again,

Regarding the comments on bidirectionality and acks, from Thomas Clausen's
email...specifically:
* "Also on buffering, I am wondering if the "start delivering buffered
packets" conditions (penultimate paragraph in 6.6, and of course through
the processing sections) is sufficient; I suspect that the condition "When
a valid route is installed" is not sufficient - that there are situations
where a routing table entry is installed, but the complete route is not
available or is not bidirectional?This obviously is related to RREP_Ack
being hop-by-hop and not end-to-end....*"

Thomas is right about hop-by-hop RREP_Ack. For intermediate nodes who
install a route to OrigAddr based on a one-hop RREP_Ack from their next hop
toward OrigAddr, it's not guaranteed that the complete route to OrigAddr is
available. Since the route is valid, the router may start forwarding data
packets to OrigAddr. An issue occurs if data packets are forwarded to
intermediate routers before the intermediate router installs a valid route.
If this happened, those data packets would be dropped and RERRs generated
(and regenerated toward the source of the data packets by any router using
it), and the route to OrigAddr would be removed at some but maybe not all
of the routers that installed it. A new RREQ would then have to go out on
behalf of the source of the traffic. So this problem would eventually fix
itself....but not without some dropped packets, RERRs, and a new RREQ/RREP
cycle. But there was a suggestion that this issue might be seen so
infrequently in practise that the overhead required to avoid this issue is
not worth it (i.e. the extra control traffic of acknowledging every link in
every route ever requested, even when some links are already known to be
bidirectional).

If you disagree, then we need to make RREP_Ack end-to-end and accept the
fact that this will result in many more RREP_Ack messages being generated
than in the current version.

Kind regards,
Victoria.

On Thu, Nov 19, 2015 at 4:09 PM, Victoria Mercieca <[email-masked]>
wrote:

>> Second, if a RREQ message is hop-by-hop only, then I do not think that
>> the use of the RFC5444 hop-limit/hop-count fields is appropriate.
>>
>> For example if "router A" decides to suppress its message relaying
>> because it estimates that "router B" provides sufficient coverage - and
>> conversely "router B" suppresses relaying for the same reason: neither A
>> nor B would relay, and so any routers reachable only via A and B would not
>> be covered.
>>

---

From: Awokoya Emma <[email-masked]>
Date: Mon, 30 Nov 2015 03:16:42 -0800

Update has being noted. Thank you Christopher and Thomas. Victoria you did
a good job in explaining their comments.  But your comment "But there was a
suggestion that this issue might be seen so infrequently in practise that
the overhead required to avoid this issue is not worth it (i.e. the extra
control traffic of acknowledging every link in every route ever requested,
even when some links are already known to be bidirectional" that might not
be the case especially with dynamic hoping.

On Mon, Nov 23, 2015 at 8:59 AM, Victoria Mercieca <[email-masked]>
wrote:

>> Thank you for your comments.  If I may address just one point for
>> starters - regeneration vs forwarding. We use the term regeneration since
>> forwarding seems inappropriate when the message content changes at each hop.
>>
>> 3) ValidityTime could potentially be added by any intermediate router
>> that wishes to limit the time it will forward packets on the route.
>>> AODVv2 is in the RFC 5444 structure. As has been noted on many
>>> occasions, AOVDVv2 gets to use messages, but packets are not in its
>>> competence.
>>>
>>> If AODVv2 wants to use a more efficient flooding process, it needs one
>>> at the message level. Now an example of that exists - the mechanism on RFC
>>> Third, the statement in section 6.5 on the use of RFC6621 is incorrect
>>> in two ways: RFC6621 does specify how messages are *forwarded* (but, as
>>> The above referenced drafts were posted Oct. 13 (for AODVv2), and Oct.
>>> 16 (DLEP). The co-authors and the chairs ask that you please take some time
>>> to review and comment on the new submissions.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Stan
>>>
>>>
>>>
>>>
>>>

-- 

Kind Regards,

*Akin-Awokoya Emmanuel*

Data/Telecommication Network Engineer and Web/Content Developer

Member IEEE, NSE, ISOC, CTO, DSA, ICANN

*Interested in volunterism, project research*

*Startups, opendatamining, open data research*

*TVWhitespace technology*

I can be on the next boat, next ship, next plane, next bus as long as where
I am going I could

help someone have a better access and create local contents on the Internet.

*Twitter:@pensebien <https://twitter.com/penseBien>*

*Facebook:* emma.awokoya

*Linkedin: EmmaAwokoya <https://ng.linkedin.com/in/emmaawokoya>*

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 30 Nov 2015 12:43:32 +0100

I think that what I wrote can be summarized into two comments:

	o	It would seem that buffering, as specified, does not accomplish what 
		it states that it accomplishes: packets are (as you describe) still being
		sent while no route is available, and therefore will be dropped later.

		=>	Consequently, it seems that buffering is a futile exercise?

	o	(This part you did not address) Buffers have huge impacts on TCP
		performance, and I doubt if (even disregarding the issue above) the
		issues on e.g. TCP are well enough understood by this WG
		(Bufferbloat was an example of where people got it wrong, despite
		having extensive experience).

And then, a comment on what you write:

> "But there was a suggestion that this issue might be seen so infrequently in practise that the overhead required to avoid this issue is not worth it "

I do not know from where the referred to suggestion comes, but  ... I do not know that there's substantial enough deployment experience with the protocol for "so infrequently in practice" to make the above an actual argument against the  issues raised (and, which you confirm, I understand?) --- this certainly not if targeting std. track.

Best,

Thomas

Sent from my iPad

> On 23 Nov 2015, at 17:59, Victoria Mercieca <[email-masked]> wrote:
> 
> Hi again,
> 
> Regarding the comments on bidirectionality and acks, from Thomas Clausen's email...specifically:
> "Also on buffering, I am wondering if the "start delivering buffered packets" conditions (penultimate paragraph in 6.6, and of course through the processing sections) is sufficient; I suspect that the condition "When a valid route is installed" is not sufficient - that there are situations where a routing table entry is installed, but the complete route is not available or is not bidirectional?This obviously is related to RREP_Ack being hop-by-hop and not end-to-end...."
> 
> 
> Thomas is right about hop-by-hop RREP_Ack. For intermediate nodes who install a route to OrigAddr based on a one-hop RREP_Ack from their next hop toward OrigAddr, it's not guaranteed that the complete route to OrigAddr is available. Since the route is valid, the router may start forwarding data packets to OrigAddr. An issue occurs if data packets are forwarded to intermediate routers before the intermediate router installs a valid route. If this happened, those data packets would be dropped and RERRs generated (and regenerated toward the source of the data packets by any router using it), and the route to OrigAddr would be removed at some but maybe not all of the routers that installed it. A new RREQ would then have to go out on behalf of the source of the traffic. So this problem would eventually fix itself....but not without some dropped packets, RERRs, and a new RREQ/RREP cycle. But there was a suggestion that this issue might be seen so infrequently in practise that the overhead required to avoid this issue is not worth it (i.e. the extra control traffic of acknowledging every link in every route ever requested, even when some links are already known to be bidirectional).
> 
> If you disagree, then we need to make RREP_Ack end-to-end and accept the fact that this will result in many more RREP_Ack messages being generated than in the current version.
> 
> Kind regards,
> Victoria.
> 
>> On Thu, Nov 19, 2015 at 4:09 PM, Victoria Mercieca <[email-masked]> wrote:
>> 
>> Thank you for your comments.  If I may address just one point for starters - regeneration vs forwarding. We use the term regeneration since forwarding seems inappropriate when the message content changes at each hop.
>> 
>> 1) We change the metric so that each router along the path learns a route from the message, with the metric associated with the path up to that point
>> 2) AckReq only applies between hops, so needs to be removed at each hop, and a new AckReq element may need to be added for the next hop.
>> 3) ValidityTime could potentially be added by any intermediate router that wishes to limit the time it will forward packets on the route.
>> 4) Stripping out Unreachable Addresses from RERR which did not affect our route set.
>> 
>> Can we really use the term "forwarding" if we are changing the metric value, adding a validity time, adding/removing AckReq or removing addresses and their associated TLVs?
>> 
>> Further, in reply to the comment about use of the msg-hop-count and msg-hop-limit fields, I think it does not matter that a message only travels one hop in that particular form, with that exact set of information enclosed. Hop limit and hop count are part of the message and used by the routing protocol, and so they refer to the multi-hop path that the AODVv2 message will follow, indicating when not to regenerate any further. So  AODVv2 uses these fields as suggested in RFC5444 Appendix B, to limit the number of hops across which it will regenerate a packet so as to "prevent messages from endlessly circulating in a MANET".
>> 
>> Kind regards,
>> Victoria.
>> 
>> 
>>> On Wed, Nov 18, 2015 at 8:49 AM, Christopher Dearlove <[email-masked]> wrote:

---

From: Awokoya Emma <[email-masked]>
Date: Mon, 30 Nov 2015 03:49:38 -0800

Dear Thomas
So I hope Victoria would consider your recommendation more in a future
comment.

On Mon, Nov 30, 2015 at 3:43 AM, Thomas Clausen <[email-masked]>
wrote:

> *"But there was a suggestion that this issue might be seen so infrequently
> in practise that the overhead required to avoid this issue is not worth it
> "*
>
>
> I do not know from where the referred to suggestion comes, but  ... I do
> not know that there's substantial enough deployment experience with the
> protocol for "so infrequently in practice" to make the above an actual
> argument against the  issues raised (and, which you confirm, I understand?)
> --- this certainly not if targeting std. track.
>
> Best,
>
> Thomas
>
> Sent from my iPad
>

-- 

Kind Regards,

*Akin-Awokoya Emmanuel*

*Facebook:* emma.awokoya