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

[Abdussalam Baryun <[e-mail]>]

On Thu, Jul 27, 2023 at 4:13 PM Christopher Dearlove <
[e-mail]> wrote:

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

the third avenues is experimental as OLSRv1, AODVv1, and MT-OLSRv2 which we
have done before, and then proposed standard. STURP can do the same.
However, IMHO the STURP is better to be proposed experimental and not
proposed standard.

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

we still have time the charter does accept that we do OLSRv2 informationals.


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

STURP does not have to be dependent on OLSRv2, so the better approach to
make it independent, so it is proposing for integrating manet routings. If
the authors amend that statements from their draft then yes we can propose
the approaches of backward compatibilities.


> 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 MANET use cases there is a need for hybrid routing that uses Proactive
(like OLSRv1, OLSRv2, MT-OLSRv2, other) and Reactive (like DSRv1, AODVv1,
AODVv2) protocols, so this STURP maybe looking at hybrid routing approach
which is needed, and OLSRv2 cannot solve those hybrid_usecases.


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

>From the draft-00 and presentation of STURP, the authors are not modifying
OLSRv2, but using its services/informations, as we see our DLEP services
are used by other routing protocols,

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

Agree,

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


I don't think it is ready for adoption it is very unclear so far but was
interesting for the WG to look into integrations,



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

The WG also owned the reactive protocol wg_AODVv2_proposed_standard_draft,
but was stopped before for some reasons, and I would ask WG chairs to
restart it again to correct/review and submit it if possible.

AB