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 06EFF1200FB for ; Mon, 8 Jul 2019 02:30:39 -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 XakAypCQuB08 for ; Mon, 8 Jul 2019 02:30:36 -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 576B212010F for ; Mon, 8 Jul 2019 02:30:35 -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 1hkPyh-00059V-TH; Mon, 08 Jul 2019 11:30:31 +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: <982B626E107E334DBE601D979F31785C5DF34984@BLREML503-MBX.china.huawei.com> Date: Mon, 8 Jul 2019 11:30:31 +0200 Cc: "Pascal Thubert (pthubert)" , Routing Over Low power and Lossy networks , Alvaro Retana Content-Transfer-Encoding: quoted-printable Message-Id: <4FA6D31C-723F-4D6A-B084-569B7B467EF9@kuehlewind.net> 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> To: Rahul Arvind Jadhav X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1562578236;358ef910; X-HE-SMSGID: 1hkPyh-00059V-TH 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 09:30:39 -0000 Hi Rahul, Please see inline. > On 7. Jul 2019, at 10:29, Rahul Arvind Jadhav = wrote: >=20 > Hi Mirja, >=20 > Thank you for the ref. >=20 > I would like to confirm my understanding of RFC 8085 in this context = (just to check if I am on the same page). >=20 > 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.=E2=80=9D Yes, that=E2=80=99s the text I was talking about. >=20 > 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. >=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 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. Do you think it would also be possible to state a clear requirement for = the maximum number of retries? Mirja >=20 > I like this better. >=20 > In your earlier mail, there were two questions,=20 > 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. >=20 > Kindly let us know your thoughts. >=20 > Thanks, > Rahul >=20 >=20 >=20 > -----Original Message----- > From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net]=20 > Sent: 05 July 2019 21:33 > To: Pascal Thubert (pthubert) > Cc: Rahul Arvind Jadhav ; Routing Over Low = power and Lossy networks ; Alvaro Retana = > 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 = sec=20 >>> to 120 seconds depending on the deployment. The number of retries=20 >>> could be set between 2 to 6 depending upon how critical the route=20 >>> invalidation could be for the deployment and the link layer retry=20 >>> configuration. For networks supporting only MP2P and P2MP flows, = such=20 >>> as in AMI and telemetry applications, the 6LRs may not be very keen=20= >>> to invalidate routes, unless they are highly memory-constrained. For=20= >>> home and building automation networks, with P2P traffic, the 6LRs=20 >>> 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 = orders=20 >>>> 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 = on=20 >>> 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=20 >>>>> (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 = still=20 >>>>> 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 = deployments=20 >>>>> 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