Re: [manet] Draft-lou-manet-sturp-00 Review

[Christopher Dearlove <[e-mail]>]

Putting together my thoughts in more depth, and I hope coherence, than in the MANET meeting or my last message here.

Thanks for the welcome in the meeting.

Let's start with that in order to consider a new ad hoc routing protocol, we should start with what is the problem it solves that we don't already have a solution for.

There was a long period when this WG was more like an IRTF group than an IETF WG, but we came out of it with one Proposed Standard routing protocol, OLSRv2, but fell short on a second, AODVv2. If we want another routing protocol, what does it offer that is new?

STURP is, as I understand it, considering networks where the main changes are routers joining and leaving the network. This might be contrasted with OLSRv2 that can handle highly dynamic networks (the M in MANET) where connections between routers form and break unpredictably.

There are then two avenues STURP could take. One is as a standalone protocol. In that case whether it is worth pursuing that depends on whether we have such networks, and whether we need it.

Here, I'd be interested in input in particular from Henning on the Freifunk network and whether OLSRv2 that it uses (or used the last time I looked at it) is considered to be a large overhead.

Because it's worth noting that OLSRv2 can be used in different ways. One of my regrets is that we ran out of steam before creating an Informational RFC (or other material) that describes all the different ways that OLSRv2 can be used. It has a lot of options, which are there to address various cases, even if those cases aren’t spelled out.

One of those is what we dubbed "responsive" (because reactive was already taken for something else). Rather than use periodic messages - technically use them but with such a long interval that in practice we never send them - we only send messages in response to changes in the neighbourhood, or other changes that indicate this should occur.

Before discussing if this is sufficient, returning to the STURP draft, it suggests modifying OLSRv2. I believe this is the wrong approach. Possibly, ideas from STURP (although actually most are not new) could provide an additional optional feature to OLSRv2. But this should be 100% backward compatible with the current protocol.

Note that this not just about using the RFC 5444 message format - whether an independent STURP should use that is a matter for the WG (but also note RFC 8245).

So if we try using OLSRv2 in fully responsive mode, and a router tries to join the network, what happens?

First, routers in that network need to take advantage of the permissions granted in RFC 7181 and RFC 6130 that they may send messages when circumstances (generally their neighbourhood) changes. Possibly more than once if signalling is unreliable.

Is this sufficient? Actually, not quite. I've been looking at RFC 7181 and running a scenario through.

(If you do, I recommend a network of three routers A - B - C where a fourth router D tries to make it A - B - C - D. I think this is about the simplest case that demonstrates all the essential features.)

And I think there is an omission. (If there isn't, and it's hiding somewhere, please let us know.) It's not a critical omission, because it's fully compatible with OLSRv2, but in the permissions to send additional messages, there's no explicit MAY that says that a router can send a TC message if it identifies, from its Router Topology Set, that a new router has joined the network.

Without that, parts of the network might be invisible to the new router. (In the A - B - C - D network, unless B sends a TC message, A is invisible to D. And B is only visible in the 2-Hop Set.)

Note that managing your network so that parameters and options across the network allow it to function effectively (not just legally) is always an issue, this is just another case. For example when running fully proactively, we need message intervals consistent with router distances and speeds.

There is an alternative - actually adding the additional permission explicitly as well as this would make sense if taking this route. This is that when a router joins the network, it gets a dump of the relevant parts its new neighbour's Topology Information Base to put into its base.

This isn't a new idea, we considered it at the time, but again it was a detail we never got to. In part because it's not trivial. (Note that if you have that feature you would be allowed to use it in other circumstances, but this would probably be the only recommended one.)

You need to define what are the relevant parts of the Topology Information Base and how to encode them in suitable TLVs in an RFC 8245 compatible way. Note that this includes issues such as multiply addressed routers and link metrics. There’s also a significant problem with how to define the validity time of this information, and possibly other details I haven’t thought of yet. There are some good reasons we never did this.

Note that this is a (hypothetical) fully backwardly compatible extension; a router receiving this information but not understanding it can simply ignore it. I’m also not saying this is necessarily a good idea, just that if such a feature is added, this is the OLSRv2-compatible way to do it.

Is this worthwhile? I return to the point about real world use cases. Unless there’s a strong case made in the real world, not just hypothetically, I don’t think it is. (That is of course just my opinion.)

In short, and considering the OLSRv2 case, I do not believe in trying to put STURP into OLSRv2. It completely doesn't fit. (Just as one detail, it gives no thought to link metrics.) But if there's a real use case, there could be - I put it no stronger than that - a motivation to add a topology update TLV to a HELLO message. (It's then also possibly received by routers that don't need it, but that does no harm, and is more efficient.) Any modification should start from OLSRv2 as-is and what trying to achieve. Or if OLSRv2 is not the right vehicle, then consider a stand alone protocol.

But there's a lot of work in an independent STURP too. OLSRv2 is as complicated as it is in large part due to requirements that people had, such as multiple interfaces, multiple addresses per interface, shared addresses, link metrics, attached networks - which I haven't discussed above - and more. Any new routing protocol has to consider which of those apply to it, and handle those that don’t.

As for accepting this as a WG draft, I think that’s at the least, premature. Particularly as it suggests things (such as that STURP in anything like its current form can be applied to existing portals. Note that I’ve concentrated on OLSRv2 not just because I’m familiar with it, but also because it’s (at present) the only standardised routing protocol owned by the WG.