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

From: Alvaro Retana <[email-masked]>
Date: Thu, 4 Jul 2019 06:44:03 -0400

On June 27, 2019 at 1:54:11 AM, Pascal Thubert (pthubert) (
[email-masked]) 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.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 4 Jul 2019 13:04:51 +0200

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 <[email-masked]> wrote:
> 
> On June 27, 2019 at 1:54:11 AM, Pascal Thubert (pthubert) ([email-masked]) 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.
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Jul 2019 11:22:21 +0000

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 <[email-masked]>
> Sent: jeudi 4 juillet 2019 13:05
> To: Alvaro Retana <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]>
> Cc: Routing Over Low power and Lossy networks <[email-masked]>
> 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
> 
> 
> >> 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.
> > 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.
> >
> >

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 4 Jul 2019 13:27:42 +0200

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) <[email-masked]> wrote:
>

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Fri, 5 Jul 2019 12:30:14 +0000

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:[email-masked]] On Behalf Of Mirja Kuehlewind
Sent: 04 July 2019 19:28
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Retrying DCO/DAO, retry parameters

Mirja

>> 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
>> 
>> 
>> can be very slow, very lossy or even both. This is why RFC 6550 
>> refrains from being too specific.
>> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Jul 2019 12:48:46 +0000

Looks good to me, Rahul

All the best,

Pascal

> From: Rahul Arvind Jadhav <[email-masked]>
> Sent: vendredi 5 juillet 2019 14:30
> Cc: Routing Over Low power and Lossy networks <[email-masked]>; Mirja
> Kühlewind <[email-masked]>; Alvaro Retana <[email-masked]>
> Subject: RE: [Roll] Retrying DCO/DAO, retry parameters
> 
> 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
> 
> 
> 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
> 
> 
> > 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.
> >

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 5 Jul 2019 15:32:36 +0200

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) <[email-masked]> wrote:
> 
> Looks good to me, Rahul
> 
> All the best,
> 
> Pascal
>

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Sun, 7 Jul 2019 08:29:55 +0000

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."

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.

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."

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:[email-masked]] 
Sent: 05 July 2019 21:33
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Rahul Arvind Jadhav <[email-masked]>; Routing Over Low power and Lossy networks <[email-masked]>; Alvaro Retana <[email-masked]>
Subject: Re: [Roll] Retrying DCO/DAO, retry parameters

Hi all,

Mirja

>> 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
>> 
>> 
>> 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) 
>>> <[email-masked]>
>> wrote:
>>> 
>> magnitude longer than usual in more classical links these days. It 
>> can take a minute and more to get a message through.
>>> 
>> 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.
>>> 
>>>> To: Alvaro Retana <[email-masked]>; Pascal Thubert 
>>>> (pthubert) <[email-masked]>
>>>> 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
>>>> 
>>>> 
>>>> 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.
>>>>> 
>>>>> 
>>> 
>>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 8 Jul 2019 11:30:31 +0200

Hi Rahul,

Please see inline.

> On 7. Jul 2019, at 10:29, Rahul Arvind Jadhav <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> Thank you for the ref.
> 
> "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.

> 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.

> "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

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Mon, 8 Jul 2019 10:29:56 +0000

Thanks Mirja,

I'll change the text to following:

"Thus this could range from 2 sec to 120 seconds depending on the deployment. In case the latency limits are not known, an implementation MUST NOT retry more than once in 3 seconds and MUST NOT retry more than 3 times."

I don't think there is any reason to retry more than thrice anyways, so it should be safe to put these limits.
I will add the above text to the document and provide an update (unless anyone else comments).

Thanks,
Rahul

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?
> Cc: Rahul Arvind Jadhav <[email-masked]>; Routing Over Low 
> power and Lossy networks <[email-masked]>; Alvaro Retana 
> <[email-masked]>
>>> 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.
>>> 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.
>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>>> has produced Applicability Statements for them: not all 
>>>>> deployments are the
>>> same.
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> Alvaro.
>>>>>> 
>>>>>> 
>>>> 
>>>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 8 Jul 2019 14:08:35 +0200

Thanks a lot! I will clear my discuss if a new version is posted.

Mirja

> On 8. Jul 2019, at 12:29, Rahul Arvind Jadhav <[email-masked]> wrote:
> 
> Thanks Mirja,
>