Subject: [manet] OLSRv2 + RFC6971

From: Ulrich Herberg <[email-masked]>
Date: Wed, 5 Mar 2014 13:48:10 +0000

Thomas,

I apologize that your last presentation slot fell under the table today
because of lack of time. As this work interests me personally (as editor of
RFC6971), can I ask you to give a bit of context on the mailing list? The
slides are already in the proceedings, so they are available for download
(as I mentioned as part of the OLSRv2 + extensions package).

Thanks
Ulrich

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 5 Mar 2014 17:47:51 +0100

Dear Ulrich, all,

On 05 Mar 2014, at 14:48 , Ulrich Herberg <[email-masked]> wrote:

> Thomas,
> I apologize that your last presentation slot fell under the table today because of lack of time.

Such are the rules of the game: time is at a premium in face to face meetings, and it was more important to spend that time to discuss WG items and new items that might be immediate actions for the WG. This presentation was "for your information" (the "collective your", that is).

>  As this work interests me personally (as editor of RFC6971), can I ask you to give a bit of context on the mailing list? The slides are already in the proceedings, so they are available for download (as I mentioned as part of the OLSRv2 + extensions package).
> 
> Thanks
> Ulrich

A bit of context: RFC6971 - also know as DFF, among friends - is an experimental mechanism which works below the IP layer and above the link layer. It's raison d'etre is to improve data delivery in case the intended next-hop (as indicated by the routing table) is somehow not reachable, and do so before a routing protocol "catches up" and repairs the routing topology. DFF does this by way of (at the router from where the next hop was not reachable) engaging a "depth first forwarding" mechanism. I'll let you read the RFC for further details, but my colleagues and I thought it a quite clever trick.

Consequently, we went ahead and implemented it and tested it, with both LOADng and OLSRv2.

We tested across two scenarios: one MANET with highly (artificially) lossy links, but otherwise no router mobility; another MANET with "normal" links but with router mobility. 

The slides contain simulation results for LOADng in a MANET with intentionally lossy links -- whereas for OLSRv2, the results displayed in the slides are from the MANET with router mobility. There's really no significance to the choice of which scenario for which protocol, other than to - precisely - not engage in routing protocol comparisons here....that's NOT the goal, and so we want to steer the discussion around that potential rathole by way of the results presented.

We actually didn't try to be particularly clever in what we did in integrating DFF with the two protocols: there are more fancy heuristics possible than those we implemented, especially for when using DFF with OLSRv2. Even so the results turned out interesting: improved data delivery rates across the board, and no (observed, at least) harmful effects. 

(OK, we did try to be a little bit clever by inventing an extension to DFF, which we called DFF++ -- but it's possible to be even more clever than that, with a little effort)

From the  OLSRv2-results, we chose the catchphrase (and the title of the presentation) "success before convergence" since it turned out that the combination OLSRv2+DFF enabled data delivery "success" across the last couple of hops while the (HELLO) message exchange of OLSRv2 was catching up with a local topology change due to router mobility.

But, look at the results in the presentation (and, perhaps, the papers cited in the presentation with more data), and judge for yourself. Actually, I'll be even more user-friendly than Ulrich, and throw in (for free) a link to the slides here:

	http://tools.ietf.org/agenda/89/slides/slides-89-manet-7.pdf

Now, we thought it interesting to bring these results to the attention of the WG for the following reasons:

	o	It helps both LOADng and OLSRv2, and in both scenarios where there are packet losses 
		on the links and when the topology changes dynamically due to mobility

	o	It's relatively simple to implement

	o	It doesn't entail any additional control signals

	o	It doesn't require any modifications to the routing protocols

Given that RFC6971 is an *experimental* RFC, we thought that we would bring the results of our *experiments* to the attention of the IETF; after all, that's the whole point of the IEF publishing *experimental* RFCs ...

At this juncture, we'd much hope that our initial results are interesting enough to encourage others to experiment with this mechanism, and to report back in a similar vein. 

Also at this juncture, we're not actually suggesting any WG actions to be taken.

We would suggest - and, of course, yield to the decision of the WG chairs on this matter - that this WG and mailing list might be a place to report and discuss such experiments and results, for when applying DFF in conjunction with MANET routing protocols?

Longer-term, and depending on how the experiments progress, there may be things that could be considered for WG actions. These may include bringing DFF towards standards track, documenting DFF++, documenting more "clever heuristics" than what we did initially (as informational documents) if some turn out to be particularly useful (or, conversely, documenting heuristics that turn out to be particularly harmful), etc. 

I'm glad that Ulrich "came out of the closet" as the editor of RFC6971, since that gives me an excuse to hive answering questions to the intricate details of DFF off to him: the mechanism is dead-simple, but the reasoning behind it has its details that he's probably a lot better equipped to answer questions to, than am I.

Hope this answers your question, triggers interest, and gets all y'all a-coding, such that we may have more data to mull over soon.

Best,

Thomas

---

From: Joe Macker <[email-masked]>
Date: Wed, 5 Mar 2014 15:55:18 -0500

The DFF interactions and concepts are interesting thanks for sharing the recent results.
As I read through it I can definitely see where more DFF++ ideas could happen.

-Joe

On Mar 5, 2014, at 11:47 AM, Thomas Heide Clausen <[email-masked]> wrote:

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 5 Mar 2014 22:06:27 +0100

Hi Thomas and Ulrich,

I reviewed the RFC before and know from previous simulation experience its
importance to MANET. However, I have seen that it may add some overhead
with mobile routers issue but better with packet losses issue.  I add my
interest to discuss the use of DFF with mostly OLSRv2.

AB

On Wednesday, March 5, 2014, Thomas Heide Clausen wrote:

> Dear Ulrich, all,
>
>
> On 05 Mar 2014, at 14:48 , Ulrich Herberg <[email-masked]<javascript:;>>
> wrote:
>
> > Thomas,
> because of lack of time.
> Such are the rules of the game: time is at a premium in face to face
> meetings, and it was more important to spend that time to discuss WG items
> and new items that might be immediate actions for the WG. This presentation
> was "for your information" (the "collective your", that is).
>
>
> >  As this work interests me personally (as editor of RFC6971), can I ask
> you to give a bit of context on the mailing list? The slides are already in
> the proceedings, so they are available for download (as I mentioned as part
> of the OLSRv2 + extensions package).
> >
> > Thanks
> > Ulrich
>
>
> A bit of context: RFC6971 - also know as DFF, among friends - is an
> experimental mechanism which works below the IP layer and above the link
> layer. It's raison d'etre is to improve data delivery in case the intended
> next-hop (as indicated by the routing table) is somehow not reachable, and
> do so before a routing protocol "catches up" and repairs the routing
> topology. DFF does this by way of (at the router from where the next hop
> was not reachable) engaging a "depth first forwarding" mechanism. I'll let
> you read the RFC for further details, but my colleagues and I thought it a
> quite clever trick.
>
> We tested across two scenarios: one MANET with highly (artificially) lossy
> links, but otherwise no router mobility; another MANET with "normal" links
> but with router mobility.
>
> The slides contain simulation results for LOADng in a MANET with
> intentionally lossy links -- whereas for OLSRv2, the results displayed in
> the slides are from the MANET with router mobility. There's really no
> significance to the choice of which scenario for which protocol, other than
> to - precisely - not engage in routing protocol comparisons here....that's
> NOT the goal, and so we want to steer the discussion around that potential
> rathole by way of the results presented.
>
> We actually didn't try to be particularly clever in what we did in
> integrating DFF with the two protocols: there are more fancy heuristics
> possible than those we implemented, especially for when using DFF with
> OLSRv2. Even so the results turned out interesting: improved data delivery
> rates across the board, and no (observed, at least) harmful effects.
>
> (OK, we did try to be a little bit clever by inventing an extension to
> DFF, which we called DFF++ -- but it's possible to be even more clever than
> that, with a little effort)
>
> From the  OLSRv2-results, we chose the catchphrase (and the title of the
> presentation) "success before convergence" since it turned out that the
> combination OLSRv2+DFF enabled data delivery "success" across the last
> couple of hops while the (HELLO) message exchange of OLSRv2 was catching up
> with a local topology change due to router mobility.
>
> But, look at the results in the presentation (and, perhaps, the papers
> cited in the presentation with more data), and judge for yourself.
> Actually, I'll be even more user-friendly than Ulrich, and throw in (for
> free) a link to the slides here:
>
> Given that RFC6971 is an *experimental* RFC, we thought that we would
> bring the results of our *experiments* to the attention of the IETF; after
> all, that's the whole point of the IEF publishing *experimental* RFCs ...
>
> At this juncture, we'd much hope that our initial results are interesting
> enough to encourage others to experiment with this mechanism, and to report
> back in a similar vein.
>
> We would suggest - and, of course, yield to the decision of the WG chairs
> on this matter - that this WG and mailing list might be a place to report
> and discuss such experiments and results, for when applying DFF in
> conjunction with MANET routing protocols?
>
> Longer-term, and depending on how the experiments progress, there may be
> things that could be considered for WG actions. These may include bringing
> DFF towards standards track, documenting DFF++, documenting more "clever
> heuristics" than what we did initially (as informational documents) if some
> turn out to be particularly useful (or, conversely, documenting heuristics
> that turn out to be particularly harmful), etc.
>
> I'm glad that Ulrich "came out of the closet" as the editor of RFC6971,
> since that gives me an excuse to hive answering questions to the intricate
> details of DFF off to him: the mechanism is dead-simple, but the reasoning
> behind it has its details that he's probably a lot better equipped to
> answer questions to, than am I.
>
> Hope this answers your question, triggers interest, and gets all y'all
> a-coding, such that we may have more data to mull over soon.
>
> Best,
>
> Thomas
>
>
> [email-masked] <javascript:;>

---

From: Jiazi YI <[email-masked]>
Date: Wed, 5 Mar 2014 22:26:28 +0100

As one can imagine, the performance of DFF is directly related to the order
of Candidate Next Hop List (CNHL).

The The DFF++ is proposed to improve the issue. The advantage of DFF++ is:

  o It doesn't require additional signaling in the air;
  o Therefore, it wouldn't affect compatibility;
  o It just need one additional field in the CNHL - no additional memory is
required.

The limitations are:

  o The DFF++ won't work for the "very first packet"
  o It could provide the optimal path, but a "workable" path.

More ideas about improving the order of CNHL are appreciated.

cheers

Jiazi

On Wed, Mar 5, 2014 at 9:55 PM, Joe Macker <[email-masked]> wrote:

> > We tested across two scenarios: one MANET with highly (artificially)
> lossy links, but otherwise no router mobility; another MANET with "normal"
> links but with router mobility.
> >
> > At this juncture, we'd much hope that our initial results are
> interesting enough to encourage others to experiment with this mechanism,
> and to report back in a similar vein.
> >
> > We would suggest - and, of course, yield to the decision of the WG
> chairs on this matter - that this WG and mailing list might be a place to
> report and discuss such experiments and results, for when applying DFF in