Re: [manet] draft-ietf-manet-olsrv2-multipath-08

["Dearlove, Christopher (UK)" <[e-mail]>]

Comments CMD> below.

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

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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: [e-mail] [mailto:[e-mail]] On Behalf Of Jiazi YI
Sent: 23 May 2016 23:10
To: Dearlove, Christopher (UK)
Cc: [e-mail]
Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-08


*** 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 Chris,

thanks very much for your comments. Please check my reply inline:

On Mon, May 23, 2016 at 2:55 PM, Dearlove, Christopher (UK) <[e-mail]<mailto:[e-mail]>> wrote:
Was away last week, but managed to read through and red-ink the multipath draft. I have some more detailed notes on it, but here - and all I’ll get to right now - are my headline comments.

Editorially, if this came from the usual OLSRv2 authors, we’d be doing some work to make it a better fit to the style of the rest of the OLSRv2 suite. It’s not bad, it just could be a bit better. For example what are listed as Information Bases aren’t, they are Protocol Sets. Together they might form a new Information Base, or be added to one. And more.

As you might have noticed, we try to make the style fit to the OLSRv2-related RFCs. If you have more specific comments, we would glad to make it better. Of course, we will check the style by ourselves also.

CMD> Later for this one.

There are also various other points that I’d make. For example, it says not just for hop count. Given that OLSRv2 is not just for hop count, I wouldn’t emphasis this. And I don’t know why MP-OLSRv2 is indicated as being suitable especially for low data rate links.

Because the specification uses parallel paths, which can provide higher aggregated throughput.

CMD> Not convinced by that argument. You’re going to gain a factor of maybe two or three at most (and only if the network is differentially loaded - at worst you lose, not gain) whereas when I see low data rate paths, that can vary by orders of magnitude.

Technically, my first issue is that OLSRv2 distributes a partial topology, so this is working at a disadvantage. OK, but this isn’t discussed, and - with the one exception of picking MPRs - tradeoffs of the incompleteness of the topology and overheads aren’t even discussed. For a start, TC messages contain advertised neighbours. Advertised neighbours must include all MPR selectors, but may include more neighbours - up to all neighbours. I would expect a discussion of this. (I’m also not actually sure how good the alternative MPR heuristics are, that’s me needing to read and think more.)

In a pure MP-OLSRv2 network, no modification is required regarding the MPR selection. Because the routers choose MPRs independently, and the MPR-selection is non-optimal, we can obtain multiple paths in most cases thanks to the topology redundancy. This has been proven in both simulation study and field tests with various node densities.

CMD> References? And even if so, I would expect a discussion of the subject. And that still doesn’t address the advertised neighbours issue.

I don’t understand (I may have missed) how SR_TC_INTERVAL is used. But the description in 5.1 isn’t clear. Why would we have separate TC messages? And why would MP be prepared to do anything ten times slower?

This is to deal with the OLSRv2/MP-OLSRv2 mixed network. As we mentioned in our previous post, an MP-OLSR router can be recognized as source-enabled unless it generates a HELLO or TC message. So what we do is:
   - MP-OLSR enabled routers MUST generate TC messages even it's not required to do so according to normal OLSR process, but with longer interval. This is because the change from MP-OLSR enabled to OLSR-only router is very rare compared to topology changes. The corresponding SR_OLSR_HOLD_TIME will be set to longer value also.
    - During routing MPR selection, an MP-OLSR enabled router SHOULD be firstly considered. The number of MP-OLSR enabled MPRs MUST be equal or greater than NUMBER_OF_PATHS, providing there are enough MP-OLSR symmetric neighbors. Or else, all the MP-OLSR routers are selected as MPR.

 CMD> Not happy with that. That assumes in effect that multipath routes are more stable - because that’d what sending ten times less often means. And if you are sending ten times less often, that will require ten times the validity time. Which will cause those links to hang around longer, and will be used by non-MP routers in the same way. (It’s even possible that a compliant implementation might choose to preferentially use links with longer validity times, all else being equal. I’ve never tried that, but it’s an obvious possibility in some heterogeneous networks.) If ten times longer is OK for some links, why not all? I think there’s a problem here - how much work with highly mobile mixed networks has been done?

I’ve been critical of AODVv2 underspecifying interaction with IP. I’m going to make the same criticism here, given the suggestion of a reactive multi-path route determination. I’m actually not keen on that idea at all, I think it needs more discussion.

The MP-OLSR is a bit different from AODVv2 -- the route calculation is local. It doesn't require DSR/AODV-like route discovery/route reply (which can have long delay). Therefore, no buffer (or very little buffer) is required: the packet is either sent out or dropped. I think there is no need to go to details on how to trigger the route calculation, which is implementation specific.
Then for the source routing part, it's just standard IP routing.

CMD> No, it’s introduced something new to OLSRv2, the need to be triggered by IP. Somebody (Henning?) criticising AODVv2 made the observation this isn’t actually easy to do. And it’s new to OLSRv2, and unnecessary. I’m strongly against this as a specification.

Note that as this is local, you could choose to do this locally if you wanted to and still interoperate. I wouldn’t be as set against this as an option in a highly resource limited router. But as the only specification, that must be done this way? No. I’m against this draft proceeding with this as the only option.

It also, I think, is broken in that there is no indication of how and when these paths are expired. This alone I think requires a new draft.

In fact, in the previous revision (-06), there is a valid time field in the multi-path routing set. But it's removed to match RFC7181-style based on the comments received (because Routing Set in RFC7181 is not based on timer-based expiration either). All the tuples in the Multi-path Routing Set will be removed whenever there is need to update the OLSRv2 Routing Set. This can make it more reactive to topology changes.
We will clarify it in the next revision.

Yes, it needs clarification however the set is created, proactively or reactively.

But there’s more. If proactive, when it expires, it actually is replaced. (The Routing Set in OLSRv2 is described as recalculated, but of course intelligent differential update is not just allowed but a good idea.) But reactive? Are you going to remove it and re-trigger its calculation from IP? Or how otherwise to decide when to stop recalculating it?
And before that discussion on whether a reactive mechanism that OLSRv2 otherwise doesn’t have is acceptable. (I don’t think it is.)

Personally, I don't see why it's not acceptable. Here I just want to note that this is an experimental draft. As far as I can see, if we have:

   - a clear specification
   - a mechanism that can bring potential performance benefit and won't break existed networks
   - some simulation study and implementation that prove the idea actually works and can be implemented (the implementation is even not mandatory to standard track protocol -- although I think it's not a good policy)
   - people interested in the idea

we already have good reason to move ahead?

CMD> I don’t agree. A specification fills a space. A poor specification is hard to push aside if a better one comes along. And I think a mandatory reactive mechanism in a multipath OLSrv2 is poor. And it’s easily addressed, define how you calculate it, make the norm that you maintain (as the normal Routing Set) but (if you want to) allow a reactive alternative (where you can send rather than drop - I see no reason to drop - using the standard Routing Set in the interim.

I’m not as familiar as I should be with loose source routing. Given that this protocol allows routes of non-minimum metric, is there any possibility of the interaction of the two allowing looping, especially with different routers having possibly different views of the topology?

When loose source routing is used, the forwarding decision is based on the forwarding table generated by OLSRv2. So if there is a loop, it's a loop in OLSRv2 (which is possible, due to attacks or high dynamic topology).

CMD> That’s one of those non-proof arguments that I’m not sure of. I can’t see an infinite loop, but the slack in the process means suppose you have A - B - C - D - E loosely routed, and now you need to go from B to C. Is it possible for D to be on the shortest path from B to C?

Some sort of proof (which might already exist) would be a good idea here. Incidentally why does the multiplicative factor on route metrics (CUTOFF_RATIO) have to be strictly greater than one? One should work.

The description of the multipath Dijkstra doesn’t really explain fp and fe. With the appendix one begins to get an idea, but the main text should not depend on an appendix in that way. And those are defined parameters, not an example.

will clarify the description.

and thanks again for the comments.

regards

Jiazi



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

T:  [phone]<tel:%2B44%20%280%291245%20242194>  |  E: [e-mail]<mailto:[e-mail]>

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


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

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