[aodvv2-discuss] Re: regeneration vs forwarding

  • From: "Ratliff, Stanley" <sratliff@xxxxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Wed, 18 Nov 2015 15:12:19 +0000

Vicky,

That confuses me a bit. You said “…so we can use them for our own purposes
since they are part of the AODVv2 message…”. But Thomas says “…the RFC5444
hop-limit/hop-count fields…”.
Are we talking about AODVv2-specific fields, or something that RFC5444 “owns”,
but allows applications to set? If it’s the latter, then I really don’t
understand how multiplexing works (this would seem to be a circular argument
much like the ‘TTL’ field everyone haggled about earlier).

I like the notion of using MAX_METRIC, and completely taking this issue off the
table.

Regards,
Stan

From: aodvv2-discuss-bounce@xxxxxxxxxxxxx
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Victoria Mercieca
Sent: Wednesday, November 18, 2015 10:03 AM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: regeneration vs forwarding

Hi Stan, hope you're well!

Well... we are allowed to set these fields...so we can use them for our own
purposes since they are part of the AODVv2 message...at least we thought we
could set and use them as we like...but Thomas seems to think this
inappropriate.

If we dont use them, we dont have the concept of "network diameter", and a
maximum number of hops allowed in a route discovery. Unless we are using the
hopcount metric type, in which case the test for MAX_METRIC accomplishes this
anyway. In fact for any cost metric type, MAX_METRIC accomplishes this type of
limit...

...so maybe we can do away with the msg_hop_count and msg_hop_limit fields, set
them to 1 every time? Unless I'm forgetting something else.....
Regards,
Vicky


On Wed, Nov 18, 2015 at 2:36 PM, Ratliff, Stanley
<sratliff@xxxxxxxxxxx<mailto:sratliff@xxxxxxxxxxx>> wrote:
Vicky,

As I read the comment, RFC5444 hop-limit/hop-count just flat don’t work,
because the message is (effectively) “generated anew” at each hop. The document
may call it “regenerated”, but fact is it’s a “new packet” – not something that
we’ve just noticed as it flew by, but something that is effectively consumed,
then a fresh (and potentially modified) copy is issued again.

That being the case, I don’t understand how the hop count is anything other
than ‘1’. Each and every time.

Regards,
Stan


From:
aodvv2-discuss-bounce@xxxxxxxxxxxxx<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>]
On Behalf Of Victoria Mercieca
Sent: Wednesday, November 18, 2015 4:53 AM
To: aodvv2-discuss@xxxxxxxxxxxxx<mailto:aodvv2-discuss@xxxxxxxxxxxxx>
Subject: [aodvv2-discuss] regeneration vs forwarding

Hi all,
Regarding Thomas comments on this subject in the email to MANET overnight
(below).
I thought we took this decision to "regenerate" since for RREQ and RREP, we may
add TLVs (AckReq, ValidityTime) or remove TLVs (AckReq), and because we change
the metric in the message. In RERR we remove addresses (and associated TLVs)
that there is no point re-reporting, i.e. Unreachable Addresses that didnt
affect any of our own routes.

Somewhere in the back of my mind there was some statement that when using
RFC5444 we shouldnt change anything other than header fields of a message when
forwarding it... but now I cant find where that was written. Since we are
changing the metric, and potentially adding or removing TLVs, was the problem
that it would affect the value in an ICV field?
The changes we make to the message content are:

* 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
* AckReq only applies between hops, so needs to be removed or added
accordingly.
* ValidityTime could potentially be added at any intermediate router that
wishes to limit the time it will forward packets on the route.
* Stripping out Unreachable Addresses from RERR which did not affect our
route set.
Picking one particular comment from Thomas Clausen's email:
"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."
I think we only really use these to test if the message has exceeded
MAX_HOPCOUNT, i.e. the diameter of the network?
Regards,
Vicky.


---------- Forwarded message ----------
From: Thomas Clausen <ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>>
Date: Wed, Nov 18, 2015 at 1:35 AM
Subject: Re: [manet] draft-ietf-manet-aodvv2-12 and draft-ietf-manet-dlep-17
To: "Ratliff, Stanley" <sratliff@xxxxxxxxxxx<mailto:sratliff@xxxxxxxxxxx>>
Cc: "manet@xxxxxxxx<mailto:manet@xxxxxxxx>"
<manet@xxxxxxxx<mailto:manet@xxxxxxxx>>
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
<sratliff@xxxxxxxxxxx<mailto:sratliff@xxxxxxxxxxx>> 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
manet@xxxxxxxx<mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@xxxxxxxx<mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet


_____________________________________________________
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.
_____________________________________________________


_____________________________________________________
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.
_____________________________________________________

Other related posts: