Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05

[Kerry Lynn <[e-mail]>]

Hi Peter,

On Tue, Sep 17, 2013 at 9:37 AM, peter van der Stok <[e-mail]>wrote:

> Hi Michael,
>
>
> Some consequences:
> 1) Too many repeaters with too small Imin and too large repeat leads to
> network congestion (similar to having too high send frequency on several
> sources)
>

The Trickle Algorithm [RFC 6206] calls for exponential growth of Imax for
some number
of intervals in order to spread the offered load over time.  Thus the claim
that it can "scale
to thousand-fold variations in network density".

It is actually the combination of large load, large k, and small *Imax*
that may contribute to
congestion collapse.  When Imax is limited to Imin then your statement is
true.  [RFC 6206]
suggests Imin should be at least 2-3 times the period it takes to transmit
k packets (and
probably double that).  Knowing k, bit rate, and message size (which seemed
to be missing
from your list of variables) it should be possible to determine a
reasonable value for Imin.
For example, an average mDNS lookup may fit in 127 octets but the
worst-case may be
twice that.

2) packets take too long to arrive at all destinations (assuming there is a
> deadline)
>

This is probably not a "typical" case.  It may involve trained installers
to achieve this goal
for large LLNs.


> 3) packets do not arrive at some destinations
>
> This is mitigated by larger k.


> This is comparable with what happens when too many nodes start sending
> unicasts on the mesh.
>
> For me the MPL draft is also OK.
>
> My original comment regarding default Imin values was that they were
defined in terms
of "worst-case latency" for a given data link and I still think this is
vague (perhaps
purposely so).  I think the present draft would be improved by adding a
definition to
section 2:

Worst Case Latency - The period of time for the largest possible MPL Data
Message to
                    be received by any MPL Forwarder in the MPL Domain.

Regards, -K-

>
> Peter
>
>
> Michael Richardson schreef op 2013-09-17 14:26:
>
>> Robert Cragie <[e-mail]> wrote:
>> > On (2):
>>
>> > I agree that all nodes in a MPL Domain MUST agree on a common value. I
>> > don't think any recommended values should be given and it depends on
>> > the applicability.
>>
>> What is the affect on the network if there is a mis-configuration?
>>
>> Can it be detected?  Does the network melt-down?
>>
>> Or is it just a question of multicast not working very well (not reaching
>> all
>> nodes it should)
>> I think that these questions will get asked by reviewers.
>>
>> > In a nutshell - I think draft-ietf-roll-trickle-mcast-**05 is good to
>> go.
>>
>> Thanks.
>>
>> --
>> Michael Richardson <[e-mail]>, Sandelman Software Works
>> IETF ROLL WG co-chair.    http://datatracker.ietf.org/**wg/roll/charter/<http://datatracker.ietf.org/wg/roll/charter/>
>>
>>
>> ______________________________**_________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/**listinfo/roll<https://www.ietf.org/mailman/listinfo/roll>
>>
>
> ______________________________**_________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/roll<https://www.ietf.org/mailman/listinfo/roll>
>