Subject: [manet] About olsrv2-multipath, following the discussion on IETF90 meeting

From: Jiazi YI <[email-masked]>
Date: Wed, 23 Jul 2014 11:56:39 +0200

Hi,

Thanks very much for the discussion on olsrv2-multipath during the meeting.
I would like to add a few words regarding the comments during the
discussions.

o Why do multipath routing in MANET, rather than other WGs?

The olsrv2-multipath is an extension of OLSRv2. Based on our experience,
multipath is more interesting if the topology is dynamic, or link breakage
is frequent. In fact, the simulation results (in which the link is assumed
relatively stable) show that the performance is very close between the two
in static scenarios. The performance gain is much more interesting in
dynamic networks.

o Source routing?

The olsrv2-multipath uses IP source routing (loose source routing for IPv4,
RFC6553 for IPv6), so that it can be interoperable with OLSRv2 and its
other extensions (such as new metrics, multi-topology, etc.).
Theres nothing inherently preventing other mechanism for 'forcing traffic
along certain paths' -- for example, one could imagine setting up a
label-switched path for each path in a multi-path flow, if such was
desired. It might be a good idea for the next version of the I-D to
indicate this, although we do not have any operational experiences with
this. It might be an interesting expansion to the document, and to the
experiment it is to enable, to try to understand which other ways of
'forcing traffic along certain paths' are valid. Adrian, thank you for
 triggering those thoughts.

o Multipath for re-active protocols?

I know that there have been several proposals that published as academic
papers. But I have to point out that the way doing multi-path for re-active
protocols is very different for pro-active protocols.
For pro-active protocol, we have already a topology map of the network, so
it's much simpler to calculate desired paths. In re-active protocol, to
obtain enough information to get multiple paths, more route discovery
messages are required, which might cause unpredictable behaviours.
I remember in the IETF Maastricht, there was a presentation about
multipath-dymo using multiple interfaces. That was totally a different way
compared to this olsrv2-multipath draft, and has special layer 2
requirements (such as multiple interfaces).

The draft is aimed to be a light-weight extension of OLSRv2 -- and it is,
regarding its size: 16 pages in total -- and if you cut the references,
implementation status, copy right, etc, you have less than 10 pages to read
:)

Please review the document, the authors are very eager to incorporate your
comments. As I heard it (granted, I attended remotely) there was a single
hum 'against' adopting the document. The authors are actually quite excited
about that, since divergent opinions is a source for inspiration:  what's
the reason for the 'hum against'? Anything in the document that can be done
better, or which in your opinion and experience would 'break the internet'
or be sub-optimal? If you could elaborate, then that would allow
improvements, which would be immensely helpful.

Of course, if you want to 'anonymize' by way of relaying through the chairs
or the ADs, that's quite alright -- our objective is to build the best
possible OLSRv2 extension possible, so through whichever form your opinion
is relayed, it's valuable to us, and we want to express our appreciation."

The work behind this draft was developed more than a decade ago, and has
existed and been improved for years, with very interesting outcome. Thanks
to the multiple open-source implementations in different platforms, the
protocol has been tested by different researchers, engineers all over the
world. We believe it's time to have it clearly specified, and published as
an experimental RFC.

We've been holding back pushing for this, since we felt that OLSRv2 -- with
its support for IPV6, and for security, and for extensibility -- should be
finalized before pushing for extensions like this.

regards

Jiazi

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jul 2014 14:09:43 +0200

On Wed, Jul 23, 2014 at 11:56 AM, Jiazi YI <[email-masked]> wrote:

>
> o Source routing?
>
> The olsrv2-multipath uses IP source routing (loose source routing for
> IPv4, RFC6553 for IPv6), so that it can be interoperable with OLSRv2 and
> its other extensions (such as new metrics, multi-topology, etc.).

I think you need to show more OLSRv2 use cases than show what does OLSR use
of multipath or IP also we should not mention many other issues like
multitopology (makes it worse).

AB

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jul 2014 14:17:04 +0200

> multitopology (makes it worse).

I think you should work on the structure of this sentence, I am not
sure what you mean.

Henning Rogge

---

From: Jiazi YI <[email-masked]>
Date: Mon, 28 Jul 2014 18:21:14 +0200

Dear all,

In recent days, I have got lot of questions, comments and suggestions on
the draft (mainly off the list). Thanks very much for all the reviews and
discussions. They helps a lot for improving the draft!

Some of the issues are raised multiple times.  I think it would be helpful
to summarise some of them, because some of you might have the same
questions/concerns also.
A new revision of the draft will be made soon, to clarify/address the
issues.

 o Strict source routing or loose source routing?

   Using strict source routing or loose source routing depends on the
number of hops of the route, and the existence of OLSRv2 routers (without
multipath support).
   There is a parameter MAX_SRC_HOPS that defines the maximum number of
hops allowed in the source routing header (by default, it is set to 10 so
as to avoid exceeding the maximum IPv4 header length). If the calculated
path is less than MAX_SRC_HOPS, then it's strict source routing -- or else,
loose source routing.
Another case of loose source routing is used is that, there are OLSRv2
routers in the calculated paths. Those routers must not be included in the
source routing header.

 o If loose source routing, how the "key" routers are selected?

There are several basic rules for being a "key" router:
- The key router must be a MP-OLSR Router, so that it can handle the
swapping operation correctly.
- Without further information (such as routers with higher priority, or
routers to be avoided), they are uniformly chosen in the calculated paths.
- If there are some MP-OLSR routers with greater capacity (such as bigger
WILLINGNESS value), they should be firstly chosen.

We will clarify those rules in the new revision of the draft, and put
"smarter choice of key routers" in the "experiments to be conducted"
section. Note that, as long as the first rule is followed, there is no
issue of interoperability.

 o Overhead because of source routing?

   It inevitable that certain overhead is introduced because of IP source
routing. However, with loose source routing and compression mechanisms in
IPv6, the overhead is limited.
   This multipath extension (probably OLSRv2 also?) is not for low power
and lossy networks. At least, in the scenarios that we faced, adding ~30
octets in the header is quite acceptable.

 o Ambiguities because of loose source routing?

   The loose source routing is used if: 1) the path length is longer than
MAX_SRC_HOPS; 2) There are OLSRv2 routers in the paths.
   For the first case, with our experience, a maximum of 10 hops to define
the route can already provide good enough granularity, given the number of
paths is normally less than 4.
   For the second case, if there are router that don't support multipath,
there are possibilities that the datagrams don't follow exactly the the
paths calculated. This is a compromise of OLSRv2 and MP-OLSRv2 mixed
networks.
   When we are talking about interoperability with OLSRv2, it doesn't mean
that the network can provide the same performance as all the routers
support this multipath extension, but the network won't break with mixed
routers, and provide as least the same performance as OLSRv2.

 o In some documents, such as RFC2991, discussed the concerns like variable
latencies and packet reordering.

   Although the issues discussed in RFC2991 (the forwarder potentially has
several next-hops for any given destination) are not exactly the same as
this extension, the flow is splited among multiple paths also.
   It's true that splitting a flow would cause packet ordering problems in
some scenarios. But in dynamic ad hoc networks, it can bring improvements.
   If you have 2 more minutes to check in detail, I uploaded an old
revision of one of the references
http://jiaziyi.com/documents/MPOLSR_old.pdf  (in the published version,
some figures are removed because some of the reviewers think it's too
verbose :)
   You can go to figure 13 directly, which gives the average jitter in a
simple and stable scenario. You can see that MP-OLSR do has larger jitter
in this kind of scenarios.
   However, if we go to dynamic scenarios, as shown in figure 15, the
MP-OLSR has actually less average latency variation. There is one more
paragraph explaining it following the figure 15, if you are interested.

 o Some services prefer flow-by-flow distribution, so it would be helpful
to use multipath for certain services, and normal OLSRv2 for the others.

   This is actually a very good idea. Because with our experiences, we know
well multipath routing can bring benefits for some applications (especially
audio/video transmissions), but it's probably not the case for every
services. Then it would be helpful to specify that the applications can
decide if multipath routing is used, by using DiffServ code point, etc.

 o Why end-to-end path? Why not allow each router to make its own decision?

There are issues with hop-by-hop multipath:
- Potential loops;
- More serious delay variations, because datagrams can be forwarded by much
more different routers;
- No guarantee of disjointness.
The reasons that end-to-end source route based approach is use are:
- In some scenarios, there are requirements that certain router must (or
must not) be used;
- By having control of the paths, the delay can be provisioned;
- An very important application of this extension is Forward Error
Correction coding. For example, we encode two data packets into 3
projections with certain redundancies, and then transmit the 3 projections
into the three disjoint paths. At the final destination, we need only 2
projections to recover the original 2 data packets --- even one of the
projections is lost. This method is not very efficient for single path
router, because the packet drop is normally continuous for a single path:
if all the 3 projections are lost, we can do nothing about it.

 o Is gateway to other routing domain supported?

   On this aspect, MP-OLSRv2 has no difference with OLSRv2. So yes.

 o Some of the implementations mentioned in the "Implementation Status" are
OLSR version 1?

   Yes. There have been a lot of work when OLSRv2 is not well-known. In
fact, the basic algorithm of multipath routing has no difference for OLSR
and OLSRv2. Therefore, the performance studies are valid for both
protocols. Given there are also a lot of OLSR networks running in the
field, we believe it would be beneficial to have all the implementations.
Actually, in the queries that we got regarding multipath routing, there are
more based on OLSR version 1 :)

Again, thanks for all the valuable comments, and we are looking forward to
your further feedback.

regards

Jiazi

On Wed, Jul 23, 2014 at 11:56 AM, Jiazi YI <[email-masked]> wrote:

> Hi,
>
> Thanks very much for the discussion on olsrv2-multipath during the
> meeting. I would like to add a few words regarding the comments during the
> discussions.
>
> Of course, if you want to 'anonymize' by way of relaying through the
> chairs or the ADs, that's quite alright -- our objective is to build the
> best possible OLSRv2 extension possible, so through whichever form your
> opinion is relayed, it's valuable to us, and we want to express our
> appreciation."
>
> We've been holding back pushing for this, since we felt that OLSRv2 --
> with its support for IPV6, and for security, and for extensibility --
> should be finalized before pushing for extensions like this.
>
> regards
>
> Jiazi
>
>