Subject: [Roll] call for adoption of forw-select draft

From: peter van der Stok <[email-masked]>
Date: Mon, 21 Nov 2016 12:29:19 +0100

Dear all,

(This is the call for adoption for the *forw-select* document.)

During the Wednesday meeting of the WG, we've discussed three drafts, 
which address items we have in our charter. We've had three 
raise-of-hands in the room, with support for the adoption of the 
documents. You can find the minutes at the following address:
https://datatracker.ietf.org/doc/minutes-97-roll/

We are now moving the call for adoption to the mailing list and will be 
closing the call in two weeks (on December 6th, 2016).

This is the call for adoption for " MPL Forwarder Select (MPLFS)" 
draft-vanderstok-roll-mpl-forw-select-01
Please read the draft and reply to the list with your comments, remarks, 
suggestions and votes on the adoption of this document.

Many thanks for your reaction,

Ines and Peter

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Nov 2016 11:47:25 +0000

I support this adoption. The work presents a new optimization and opens new applications to MPL

Regards,

Pascal

> Le 21 nov. 2016 à 12:29, peter van der Stok <[email-masked]> a écrit :
> 
> Dear all,
> 
> During the Wednesday meeting of the WG, we've discussed three drafts, which address items we have in our charter. We've had three raise-of-hands in the room, with support for the adoption of the documents. You can find the minutes at the following address:
> We are now moving the call for adoption to the mailing list and will be closing the call in two weeks (on December 6th, 2016).
> 
> This is the call for adoption for " MPL Forwarder Select (MPLFS)" draft-vanderstok-roll-mpl-forw-select-01
> Please read the draft and reply to the list with your comments, remarks, suggestions and votes on the adoption of this document.
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 21 Nov 2016 20:48:57 +0900

I support the adoption as well.

Regards,
Rahul

On 21 Nov 2016 4:59 p.m., "peter van der Stok" <[email-masked]> wrote:

> which address items we have in our charter. We've had three raise-of-hands
> in the room, with support for the adoption of the documents. You can find
> the minutes at the following address:

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Mon, 21 Nov 2016 14:53:18 +0100

Hi all,

Is there any publication about MPLFS performance?

I think MPL itself is well designed. The communication rate of MPL
scales logarithmically with density; it's not bad. Redundant traffic
by MPL contributes reliable data delivery. To my knowledge, the lower
packet loss rate is, the less redundant traffic is generated. That's
also a nice property.

I'm curious how much MPLFS can reduce the total amount of traffic with
preserving communication reliability.

Best,
Yatch

---

From: peter van der Stok <[email-masked]>
Date: Tue, 22 Nov 2016 09:22:14 +0100

Hi Yatch,

Indeed these are interesting questions.
Some back of envelope calculations help.
Assume a n-hop network and no losses.
assume number of MPL intervals is n_I
Total time of transmitting a single multicast is given by
n-hop*I-min + 2^(n_I-1)*I_min
Numer of messages per forwarder is n_I

Give the example 1 in my presentation that gives a 2-hop network 
producing
81*n_I messages when all nodes are forwarder
and 3*n_I messages with the 3 selected forwarders

Set n_I to 2, which yields 162 messages versus 6 messages.
For lighting control an I-min of 20 ms is reasonable.
Total time period is 20*2 + 3*20 gives 100 ms. Other examples can be 
done similarly to get an order of magnitude.

I did a simulation on a 3x15 network (4 hops maximum) with all 45 nodes 
forwarders or only 10 forwarders.
with 10 forwarders 3 times as many messages could be sent without losses 
as with all 45 nodes as forwarders.

Hope this helps,

greetings,

peter

Yasuyuki Tanaka schreef op 2016-11-21 14:53:
>> We are now moving the call for adoption to the mailing list and will 
>> be closing the call in two weeks (on December 6th, 2016).
>> 
>> Please read the draft and reply to the list with your comments, 
>> remarks, suggestions and votes on the adoption of this document.
>>

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 23 Nov 2016 16:04:30 +0100

Thank you, Peter!
Sorry for this late response...

> Assume a n-hop network and no losses.  assume number of MPL
> intervals is n_I Total time of transmitting a single multicast is
> given by n-hop*I-min + 2^(n_I-1)*I_min Numer of messages per
> forwarder is n_I

Honestly speaking, I couldn't understand the formula well... But, I
guess, your point here is that the more hops, the longer time for a
multicast to traverse a network. Therefore, you want to decrease the
number of hops in order to deliver a multicast packet quickly, don't
you?

I think there is a misunderstanding about the number of messages. You
can reduce messages by enabling message suppression. Supposing
DATA_MESSAGE_K defined in RFC 7731 is set to one, a forwarder will
suppress forwarding a multicast packet if it receives the same packet
before its time t, time to forward the packet.

I'm so interested in this kind of topic that I ran a couple of small
simulations with my MPL implementation using the same node assignment
as Example 1 in the presentation. The node at the top-left corner
sends a multicast packet, it is a MPL Seed. All other 80 nodes are
configured as MPL forwarders, no packet loss, n_I
(DATA_MESSAGE_TIMER_EXPIRATIONS) is set to 2, Imin (DATA_MESSAGE_IMIN)
is 20 msec or 500 msec. The MPL Seed sends one multicast packet 30
seconds after a simulation starts.

Here is the result. The packet delay is time between when the MPL Seed
sent a packet and when a last MPL forwarder received it.

   |               | Imin=20ms | Imin=500ms |
   |---------------+-----------+------------|
   | # of messages | 17        | 11         |
   | packet delay  | 48 msec   | 802 msec   |

Looking at the numbers of messages, they are not as bad as you
mentioned, 162 messages. Suppression happens many times. The reason
why the number of messages in Imin=20 are bigger than Imin=500ms is
that more collision occur in the Imin=20ms case, I suppose.

I think MPLFS could reduce the amount of multicasted application
packets shown above. At the same time, MPLFS would introduce its
control overhead. And, concerns about communication reliability.

I may be wrong, but I'm afraid I'm not sure how much helpful MPLFS
is...

Best,
Yatch

On 2016/11/22 9:22, peter van der Stok wrote:
> Give the example 1 in my presentation that gives a 2-hop network producing
> Total time period is 20*2 + 3*20 gives 100 ms. Other examples can be done similarly to get an order of magnitude.
>
> I did a simulation on a 3x15 network (4 hops maximum) with all 45 nodes forwarders or only 10 forwarders.
> with 10 forwarders 3 times as many messages could be sent without losses as with all 45 nodes as forwarders.
>
> Hope this helps,
>
> greetings,
>
> peter
>
>
>

---

From: peter van der Stok <[email-masked]>
Date: Thu, 24 Nov 2016 09:21:05 +0100

Thanks for this information.

Your results do not correpond with my results.
We noticed that k should be at least 4 in a 4 hop network. (no 
connection between these numbers)
With lower k we got message loss and significant delays, at least at the 
edges, and I_min > 10 ms.
This is confirmed by other people.

The k parameter is great in situations where you do not have significant 
deadllines.
In case of deadlines, the recommendation is to set k to infinity.
For k=inf, MPLFS makes sense.

In my simulations, I set k=4, deadline is 200 ms. 7 < I_min < 40 ms, N-I 
is set to 3, 4, and repetition frequency at seed
is between 10 and 100 ms, with saturation (losses) for  repetition 
interval < 70 ms.
In a multihop network, you will see significant losses after hop 1 with 
k = 2 for example.

>   |               | Imin=20ms | Imin=500ms |

I have analysed what happens at I_min small, and other effects occur as 
well.

Cheerio,

Peter

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 24 Nov 2016 12:19:13 +0100

Hi Peter,

I believe I understand your points better! Thank you.

Summary in my mind is:

  - You assumes k=inf, that's why setting n_I to 2 yields 162 messages
    without MPLFS in Example 1 of the presentation.

  - From your observation, setting k=inf is recommended in a situation
    where there is a certain deadline to deliver a concerned
    application message.

  - In the case of k=inf (no suppression), MPLFS has good effect,
    better effect in a dense network, on reducing the total number of
    multicast messages.

I agree that there needs to be some effort to deal with the deadline
thing in a MPL network. I have some experiment results showing that.
This is one of my interests :-)

My suggestion on this draft is, if the draft assumes k=inf, it'd be
nice to mention that in the text. In addition, having some background
information or discussion in the text, why/where k=inf makes sense,
would be helpful since k=inf is NOT RECOMMENDED by RFC 6206.

    https://tools.ietf.org/html/rfc6206#section-6.5

Best,
Yatch

---

From: peter van der Stok <[email-masked]>
Date: Thu, 24 Nov 2016 14:07:23 +0100

Hi Yatch,

Thanks for this exchange.
Excellent suggestion; I will update the text with some information on k.
This was all more than 2 years ago, and I forgot.

Peter