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

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Mon, 08 July 2019 10:30 UTC

Return-Path: <rahul.jadhav@huawei.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA8E120127 for <roll@ietfa.amsl.com>; Mon, 8 Jul 2019 03:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyyzMCi7zPUA for <roll@ietfa.amsl.com>; Mon, 8 Jul 2019 03:30:09 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB646120088 for <roll@ietf.org>; Mon, 8 Jul 2019 03:30:08 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 350EC98BEA4488F7D893; Mon, 8 Jul 2019 11:30:06 +0100 (IST)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 8 Jul 2019 11:30:05 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.50]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0439.000; Mon, 8 Jul 2019 15:59:56 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
CC: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Routing Over Low power and Lossy networks <roll@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>
Thread-Topic: [Roll] Retrying DCO/DAO, retry parameters
Thread-Index: AdUshAoU1ZNXDKIJRSu3/AosXtsQyAAJ73yQAV7g4oAAALn3gAAAnHeAAAAv1QAAJjjSIAAO5pMAAAGH5wAAZKl7kAApwe+AAA1exPA=
Date: Mon, 08 Jul 2019 10:29:56 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DF352C1@BLREML503-MBX.china.huawei.com>
References: <982B626E107E334DBE601D979F31785C5DF0BFA2@BLREML503-MBX.china.huawei.com> <BYAPR11MB3558B443C789222A7604184ED8FD0@BYAPR11MB3558.namprd11.prod.outlook.com> <CAMMESswJ0TozAJCa4o0nJOvGToi-324M4CY9beWWQmOB-Cp6PQ@mail.gmail.com> <781F0E6E-5F97-49C4-8E5C-3933088D87E7@kuehlewind.net> <MN2PR11MB35659BA8A9C5D1A810DF9A1DD8FA0@MN2PR11MB3565.namprd11.prod.outlook.com> <40B8B554-40C5-43E8-ACB0-C10F89C085EA@kuehlewind.net> <982B626E107E334DBE601D979F31785C5DF30F64@BLREML503-MBX.china.huawei.com> <MN2PR11MB3565C62C5B9AAADCB9173F16D8F50@MN2PR11MB3565.namprd11.prod.outlook.com> <1AC88ACD-4A7F-4E72-97E5-84548BC78557@kuehlewind.net> <982B626E107E334DBE601D979F31785C5DF34984@BLREML503-MBX.china.huawei.com> <4FA6D31C-723F-4D6A-B084-569B7B467EF9@kuehlewind.net>
In-Reply-To: <4FA6D31C-723F-4D6A-B084-569B7B467EF9@kuehlewind.net>
Accept-Language: en-IN, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.109.81]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/GMniORk-OmuDb5yrs5HZwtPbctU>
Subject: Re: [Roll] Retrying DCO/DAO, retry parameters
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2019 10:30:12 -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



> 
> 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:ietf@kuehlewind.net]
> Sent: 05 July 2019 21:33
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>; Routing Over Low 
> power and Lossy networks <roll@ietf.org>; Alvaro Retana 
> <aretana.ietf@gmail.com>
> 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) <pthubert@cisco.com> wrote:
>> 
>> Looks good to me, Rahul
>> 
>> All the best,
>> 
>> Pascal
>> 
>>> -----Original Message-----
>>> From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
>>> Sent: vendredi 5 juillet 2019 14:30
>>> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
>>> Cc: Routing Over Low power and Lossy networks <roll@ietf.org>; Mirja 
>>> Kühlewind <ietf@kuehlewind.net>; Alvaro Retana 
>>> <aretana.ietf@gmail.com>
>>> 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: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
>