non-symmetric links

[Lotterleben]

Also brought up by Justin. I remember multiple members of the WG saying that simply declaring non-symmetric links out of scope doesn't cut it since non-symmetric links are fairly common. At the least, I guess we need to come up with a solid response to this.

[Lotterleben]

See also this thread: https://www.ietf.org/mail-archive/web/manet/current/msg18873.html

[Lotterleben]

And from Ulrichs review:

• As outlined in my email [1], I don't agree with the assumption in AODVv2 that most wireless links are symmetric. In my observations, the opposite is the case. Vicky outlined some intended changes to address this, but this will likely be a larger redesign of the mechanism for calculating and using metrics.

[1] https://www.ietf.org/mail-archive/web/manet/current/msg18873.html

[charliep51]

Hello folks,

We have a draft to be submitted to [roll] which tackles this issue. For AODVv2 it has always been the case that some asymmetry was admissible.
We already know that it's impossible to get a static measurement for this anyway, and a link that was good a moment ago can be bad now.

For a very long time the answer has been that we should just do the best we can do, and I am happy with that answer. Solving it for AODVv2 now would take us far afield and I would suggest we rely on guidance from Alvaro on this point. I am happy to lead the discussion with Alvaro, but first let's get the other resolvable issues resolved.

Regards, Charlie P.

On 5/17/2016 2:53 PM, Lotte Steenbrink wrote:

And from Ulrichs review:

  * As outlined in my email [1], I don't agree with the assumption
    in AODVv2 that most wireless links are symmetric. In my
    observations, the opposite is the case. Vicky outlined some
    intended changes to address this, but this will likely be a
    larger redesign of the mechanism for calculating and using
    metrics.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/Lotterleben/AODVv2-Draft/issues/18#issuecomment-219865894

[charliep51]

Hello again folks,

Related to this point, Emmanuel and I have a draft to [int-area] that is currently in Last Call. I would greatly appreciate if you would support publication of that draft. It's short and hopefully easy to read, and you already know everything in it -- but some people do not.

The draft can be found at the following URL: https://datatracker.ietf.org/doc/draft-ietf-intarea-adhoc-wireless-com/

Your comments and support will be very helpful. I would be very happy to answer any questions you might have!

Regards, Charlie P.

On 5/17/2016 2:53 PM, Lotte Steenbrink wrote:

And from Ulrichs review:

  * As outlined in my email [1], I don't agree with the assumption
    in AODVv2 that most wireless links are symmetric. In my
    observations, the opposite is the case. Vicky outlined some
    intended changes to address this, but this will likely be a
    larger redesign of the mechanism for calculating and using
    metrics.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/Lotterleben/AODVv2-Draft/issues/18#issuecomment-219865894

[pv0]

In terms of directional metrics, I think we state that we add up incoming metrics...? I forget the exact details, but I think this means that when intermediate routers handling the RREQ install the route to OrigPrefix, it has a metric on it which reflects the path in the direction from OrigPrefix toward TargPrefix... i.e. the wrong direction to put with the route to OrigPrefix. But we need that sum of incoming costs to know which is the best return route for sending the RREP. In the RREP we could add up outgoing costs back toward TargAddr (I dont think we currently do that?). Then the all routers handling the RREP learn the cost toward TargAddr correctly.

So the first problem would still exist: intermediate nodes don't always learn the correct metric for a route to OrigPrefix, since we are optimising for the requested route. I wonder if we could mark the route learned via RREQ as a "non-optimal" route, maybe indicated by a particular metric value, e.g. MAX_METRIC? The intermediate routers would still forward the RREQ the same way, using the accumulated incoming link costs. So RREP_Gen would still be able to determine the best path on which to send the RREP, by checking where the best RREQ came from in its RteMsg table. And all routers would have a route to OrigAddr which is good enough to send the RREP back, but since it's also marked to say "this isnt optimal, maybe you should send a RREQ if you want to find out a decent route to this address from your perspective, i.e. if some of your router clients need that route". It could be optional behaviour to do that extra RREQ. But this approach would avoid us having routes installed using a metric value calculated for the wrong direction.

[Lotterleben]

In terms of directional metrics, I think we state that we add up incoming metrics...? I forget the exact details, but I think this means that when intermediate routers handling the RREQ install the route to OrigPrefix, it has a metric on it which reflects the path in the direction from OrigPrefix toward TargPrefix... i.e. the wrong direction to put with the route to OrigPrefix. But we need that sum of incoming costs to know which is the best return route for sending the RREP. In the RREP we could add up outgoing costs back toward TargAddr (I dont think we currently do that?). Then the all routers handling the RREP learn the cost toward TargAddr correctly.

afaik we don't currently do that but we've discussed the option of having this additional metric info, didn't we? Including it sounds reasonable to me, but maybe we could make it optional...

So the first problem would still exist: intermediate nodes don't always learn the correct metric for a route to OrigPrefix, since we are optimising for the requested route. I wonder if we could mark the route learned via RREQ as a "non-optimal" route, maybe indicated by a particular metric value, e.g. MAX_METRIC? The intermediate routers would still forward the RREQ the same way, using the accumulated incoming link costs. So RREP_Gen would still be able to determine the best path on which to send the RREP, by checking where the best RREQ came from in its RteMsg table. And all routers would have a route to OrigAddr which is good enough to send the RREP back, but since it's also marked to say "this isnt optimal, maybe you should send a RREQ if you want to find out a decent route to this address from your perspective, i.e. if some of your router clients need that route". It could be optional behaviour to do that extra RREQ. But this approach would avoid us having routes installed using a metric value calculated for the wrong direction.

Jut thinking aloud: What happens if an intermediate router has flushed its RteMsg Table (i.e. the Multicast Route Message Set?) before the RREP arrives? It would still be able to use a route back to OrigAddr, even though it has been marked as maybe not optimal, wouldn't it?

[pv0]

For the first paragraph, it wouldnt be additional metric info i.e. extra bytes in the message, it would be accumulating incoming link costs in RREQ but outgoing costs in RREPs.

For the second, you're right, if the RteMsg table was flushed, there is a route to OrigAddr which could be used. In that case, the route that RREQ_Gen learns might or might not not be optimal, but would allow traffic to be sent in either case.