Agreed, Yatch.

Can the authors have a look and propose a resolution?

Then we'll see how to publish the fix.

Many thanks

Pascal

> -----Original Message-----
> From: Yasuyuki Tanaka <[email protected]>
> Sent: mardi 28 août 2018 10:56
> To: Pascal Thubert (pthubert) <[email protected]>
> Cc: Yasuyuki Tanaka <[email protected]>; [email protected]
> Subject: Re: [6tisch] Questions on RPL Settings in RFC 8180
> 
> Hi Pascal,
> 
> pascal> Maybe we could amend/ERRATA the RFC to recommend different
> settings.
> 
> It'd be nice to have some amendment or an errata entry for the following
> sentence.
> 
> rfc8180> (5.3.  Trickle Timer, RFC 8180)
> rfc8180>
> rfc8180> For this specification, the Trickle timer MUST be used with the
> rfc8180> RPL-defined default values (see Section 8.3.1 of [RFC6550]).
> 
> At least, "MUST" in this sentence should be replaced with something, in my
> opinion.
> 
> Best,
> Yatch
> 
> 
> > On Aug 27, 2018, at 17:45, Pascal Thubert (pthubert) <[email protected]>
> wrote:
> >
> > Starting a discussion on your last point, Yatch:
> >
> > RFC 6206 says:
> >
> > "
> >   Finally, a protocol SHOULD set k and Imin such that Imin is at least
> >   two to three times as long as it takes to transmit k packets.
> > "
> > By default k n RPL is set to very conservative
> DEFAULT_DIO_REDUNDANCY_CONSTANT of 10, so there is not suppression
> unless there is a high density.
> > So with the 1.01s slotframe, RFC 6206 recommends that Imin should be 20
> to 30 seconds...
> >
> > Maybe we could amend/ERRATA the RFC to recommend different settings.
> >
> > What do others think?
> >
> > Pascal
> >
> >> -----Original Message-----
> >> From: Pascal Thubert (pthubert)
> >> Sent: lundi 27 août 2018 17:29
> >> To: 'Yasuyuki Tanaka' <[email protected]>; [email protected]
> >> Subject: RE: [6tisch] Questions on RPL Settings in RFC 8180
> >>
> >> Hello Yatch
> >>>
> >>> (1) Rank Computation
> >>>
> >>> RFC 8180 says:
> >>>
> >>> rfc8180> 5.1.1.  Rank Computation
> >>> rfc8180> (...)
> >>> rfc8180> Sp SHOULD be calculated as (3*ETX)-2.  The minimum value of
> >>> rfc8180> Sp
> >>> rfc8180> (MINIMUM_STEP_OF_RANK) indicates a good quality link.  The
> >>> rfc8180> maximum value of Sp (MAXIMUM_STEP_OF_RANK) indicates a
> poor
> >>> rfc8180> quality link.  The default value of Sp
> >>> rfc8180> (DEFAULT_STEP_OF_RANK) indicates an average quality link.
> >>> rfc8180> Candidate parents with ETX greater than 3 SHOULD NOT be
> selected.
> >>>
> >>>  https://tools.ietf.org/html/rfc8180#section-5.1.1
> >>>
> >>> MAXIMUM_STEP_OF_RANK is defined to 9. Why?
> >>>
> >> [PT>] This is defined in OF0. 9 denotes a worst possible quality that
> >> is still acceptable and makes it equivalent to 9 hops at the best
> >> quality for that technology.
> >> The number enables 7 hops at the worst rank factor (4) and with the
> >> worst quality.
> >>
> >>
> >>> Sp is calculated as (3 * ETX) - 2 and the worst acceptable ETX is 3.
> >>> It looks like 7 is the possible largest value of Sp...
> >>>
> >> [PT>] True, so we never reach 9 and stay compatible with OF0. I guess
> >> the max ETX of 3 is arbitrary, we could have gone up to 11/3...
> >>
> >>
> >>> (2) Trickle Timer
> >>>
> >>> RFC 8180 says:
> >>>
> >>> rfc8180> 5.3.  Trickle Timer
> >>> rfc8180> (...)
> >>> rfc8180> For this specification, the Trickle timer MUST be used with
> >>> rfc8180> the RPL-defined default values (see Section 8.3.1 of [RFC6550]).
> >>>
> >>>  https://tools.ietf.org/html/rfc8180#section-5.3
> >>>
> >>> So, Imin for DIO Trickle timer starts with 8 ms, which looks too
> >>> short for the minimal TSCH schedule where one shared cell in a
> >>> slotframe of 1.01s. This setting could cause congestion by DIO traffic...
> >>>
> >>> Why is this default value (DEFAULT_DIO_INTERVAL_MIN) reasonable for
> >>> the 6TiSCH minimal configuration...?
> >> [PT>]
> >> [PT>] I agree that this needs discussion. Note that the minimal
> >> schedule of 1.01s is just an example.
> >> The initial value of I (see RFC 6206) is between Imin and Imax. With
> >> the default, that is between 8ms and 2.3 hours. Hopefully I is not
> >> always 8ms! The DIO will not fire before I/2.
> >> I agree we should use a somewhat higher Imin, but then that pushes
> >> Imax to the say and I may be set to that.
> >> IOW I'd have liked to restraint the initial setting of I to something
> >> in between, like between a few seconds and a few minutes while
> >> keeping Imax to 2^20 times Imin.
> >>
> >> Take care,
> >>
> >> Pascal
> >>> _______________________________________________
> >>> 6tisch mailing list
> >>> [email protected]
> >>> https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to