From nobody Wed Dec 23 01:14:15 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC86E3A0C93; Wed, 23 Dec 2020 01:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 4cKwM_P1PiYM; Wed, 23 Dec 2020 01:14:12 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6D73A0C90; Wed, 23 Dec 2020 01:14:12 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4D16w15K6Bz2xy2; Wed, 23 Dec 2020 10:14:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608714849; bh=B+OsC9MxQf86njvwnLQF+gtGHn6muw1P/Sz1rkdhhJU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=LJX2d6++cNSVeWUD7sNsZviN04gO41RUmJedkOamEfxCnwwoVFFgTWwtJTDMYtKFF bIFISeILFf9dM0iIBOGEpC3r3NGyRVLLI7tKS3gxJ8zk07A7+MwZgH5/wFFJqJRWFm WI5AUkuu4GfrfV6BIRPysyo0BWpyETTaXa7XQVof/xYPunhAf4vTbiOVKveD5bwU9A V0pUCVZqHUBMUI+POLXkALAPn9yv8eKaTa7dcR92Khi/odmrpx2lr+Cmep1p3mhMNP KmRS6gHUFsZnnKqMhQ5fJa0dP+Jw9ejy0NAfmiHBecnd4Tuyuxbnrb3BBZXAD88tO4 IrMLG+8B2IOaQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4D16w14D5tz5vMq; Wed, 23 Dec 2020 10:14:09 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "draft-ietf-core-new-block@ietf.org" CC: "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) Thread-Index: AdbZC/aihA0VBDFOQyy3pGY3SL4iaQ== Date: Wed, 23 Dec 2020 09:14:09 +0000 Message-ID: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 09:14:14 -0000 Re-, You are completely right that the default probing-rate is to be increased f= or the DOTS case. FYI, this is why we went with the following in RFC8782: | Given that the size of the heartbeat request cannot exceed | ('heartbeat-interval' * 'probing-rate') bytes, 'probing-rate' | should be set appropriately to avoid slowing down heartbeat | exchanges. For example, 'probing-rate' may be set to 2 * | ("size of encrypted DOTS heartbeat request"/'heartbeat- | interval') or (("size of encrypted DOTS heartbeat request" + | "average size of an encrypted mitigation request")/'heartbeat- | interval'). Absent any explicit configuration or inability to | dynamically adjust 'probing-rate' values (Section 4.8.1 of | [RFC7252]), DOTS agents use 5 bytes/second as a default | 'probing-rate' value. We also allow DOTS peers to negotiate the transmission parameters (and prob= ing rate) with the following as default:=20 "The RECOMMENDED values of transmission parameter values are 'ack-timeout' (2 seconds), 'max- retransmit' (3), and 'ack-random-factor' (1.5). In addition to those parameters, the RECOMMENDED specific DOTS transmission parameter values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' (15)." We avoided to include a pointer to these details as these are application-s= pecific and that, even if the draft is motivated by the DOTS use case, othe= r applications can make use of the new block functionality.=20 For NSTART, we already have the following:=20 " NSTART will also need to be increased from the default (1) to get faster transmission rates." Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 06:01 > =C0=A0: draft-ietf-core-new-block@ietf.org > Cc=A0: core@ietf.org WG (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > * Also on parameters: This document is describing flow control stuff > around a situation CoAP was not originally designed for. Wouldn't > it > make sense to include a set of parameters (PROBING_RATE, > MAX_LATENCY, > ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that > PROBING_RATE will be left to 1 byte/second for any DOTS > application > using this (for sending 10KiB in the initial 10-package > MAX_PAYLOADS > burst would mark that connection as unusable for about 3 hours if > they > all get lost), so better give justifiable numbers here than rely > on > implemnetors to come up with unreviewed numbers or disregard > PROBING_RATE altogether. >=20 > I don't know if it needs additional justification, but an > increased > N_START may be justifiable there. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you.