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:roll-bounces@ietf.org] On Behalf Of Mirja Kuehlewind
Sent: 04 July 2019 19:28
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>
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) <pthubert@cisco.com> 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 <ietf@kuehlewind.net>
>> Sent: jeudi 4 juillet 2019 13:05
>> To: Alvaro Retana <aretana.ietf@gmail.com>; Pascal Thubert (pthubert) 
>> <pthubert@cisco.com>
>> Cc: Routing Over Low power and Lossy networks <roll@ietf.org>
>> 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 <aretana.ietf@gmail.com> wrote:
>>> 
>>> On June 27, 2019 at 1:54:11 AM, Pascal Thubert (pthubert)
>> (pthubert@cisco.com) 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
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll