Subject: [manet] my olsrv2-multipath notes

From: Justin Dean <[email-masked]>
Date: Tue, 24 Mar 2015 11:55:09 -0500

There are language issues throughout the document which need addressing.
These are quite numerous and wouldn't be appropriate to address them all in
a list email.

Bullet point in introduction regarding FEC coding isn't fully correct.
Multi-path can help FEC encoding but isn't a requirement (packets can get
lost in all sorts of ways and in all kinds of distributions). FEC coding
can work with ANY of them and work, provided the code aligns to the loss
patterns.  Having multiple paths can help select a better encoding for
better performance but it's not a requirement.

In the applicability statement it's mentioned that no new messages are
introduced to OLSRv2 which is true but misleading as message tlv types are
introduced and required.  This should also be stated at this time or
earlier.  Some mention of source route headers being applied to each packet
also needs to happen here along with the appropriate RFC references
(RFC0791 and RFC6554)

Protocol Overview and Functioning section needs a little bit of
reorganizing. Here is how I would do it:  OLSRv2 and NHDP are used
with TLVs added to messages, identifying MP-OLSRv2 functionality.
Multi-path routes are invoked on demand. Multi-path algorithms choices.
Source routing headers are used based on these multiple paths.

HELLO and TC messages section.  Some mention of WHY TLVs are required
should be done (i.e. if you add an address of an OLSRv2 only router in a
source route header you're gonna have a bad time)

HELLO and TC Message Generation: change "is" to "MUST be" A single
Message-Type-Specific TLV with Type := MP_OLSRv2 MUST be added to the
message....actually the TLV only needs to be added if the router is willing
to participate in the source routing.  There is nothing broken with a non
MP-OLSRv2 (plain OLSRv2) router from implementing the source routing when
other MP-OLSRv2 routers exist.  Should this be allowed?  I say yes but then
more clarity is needed on what is appropriate and what isn't.

Multi-path Dijkstra Algorithm:  As this is an experimental protocol and the
algorithm choice doesn't effect any functionality of other parts of the
network I think it would be appropriate to have a default method but allow
for other algorithm choices.  The requirements if any and likely good
quality of what paths an algorithm selects should be presented.

Security Considerations should also reference source forwarding security
documents not just manet related security documents.

Justin

---

From: Jiazi YI <[email-masked]>
Date: Sat, 28 Mar 2015 00:52:29 +0100

Dear Justin,

> better performance but it's not a requirement.

We didn't mean to say that FEC requires multi-path routing.  Maybe "The
single path routing is not adapted " used is too strong. We will rephrase
it.

> also needs to happen here along with the appropriate RFC references

Yes, agree.

> Source routing headers are used based on these multiple paths.

Agree.

> source route header you're gonna have a bad time)

Will do.

> more clarity is needed on what is appropriate and what isn't.

We will clarify it in the next revision.

>
> Multi-path Dijkstra Algorithm:  As this is an experimental protocol and
> the algorithm choice doesn't effect any functionality of other parts of the

It's a good point. We will have the multipath-dijkstra algorithm as the
default algorithm, and also allow other alternatives. Different approaches
of the multipath computing can be an experiment point also.

> documents not just manet related security documents.

Yes. I'm thinking about having the Security Consideration section of RFC
6554 (An IPv6 Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks) and RFC 5095 (Deprecation of Type 0
Routing Headers in IPv6). Those two describe the security issues related to
IP source routing.

Regarding the language issue, we (a French and a Chinese as co-authors :)
will do our best -- and try to find some help from native English speakers.

A new revision will be submitted afterwards.

regards

Jiazi

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

---

From: Frank Fitzek <[email-masked]>
Date: Sat, 28 Mar 2015 15:54:58 +0100

Dear all,

I am very pleased to see multi path support for MANET coming. I have 
attend some of the last meetings of MANET and intend to come to Prague 
and I would be happy to hear more about the multi path initiative.

My reasearch group has a strong interest in coding for multi path MANET. 
We already used network coding for the BATMAN routing protocol (single 
route), but see even more potential for multi path approaches (where 
each path is composed out of multi hops).

In case you are not familiar with network coding, here a small example 
why it will impact any multi hop system.

Consider the following topology with one source S sending to the 
destination D over three hops with different error probabilities

S <--- e1 ---> R1 <--- e2 ---> R2 <--- e3 ---> D

A standard FEC end to end code would need to send enough packets for a 
COMBINED error 1 - (1-e1)(1-e2)(1-e3). Here S is doing the endcoding, 
and D the decoding.

If we use network coding and allow the relays to recode, the combined 
error is just 1 - min((1-e1);(1-e2);(1-e3). This means the performance 
is determined by the worst performing hop but not the full chain. 
Therefore less packets are used for such a system.

For multipath we get even bigger gains, but they are harder to describe 
here in a short email.

Maybe you find this interesting and we can talk about this here on the 
mailing list or in Prague.

All the best
FF

Am 28.03.2015 um 00:52 schrieb Jiazi YI:
>     Bullet point in introduction regarding FEC coding isn't fully
>     correct.  Multi-path can help FEC encoding but isn't a requirement
>     (packets can get lost in all sorts of ways and in all kinds of
>     distributions). FEC coding can work with ANY of them and work,
>     provided the code aligns to the loss patterns.  Having multiple
>     paths can help select a better encoding for better performance but
>     it's not a requirement.
>
>
> We didn't mean to say that FEC requires multi-path routing.  Maybe 
> "The single path routing is not adapted " used is too strong. We will 
> rephrase it.
>
>
>     In the applicability statement it's mentioned that no new messages
>     are introduced to OLSRv2 which is true but misleading as message
>     tlv types are introduced and required.  This should also be stated
>     at this time or earlier.  Some mention of source route headers
>     being applied to each packet also needs to happen here along with
>     the appropriate RFC references (RFC0791 and RFC6554)
>
>
> Yes, agree.
>
>
>     Multi-path routes are invoked on demand. Multi-path algorithms
>     choices. Source routing headers are used based on these multiple
>     paths.
>
>
> Agree.
>
>
>     HELLO and TC messages section.  Some mention of WHY TLVs are
>     required should be done (i.e. if you add an address of an OLSRv2
>     only router in a source route header you're gonna have a bad time)
>
>
> Will do.
>
>
>     Message-Type-Specific TLV with Type := MP_OLSRv2 MUST be added to
>     the message....actually the TLV only needs to be added if the
>     router is willing to participate in the source routing.  There is
>     nothing broken with a non MP-OLSRv2 (plain OLSRv2) router from
>     implementing the source routing when other MP-OLSRv2 routers
>     exist.  Should this be allowed?  I say yes but then more clarity
>     is needed on what is appropriate and what isn't.
>
>
>     Multi-path Dijkstra Algorithm:  As this is an experimental
>     protocol and the algorithm choice doesn't effect any functionality
>     of other parts of the network I think it would be appropriate to
>     have a default method but allow for other algorithm choices.  The
>     requirements if any and likely good quality of what paths an
>     algorithm selects should be presented.
>
>
> It's a good point. We will have the multipath-dijkstra algorithm as 
> the default algorithm, and also allow other alternatives. Different 
> approaches of the multipath computing can be an experiment point also.
>
>
>     Security Considerations should also reference source forwarding
>     security documents not just manet related security documents.
>
>
> Yes. I'm thinking about having the Security Consideration section of 
> RFC 6554 (An IPv6 Routing Header for Source Routes with the Routing 
> Protocol for Low-Power and Lossy Networks) and RFC 5095 (Deprecation 
> of Type 0 Routing Headers in IPv6). Those two describe the security 
> issues related to IP source routing.
>
> Regarding the language issue, we (a French and a Chinese as co-authors 
> :) will do our best -- and try to find some help from native English 
> speakers.
>
>     [email-masked] <mailto:[email-masked]>

-- 
Frank Fitzek
Professor
Chair of Communication Networks
Institute of Communication Technology
TU Dresden

phone:  +49 351 463 33945
fax:    +49 351 463 37163
mobile: +49 173 548 2947
web:    www.fitzek.net
skype:	fitzek

5G Lab Germany Coordinator 5Glab.de