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

[peter van der Stok <[e-mail]>]

Hi Kerry,

some inline comments on your comments.
The questions was: what might go wrong when MPL values are badly chosen.
I tried to describe some most likely causes and effects. No attempt at 
completeness was intended.


Kerry Lynn schreef op 2013-09-19 15:07:
> 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. 

I think a small Imin is sufficient in combination with many sources, 
repeaters and large repeat
Stating Imax =Imin certainly helps. I was referring to an Imin=1 ms.

[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 me it is typical. My deadlines are 200 ms.
I also think that conditions on the installation (density of repeaters, 
bounded network load, source and destination separated by bounded number 
of hops) will go a long way to make deadlines meet.
> 
> for large LLNs.
> 
>  
> 
> 3) packets do not arrive at some destinations
> 
> This is mitigated by larger k.

So choice of k is important
>  
> 
> 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.

As stated earlier. I don't like the worst case latency. With a heavily 
loaded network, MAC buffers > 3, Backoff retries >2, worst case 
latencies can reach hundreds of msec and even seconds.
The transmission time of the packet 3-6 ms can be neglected under those 
circumstances. Concluding, WCL should certainly not be used to set Imin.
However the I-D talks default values and the wording is OK for me.
> 
> Regards, -K-
> 

Greetings
Peter
> 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/ 
> [1]
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll [2]
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll [2]
> 
> 
> 
> Links:
> ------
> [1] http://datatracker.ietf.org/wg/roll/charter/
> [2] https://www.ietf.org/mailman/listinfo/roll