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

From: Ulrich Herberg <[email-masked]>
Date: Mon, 25 Apr 2016 08:51:21 -0700

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.

---

From: Victoria Mercieca <[email-masked]>
Date: Mon, 25 Apr 2016 18:21:41 +0100

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:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 25 Apr 2016 19:39:28 -0700

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:
> Each intermediate hop adds the cost of the link from itself back to the last
> router which forwarded the message.
>
> 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.
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 26 Apr 2016 08:44:01 +0000

If you also change metrics in an RREQ (which if you want to establish asymmetric metrics both ends to each other is logical) what actually now is the difference between an RREQ and an RREP. (Even if you multicast one and unicast the other, or multicast both but one only on one interface, that’s not a difference in the message.) Of course you may need to know which one a particular message is, but anything else? (Sorry, meant to say if you separate out the RREQ_Ack mechanism and assuming no intermediate validity times.)

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: Victoria Mercieca [mailto:[email-masked]]
Sent: 25 April 2016 18:22
To: Ulrich Herberg
Cc: Thomas Heide Clausen; Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Symmetric link metrics (was: Re: Message integrity and message mutability)

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
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]<mailto:[email-masked]>> wrote:
Hi,

Best regards
Ulrich

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Victoria Mercieca <[email-masked]>
Date: Tue, 26 Apr 2016 11:29:35 +0100

Interesting question...We already do change metrics in the RREQ so that
every intermediate router learns the metric of the route to OrigAddr.

If we don't include ValidityTime or AckReq in the RREP, then its use is
pretty similar to RREQ. Are you thinking we could use one message type and
judge from the contents of it whether its a request or a reply?
i.e. if its got OrigSeqNum its a RREQ, if its got TargSeqNum its a RREP?
But this would make it impossible for an extension where you might want to
include both seqnums. Would there be similar arguments against using the
presence of OrigMetric to signal it's a RREQ? Or would you introduce a flag
somewhere indicating that it's a request or a response?

Kind regards,
Victoria.

On Tue, Apr 26, 2016 at 9:44 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> If you also change metrics in an RREQ (which if you want to establish
> asymmetric metrics both ends to each other is logical) what actually now is
> the difference between an RREQ and an RREP. (Even if you multicast one and
> unicast the other, or multicast both but one only on one interface, that’s
> not a difference in the message.) Of course you may need to know which one
> a particular message is, but anything else? (Sorry, meant to say if you
> separate out the RREQ_Ack mechanism and assuming no intermediate validity
> times.)
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> www.baesystems.com/ai
> *From:* Victoria Mercieca [mailto:[email-masked]]
> *Sent:* 25 April 2016 18:22
> *To:* Ulrich Herberg
> *Cc:* Thomas Heide Clausen; Dearlove, Christopher (UK); Christopher
> Dearlove; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Symmetric link metrics (was: Re: Message integrity
> and message mutability)
>
>
>
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> * Consider carefully whether you should click on any links, open any
> attachments or reply. For information regarding **Red Flags** that you
> can look out for in emails you receive, click here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
> 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.
>
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 26 Apr 2016 10:54:21 +0000

Whether to use one message type is one issue - but I think we’re agreed that you will probably need to know which it is from the message itself. Which is a tradeoff of the use of a message type (currently not an issue if using experimental suggestions only - I’m not sure if that is agreed or not) and the minimum to otherwise indicate that (which is a three octet TLV I think - definitely in the message type specific space, as it’s hard to think of anything more message type specific.

But possibly as important is that where RREQs and RREPs are essentially the same, even if different message types, there’s one description of what they do that is common. Again, maybe there already is, I don’t know.

From: Victoria Mercieca [mailto:[email-masked]]
Sent: 26 April 2016 11:30
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; Thomas Heide Clausen; Christopher Dearlove; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Symmetric link metrics (was: Re: Message integrity and message mutability)

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Interesting question...We already do change metrics in the RREQ so that every intermediate router learns the metric of the route to OrigAddr.
If we don't include ValidityTime or AckReq in the RREP, then its use is pretty similar to RREQ. Are you thinking we could use one message type and judge from the contents of it whether its a request or a reply?
i.e. if its got OrigSeqNum its a RREQ, if its got TargSeqNum its a RREP? But this would make it impossible for an extension where you might want to include both seqnums. Would there be similar arguments against using the presence of OrigMetric to signal it's a RREQ? Or would you introduce a flag somewhere indicating that it's a request or a response?
Kind regards,
Victoria.

On Tue, Apr 26, 2016 at 9:44 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
If you also change metrics in an RREQ (which if you want to establish asymmetric metrics both ends to each other is logical) what actually now is the difference between an RREQ and an RREP. (Even if you multicast one and unicast the other, or multicast both but one only on one interface, that’s not a difference in the message.) Of course you may need to know which one a particular message is, but anything else? (Sorry, meant to say if you separate out the RREQ_Ack mechanism and assuming no intermediate validity times.)

T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>

From: Victoria Mercieca [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 25 April 2016 18:22
To: Ulrich Herberg
Cc: Thomas Heide Clausen; Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Symmetric link metrics (was: Re: Message integrity and message mutability)

*** WARNING ***

Kind regards,
Victoria.

Best regards
Ulrich