[manet] Loops & Specification (was: Re: draft-ietf-manet-aodvv2-12 and draft-ietf-manet-dlep-17)

[[e-mail]]

Dear All,

A colleague brought my attention to this paper earlier this week:

	http://www.cse.unsw.edu.au/~rvg/pub/AODVloop.pdf <http://www.cse.unsw.edu.au/~rvg/pub/AODVloop.pdf>

I’ve scanned through it quickly, and it looks like something the WG should care about - although I admittedly have not had cycles to study it in all the glory details yet.

A highlight from the conclusion:

	"We have shown that, in contrast to common belief, sequence numbers do not 
	 guarantee loop freedom, even if they are increased monotonically over time and 
	 incremented whenever a new route request is generated. This was mainly achieved 
	 by analysing the Ad hoc On-demand Distance Vector (AODV) routing protocol. 
	 We have shown that AODV can yield routing loops"

The authors of  are also making some interesting observations on how different implementations of RFC3561 see loops due to different interpretations of the specification.

I think that much of what is in this paper would apply to v2, still, notably directly the part about sequence numbers (and indirectly, it would be worth to verify if their precognitions on the specification leading to different interpretations and different loop properties also still apply?)

Best,

Thomas



> On 18 Nov 2015, at 02:35, Thomas Clausen <[e-mail]> wrote:
> 
> 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 <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.
> 
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> 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.
>> _____________________________________________________
>> _______________________________________________
>> manet mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> _______________________________________________
> manet mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>