Return-Path: 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 1F76D1201E0 for ; Mon, 8 Jul 2019 05:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 e7yynrjkfBZD for ; Mon, 8 Jul 2019 05:08:40 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32EF11201E9 for ; Mon, 8 Jul 2019 05:08:40 -0700 (PDT) Received: from 200116b82cc4d10004c03462e129448d.dip.versatel-1u1.de ([2001:16b8:2cc4:d100:4c0:3462:e129:448d]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hkSRf-00023f-Nn; Mon, 08 Jul 2019 14:08:35 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <982B626E107E334DBE601D979F31785C5DF352C1@BLREML503-MBX.china.huawei.com> Date: Mon, 8 Jul 2019 14:08:35 +0200 Cc: "Pascal Thubert (pthubert)" , Routing Over Low power and Lossy networks , Alvaro Retana Content-Transfer-Encoding: quoted-printable Message-Id: References: <982B626E107E334DBE601D979F31785C5DF0BFA2@BLREML503-MBX.china.huawei.com> <781F0E6E-5F97-49C4-8E5C-3933088D87E7@kuehlewind.net> <40B8B554-40C5-43E8-ACB0-C10F89C085EA@kuehlewind.net> <982B626E107E334DBE601D979F31785C5DF30F64@BLREML503-MBX.china.huawei.com> <1AC88ACD-4A7F-4E72-97E5-84548BC78557@kuehlewind.net> <982B626E107E334DBE601D979F31785C5DF34984@BLREML503-MBX.china.huawei.com> <4FA6D31C-723F-4D6A-B084-569B7B467EF9@kuehlewind.net> <982B626E107E334DBE601D979F31785C5DF352C1@BLREML503-MBX.china.huawei.com> To: Rahul Arvind Jadhav X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1562587720;e855d9c0; X-HE-SMSGID: 1hkSRf-00023f-Nn Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 12:08:51 -0000 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 = wrote: >=20 > Thanks Mirja, >=20 > I'll change the text to following: >=20 > "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." >=20 > 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). >=20 > Thanks, > Rahul >=20 >=20 >=20 >>=20 >> 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.=E2=80=9D >=20 > Yes, that what I was looking for. I think you can even go for "MUST = NOT=E2=80=9D 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=E2=80=99t have to. >=20 > Do you think it would also be possible to state a clear requirement = for the maximum number of retries? >=20 > Mirja >=20 >=20 >>=20 >> I like this better. >>=20 >> In your earlier mail, there were two questions, 1. What is the max=20 >> 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. >>=20 >> Kindly let us know your thoughts. >>=20 >> Thanks, >> Rahul >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net] >> Sent: 05 July 2019 21:33 >> To: Pascal Thubert (pthubert) >> Cc: Rahul Arvind Jadhav ; Routing Over Low=20= >> power and Lossy networks ; Alvaro Retana=20 >> >> Subject: Re: [Roll] Retrying DCO/DAO, retry parameters >>=20 >> Hi all, >>=20 >> 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)? >>=20 >> Also would be okay to define the maximum of 6 retries as a = requirement? >>=20 >> Mirja >>=20 >>=20 >>> On 5. Jul 2019, at 14:48, Pascal Thubert (pthubert) = wrote: >>>=20 >>> Looks good to me, Rahul >>>=20 >>> All the best, >>>=20 >>> Pascal >>>=20 >>>> -----Original Message----- >>>> From: Rahul Arvind Jadhav >>>> Sent: vendredi 5 juillet 2019 14:30 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Routing Over Low power and Lossy networks ; = Mirja=20 >>>> K=C3=BChlewind ; Alvaro Retana=20 >>>> >>>> Subject: RE: [Roll] Retrying DCO/DAO, retry parameters >>>>=20 >>>> Can we add something like; >>>>=20 >>>> The DCO retry time should be dependent on the maximum depth of the=20= >>>> network and average per hop latency. Thus this could range from 2=20= >>>> sec to 120 seconds depending on the deployment. The number of=20 >>>> retries could be set between 2 to 6 depending upon how critical the=20= >>>> route invalidation could be for the deployment and the link layer=20= >>>> retry configuration. For networks supporting only MP2P and P2MP=20 >>>> flows, such as in AMI and telemetry applications, the 6LRs may not=20= >>>> be very keen to invalidate routes, unless they are highly=20 >>>> memory-constrained. For home and building automation networks, with=20= >>>> 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=20 >>>> layer supports Ack for unicast packets. In such cases where link=20 >>>> layer employs retry- mechanism for unicast packets, retrying more=20= >>>> than 3 times may not be necessary, depending on link layer retry = configuration. >>>>=20 >>>> Any thoughts? >>>>=20 >>>> Regards, >>>> Rahul >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Mirja=20 >>>> Kuehlewind >>>> Sent: 04 July 2019 19:28 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Routing Over Low power and Lossy networks >>>> Subject: Re: [Roll] Retrying DCO/DAO, retry parameters >>>>=20 >>>> I think that is also a good additional to have. I would recommend = to=20 >>>> discus the boundaries in both directions: what the maximum rate I=20= >>>> should ever to for in order to not permanently overload the network=20= >>>> and what are the usual considerations to set these parameters = correctly for my use case. >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>> On 4. Jul 2019, at 13:22, Pascal Thubert (pthubert)=20 >>>>> >>>> wrote: >>>>>=20 >>>>> You have a point there, Mirja. >>>>>=20 >>>>> UDP over LLNs may have to live with durations that are 1 to 2=20 >>>>> orders of >>>> magnitude longer than usual in more classical links these days. It=20= >>>> can take a minute and more to get a message through. >>>>>=20 >>>>> So yes, a bit of text that says that the typical latencies and=20 >>>>> turn-around-trip >>>> delays observed on the Internet and the default settings that = derive=20 >>>> from that may not apply in LLNs and need to be revisited depending=20= >>>> on the link type and the number of hops in case of a mesh network. >>>>>=20 >>>>> Is that what you are indicating to us? >>>>>=20 >>>>> Pascal >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Mirja Kuehlewind >>>>>> Sent: jeudi 4 juillet 2019 13:05 >>>>>> To: Alvaro Retana ; Pascal Thubert >>>>>> (pthubert) >>>>>> Cc: Routing Over Low power and Lossy networks >>>>>> Subject: Re: [Roll] Retrying DCO/DAO, retry parameters >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> My request wasn=E2=80=99t to specify this in detail for every = scenario, it=20 >>>>>> was to set boundaries about what's safe to do. The 3 seconds I=20 >>>>>> mentions are the recommendation given in RFC8085, however, if you=20= >>>>>> have a good reason to use different values that possible but it=20= >>>>>> would be good to provide more reasoning then about when it is=20 >>>>>> still safe to use the values and when it should be avoided. >>>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>> On 4. Jul 2019, at 12:44, Alvaro Retana = wrote: >>>>>>>=20 >>>>>>> On June 27, 2019 at 1:54:11 AM, Pascal Thubert (pthubert) >>>>>> (pthubert@cisco.com) wrote: >>>>>>>=20 >>>>>>> Hi! >>>>>>>=20 >>>>>>>> RPL is designed to operate in very different environment, and=20= >>>>>>>> some LLNs >>>>>> can be very slow, very lossy or even both. This is why RFC 6550=20= >>>>>> refrains from being too specific. >>>>>>>> Maybe it is good enough to add text indicating that the values=20= >>>>>>>> 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=20= >>>>>>> only makes it >>>>>> very hard to be too specific, but it is one of the reasons the WG=20= >>>>>> has produced Applicability Statements for them: not all=20 >>>>>> deployments are the >>>> same. >>>>>>>=20 >>>>>>> Thanks! >>>>>>>=20 >>>>>>> Alvaro. >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20