Subject: Re: [manet] my olsrv2-multipath notes

From: Jiazi YI <[email-masked]>
Date: Sun, 3 May 2015 11:59:04 +0200

Hi,

I'm not an expert in network coding, but it is surely a very interesting
combination with multi-path routing.

I'm not sure I'll be in Prague or not yet -- but in any case, I would be
glad to continue the discussion.

btw, I tried several times to subscribe to the list of network coding
research group (nwcrg), but never get the confirmation. So I'm CCing Brian
also :) Is any action required from the list moderator?

best

Jiazi

On Sat, Mar 28, 2015 at 3:54 PM, Frank Fitzek <[email-masked]>
wrote:

>  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:
>
> Dear Justin,
>
>  Thanks very much for your comments, please check inline:
>
>
>>
>>  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.
>
>
>>
>> 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.
>>
>
>  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.
>
>
>>
>>  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.
>>
>
>  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
>> 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.
>
>  A new revision will be submitted afterwards.
>
>  regards
>
>  Jiazi
>
>
>
>>
>>  Justin
>>
>>
>>
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>
>
> _______________________________________________
> manet mailing [email-masked]://www.ietf.org/mailman/listinfo/manet
>
>
> --
> 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
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Jiazi YI <[email-masked]>
Date: Sun, 3 May 2015 12:12:08 +0200

Hi,

Regarding Justin's comment:

> ....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
I think it's very good point. As far as I can see, a non MP-OLSRv2 router
can be added to the source routing header, as long as it implements
appropriate source routing mechanism.

Then it would be better to change the MP-OLSRv2 TLV (identifying an
MP-OLSRv2 router) to SR-OLSRv2 TLV (identifying an OLSRv2/MP-OLSRv2 router
supporting source routing).
By doing so, more OLSRv2 routers (don't support multi-path but support
source routing) can be used in the source route. Plus, the SR-OLSRv2 TLV is
more general, and could possible used for other purpose.

best

Jiazi