Re: [Roll] Retrying DCO/DAO, retry parameters

[Mirja Kuehlewind <[e-mail]>]

Hi Rahul,

Please see inline.

> On 7. Jul 2019, at 10:29, Rahul Arvind Jadhav <[e-mail]> wrote:
> 
> Hi Mirja,
> 
> Thank you for the ref.
> 
> I would like to confirm my understanding of RFC 8085 in this context (just to check if I am on the same page).
> 
> Section 3.1.3. "Low Data-Volume Applications" in bullet point 2 states that, if the application does not have a way to infer RTT for congestion control handling (because there is no return traffic from the destination), then it states,
> "Such applications SHOULD NOT send more than one UDP datagram every 3 seconds and SHOULD use an even less aggressive rate when possible. Shorter values are likely problematic in many cases.”

Yes, that’s the text I was talking about.

> 
> My inference from above statement is; use as less aggressive rate as possible and whatever the case, cap the sending rate to once per 3 second.
> There is no ref on how 3 second rate was arrived at, so could not get into more details.

Yes, that is a value that is deemed to be safe as the rate is quite low, however, it is well understood that different scenarios have different constraints and it is hard to give an ultimate number.

> 
> In the text that I suggested, the statement, " Thus this could range from 2 sec to 120 seconds depending on the deployment" provides a max/min rate. Do you think I should add something like?
> "Thus this could range from 2 sec to 120 seconds depending on the deployment. In case the latency limits are not known, an implementation SHOULD NOT retry DCO more than once in 3 seconds.”

Yes, that what I was looking for. I think you can even go for "MUST NOT” because this is also restricted to the case where latency limits are unknown. If you want, you can cite RFC8085 to given more reasoning for the exact value, however, you don’t have to.

Do you think it would also be possible to state a clear requirement for the maximum number of retries?

Mirja


> 
> I like this better.
> 
> In your earlier mail, there were two questions, 
> 1. What is the max rate to be used so as not to overload the network?
> 2. What are the usual considerations/reasoning?
> This update and the proposed new para should answer both these questions.
> 
> Kindly let us know your thoughts.
> 
> Thanks,
> Rahul
> 
> 
> 
> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[e-mail]] 
> Sent: 05 July 2019 21:33
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: Rahul Arvind Jadhav <[e-mail]>; Routing Over Low power and Lossy networks <[e-mail]>; Alvaro Retana <[e-mail]>
> Subject: Re: [Roll] Retrying DCO/DAO, retry parameters
> 
> Hi all,
> 
> RFC8085 recommend a maximum sending of one packet per 3 sec (if the RTT is unknown). This seems to be also a plausible mininum retry interval for your scenarios described below. Can we just add that as a requirement (as original proposed in my discuss)?
> 
> Also would be okay to define the maximum of 6 retries as a requirement?
> 
> Mirja
> 
> 
>> On 5. Jul 2019, at 14:48, Pascal Thubert (pthubert) <[e-mail]> wrote:
>> 
>> Looks good to me, Rahul
>> 
>> All the best,
>> 
>> Pascal
>> 
>>> -----Original Message-----
>>> From: Rahul Arvind Jadhav <[e-mail]>
>>> Sent: vendredi 5 juillet 2019 14:30
>>> To: Pascal Thubert (pthubert) <[e-mail]>
>>> Cc: Routing Over Low power and Lossy networks <[e-mail]>; Mirja 
>>> Kühlewind <[e-mail]>; Alvaro Retana 
>>> <[e-mail]>
>>> Subject: RE: [Roll] Retrying DCO/DAO, retry parameters
>>> 
>>> Can we add something like;
>>> 
>>> The DCO retry time should be dependent on the maximum depth of the 
>>> network and average per hop latency. Thus this could range from 2 sec 
>>> to 120 seconds depending on the deployment. The number of retries 
>>> could be set between 2 to 6 depending upon how critical the route 
>>> invalidation could be for the deployment and the link layer retry 
>>> configuration. For networks supporting only MP2P and P2MP flows, such 
>>> as in AMI and telemetry applications, the 6LRs may not be very keen 
>>> to invalidate routes, unless they are highly memory-constrained. For 
>>> home and building automation networks, with P2P traffic, the 6LRs 
>>> might be keen to invalidate efficiently because it may additionally impact the forwarding efficiency.
>>> Note that the DCO might in turn be retried at link layer if link 
>>> layer supports Ack for unicast packets. In such cases where link 
>>> layer employs retry- mechanism for unicast packets, retrying more 
>>> than 3 times may not be necessary, depending on link layer retry configuration.
>>> 
>>> Any thoughts?
>>> 
>>> Regards,
>>> Rahul
>>> 
>>> 
>>> -----Original Message-----
>>> From: Roll [mailto:[e-mail]] On Behalf Of Mirja 
>>> Kuehlewind
>>> Sent: 04 July 2019 19:28
>>> To: Pascal Thubert (pthubert) <[e-mail]>
>>> Cc: Routing Over Low power and Lossy networks <[e-mail]>
>>> Subject: Re: [Roll] Retrying DCO/DAO, retry parameters
>>> 
>>> I think that is also a good additional to have. I would recommend to 
>>> discus the boundaries in both directions: what the maximum rate I 
>>> should ever to for in order to not permanently overload the network 
>>> and what are the usual considerations to set these parameters correctly for my use case.
>>> 
>>> Mirja
>>> 
>>> 
>>>> On 4. Jul 2019, at 13:22, Pascal Thubert (pthubert) 
>>>> <[e-mail]>
>>> wrote:
>>>> 
>>>> You have a point there, Mirja.
>>>> 
>>>> UDP over LLNs may have to live with durations that are 1 to 2 orders 
>>>> of
>>> magnitude longer than usual in more classical links these days. It 
>>> can take a minute and more to get a message through.
>>>> 
>>>> So yes, a bit of text that says that the typical latencies and 
>>>> turn-around-trip
>>> delays observed on the Internet and the default settings that derive 
>>> from that may not apply in LLNs and need to be revisited depending on 
>>> the link type and the number of hops in case of a mesh network.
>>>> 
>>>> Is that what you are indicating to us?
>>>> 
>>>> Pascal
>>>> 
>>>>> -----Original Message-----
>>>>> From: Mirja Kuehlewind <[e-mail]>
>>>>> Sent: jeudi 4 juillet 2019 13:05
>>>>> To: Alvaro Retana <[e-mail]>; Pascal Thubert 
>>>>> (pthubert) <[e-mail]>
>>>>> Cc: Routing Over Low power and Lossy networks <[e-mail]>
>>>>> Subject: Re: [Roll] Retrying DCO/DAO, retry parameters
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> My request wasn’t to specify this in detail for every scenario, it 
>>>>> was to set boundaries about what's safe to do. The 3 seconds I 
>>>>> mentions are the recommendation given in RFC8085, however, if you 
>>>>> have a good reason to use different values that possible but it 
>>>>> would be good to provide more reasoning then about when it is still 
>>>>> safe to use the values and when it should be avoided.
>>>>> 
>>>>> Mirja
>>>>> 
>>>>> 
>>>>>> On 4. Jul 2019, at 12:44, Alvaro Retana <[e-mail]> wrote:
>>>>>> 
>>>>>> On June 27, 2019 at 1:54:11 AM, Pascal Thubert (pthubert)
>>>>> ([e-mail]) wrote:
>>>>>> 
>>>>>> Hi!
>>>>>> 
>>>>>>> RPL is designed to operate in very different environment, and 
>>>>>>> some LLNs
>>>>> can be very slow, very lossy or even both. This is why RFC 6550 
>>>>> refrains from being too specific.
>>>>>>> Maybe it is good enough to add text indicating that the values 
>>>>>>> used for DCO
>>>>> are expected to be similar/consistent with those used in DAO?
>>>>>> I agree with Pascal.  In fact, the diversity of environments not 
>>>>>> only makes it
>>>>> very hard to be too specific, but it is one of the reasons the WG 
>>>>> has produced Applicability Statements for them: not all deployments 
>>>>> are the
>>> same.
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> Alvaro.
>>>>>> 
>>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> Roll mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/roll
>