Subject: Re: [manet] Symmetric link metrics (was: Re: Message integrity and message mutability)

From: Victoria Mercieca <[email-masked]>
Date: Mon, 2 May 2016 03:41:33 +0100

Hi Ulrich,

Thank you for your review. I noticed you mentioned metrics again, so I had
a further think about this.

Since we are requesting a route from OrigAddr to TargAddr, we want the
metric to be optimised in that direction, so we are currently adding
incoming link costs at each hop of the RREQ's path, so that RREP_Gen will
learn a route to OrigPrefx that represents the best path in the direction
from OrigAddr to TargAddr, and will forward the RREP back along the reverse
of that best path. However, this does mean that the metric learned at
RREP_Gen for the route to OrigPrefix is for the wrong direction - it's the
cost we actually want to install at RREQ_Gen on the route to TargPrefix.

I think we may need to accumulate metrics for both directions in the RREQ,
updating at each hop. This allows two things:
- RREP_Gen can choose to install the best route back to OrigAddr based on
the outgoing metrics backwards along the route of the RREQ
- RREP_Gen can send the RREP backwards via the routers which had the best
incoming cost in the RREQ (this info would be in the Multicast Route
Message Table), rather than along the installed route to OrigPrefix, which
could be different.

Then in the RREP, we still need to include the incrementing metric value to
add up the metrics of each hop looking back toward TargPrefix. So RREQ_Gen
and all intermediate routers learn the cost in the direction
OrigAddr->TargAddr.

Should we include a metric value OrigMetric associated with OrigPrefix to
indicate the real cost of the path backwards to OrigPrefix, and another
metric TargMetric associated with TargAddr to indicate the accumulated cost
in the direction from OrigAddr towards TargAddr? At RREP_Gen, install a
route to OrigPrefix with OrigMetric. Then, since TargMetric represents the
cost of the path from Orig->Targ, use the Multicast Route Message Table
(which will store the RREQ with the lowest TargMetric), and decide to send
the RREP via the neighbor which advertised the lowest TargMetric?

Kind regards,
Victoria.

On Tue, Apr 26, 2016 at 3:39 AM, Ulrich Herberg <[email-masked]> wrote:

> Yes, something along that line. But I'd have to review the precise
> updates required to the draft.
>
> Best regards
> Ulrich
>
> On Mon, Apr 25, 2016 at 10:21 AM, Victoria Mercieca
> <[email-masked]> wrote:
> > Hi Ulrich,
> >
> > Do we just need to add up link costs looking backwards to where the
> message
> > came from? Back toward OrigAddr in a RREQ, back toward TargAddr in a
> RREP?
> > Each intermediate hop adds the cost of the link from itself back to the
> last
> > router which forwarded the message.
> >
> > At RREP_Gen we would end up with the route cost looking in the correct
> > direction from RREP_Gen back to OrigAddr, along the reverse of the route
> the
> > RREQ took (although that's not necessarily the optimal route to
> OrigAddr),
> > and at RREQ_Gen we would get the route cost along the optimal route which
> > the RREQ travelled on, from RREQ_Gen to TargAddr.
> >
> > Kind regards,
> > Victoria.
> >
> > On Mon, Apr 25, 2016 at 4:51 PM, Ulrich Herberg <[email-masked]>
> wrote:
> >>
> >> Hi,
> >>
> >> I am in the process of reviewing the AODVv2 draft, and like Thomas, I
> >> was surprised about your conclusion to move "asymmetric links" out of
> >> scope of AODVv2. Most (if not all) wireless networks that I have seen
> >> include asymmetric links. I don't think it's a good idea moving this
> >> out of the protocol.
> >>
> >> Best regards
> >> Ulrich
> >>
> >> On Mon, Apr 25, 2016 at 7:18 AM,  <[email-masked]> wrote:
> >> >[...]
> >> > Since we’re discussing bi-directionality of links here, and the
> >> > necessity of
> >> > a mechanism for handling these, I want to call attention to a related
> >> > issue,
> >> > as I hinted previously.
> >> >
> >> > The abstract states that the protocol:
> >> >
> >> >    ...is intended for use by mobile routers in wireless, multihop
> >> >    networks.
> >> >
> >> >
> >> > Section 5 paragraph 4  of the document, however, reads:
> >> >
> >> >    Assuming link metrics are symmetric, the cost of the routes
> installed
> >> >    in the Local Route Set at each router will be correct.  While this
> >> >    assumption is not always correct, calculating incoming/outgoing
> >> >    metric data is outside of scope of this document.
> >> >
> >> >
> >> > I do not know of any wireless systems, where the assumption that “link
> >> > metrics are symmetric” actually holds. Consequently, the conclusion in
> >> > the
> >> > quoted paragraph:
> >> >
> >> >
> >> >    calculating incoming/outgoing
> >> >    metric data is outside of scope of this document.
> >> >
> >> >
> >> > Is not an acceptable design choice.
> >> >
> >> > While this protocol may not want to “calculate if for this link the
> >> > metrics
> >> > is 4 or 5”, the protocol must be able to convey and distinguish that
> >> > “the
> >> > metric from A to B is 4, and the metric from B to A is 19”.
> >> >
> >> > This is a “related issue” since the solution may (as with the
> >> > bi-directionality check) be in the triggered neighbour detection
> >> > mechanism:
> >> > that exchange could, if designed carefully, be used to probe for and
> >> > convey
> >> > metrics information, also.
> >>
> >> _______________________________________________
> >> manet mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/manet
> >
> >
>