[Roll] [roll] #131: draft-ietf-roll-trickle-mcast-04 - Parameter-IMAX-equal-to-IMIX

["roll issue tracker" <[e-mail]>]

#131: draft-ietf-roll-trickle-mcast-04 - Parameter-IMAX-equal-to-IMIX

 From: Kerry Lynn <kerlyn at ieee.org

 Regarding the definition of DATA_MESSAGE_IMAX, RFC 6206 seems
 to suggest that this parameter should be described as the number of
 doublings of Imin: "For example, a protocol might define Imax as 16."
 If this interpretation is correct, then DATA_MESSAGE_IMAX should be
 set to 0 in order to limit Imax to Imin.

 Similarly, CONTROL_MESSAGE_IMAX should be set to an integer
 number of doublings, or at least specified in terms of worst-case link-
 layer latency if my interpretation of RFC 6202 is incorrect.

 The implication of specifying Imax = Imin seems to be that the dithering
 interval for MPL Data Message re-transmission will *always* be [Imin/2,
 Imin) == DATA_MESSAGE_K (since DATA_MESSAGE_IMIN is specified
 as 2*DATA_MESSAGE_K).  This has the effect of setting k == infinity,
 which is presumably the point for specifying the default values as they
 are.

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg07845.html

 From Kerry

 In addition to the comments I made previously, I am concerned that the
 default for Imax (== Imin) prevents the Trickle timer interval I from ever
 doubling.  Combined with a high k, this leads to aggressive Trickle
 forwarding
 in dense parts of the mesh that may inhibit (by interfering with) unicast
 responses in transit to the original sender.  Is there a reason for not
 relaxing DATA_MESSAGE_IMAX to e.g.
 DATA_MESSAGE_TIMER_EXPIRATIONS?

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg07849.html

 From Peter

 Their recommended values very much depend on the timing characteristics of
 the application and the topology of the network. I think it is more
 appropriate to have these values cited in the applicability statements (if
 they are focused enough).

 Coming back to simulation c.q. operation results:
 I can well imagine that with a network that is loaded for a few percent of
 the time with mpl messages the value of k is not that important. I can
 also imagine that at the edge of networks with a strongly varying density
 of repeaters, it is possible that some nodes at the edge only receive
 messages with a given regularity when k is infinity. In the applications
 that I consider the density of repeaters is quite homogeneous, the end to
 end delays are expressed in hundreds of milliseconds and multiple seeds
 generate messages on a (tens of) seconds scale. In that case k=1 is often
 excellent and a higher k is not recommended.

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg07857.html

 From AB

 I agree with the below message proposal, and to add that I think this
 I-D should define the trickle parameters not leaving them for open
 test. I think IMAX should not equal IMIN [1] for this protocol, but
 mostly tests will proof best. IMO, the use of trickle parameter to
 make change in MPL forwarding is better than enabling transit node to
 change option content [2], Could transit nodes change trickle
 parameter value when that chg bit is 1, but not change option content?

 [I-D>Abstract] Different Trickle parameter configurations allow MPL to
 trade between dissemination latency and transmission efficiency.
 [AB] The I-D does not show parameter values/relations/equations, how
 can I test their consistency with the protocol?

 [1] http://www.ietf.org/mail-archive/web/roll/current/msg07887.html
 [2] http://www.ietf.org/mail-archive/web/roll/current/msg07880.html

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg07899.html

 From Philip Levis


 I worry a bit about the default value for DATA_MESSAGE_IMAX. Setting IMAX
 to the same as IMIN misses one very useful property of exponentially
 increasing timers, which is that they quickly find the right randomization
 interval under heavy congestion. The original motivation for the
 exponential timer in Trickle was to find the right randomization interval
 (much as, say, Ethernet CSMA/CD does). The challenge with having IMAX
 equal IMIN is that if IMIN is too small, you'll end up with a lot of
 congestion and link-layer collisions.

 I don't think this needs any change to the document because it's just a
 default. If experience and practice shows that you don't want IMAX to be
 equal to IMIN, then I'm sure people will adjust best practices and
 recommendations appropriately. Just wanted to point out that keeping an
 eye on this might be valuable.

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg07887.html

-- 
---------------------------------------+-----------------------------
 Reporter:  [e-mail]  |      Owner:  [e-mail]
     Type:  defect                     |     Status:  new
 Priority:  major                      |  Milestone:
Component:  trickle-mcast              |    Version:
 Severity:  In WG Last Call            |   Keywords:
---------------------------------------+-----------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/131>
roll <http://tools.ietf.org/wg/roll/>