From nobody Tue Feb 16 15:53:48 2021 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 D206D3A12FA; Tue, 16 Feb 2021 15:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 aVH1Dz7sHn2n; Tue, 16 Feb 2021 15:53:44 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EDF3A12F4; Tue, 16 Feb 2021 15:53:43 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0CCC740887; Wed, 17 Feb 2021 00:53:41 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1AACAFD; Wed, 17 Feb 2021 00:53:40 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D720944; Wed, 17 Feb 2021 00:53:39 +0100 (CET) Received: (nullmailer pid 612561 invoked by uid 1000); Tue, 16 Feb 2021 23:53:39 -0000 Date: Wed, 17 Feb 2021 00:53:39 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: mohamed.boucadair@orange.com Cc: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HoBOzF5stQ3CqCEx" Content-Disposition: inline In-Reply-To: <23740_1612339780_601A5A44_23740_98_8_787AE7BB302AE849A7480A190F8B9330315C6374@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (No-Response) 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: Tue, 16 Feb 2021 23:53:47 -0000 --HoBOzF5stQ3CqCEx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Med, On Wed, Feb 03, 2021 at 08:09:40AM +0000, mohamed.boucadair@orange.com wrot= e: > As a follow-up on this issue, we finally went with an approach that > does not require No-Response. We do have the following to avoid extra > delays, e.g.,=20 The need to indicate when a client wants confirmation has been avoided by having timeouts on both sides, and relying more on MAX_PAYLOADS being aligned. For my taste, that makes unnecessary sacrifices in robustness over the simple two-byte NoResponse:0 that'd go with every MAX_PAYLOADS'th Q-Block2 from the client (and would completey avoid the risk of stalling in a lossless situation). (For the other direction, corective heuristics can easily be applied). But given they are explicitly configured in the DOTS case where Q-Block is used, so -- well. Food for a block-bis (or generalized additions that allow block to be used that way). That aside, in the interest of readers who try to understand the ecosystem and the trade-offs involved, I think that at least a reference to it in a statement like "was not chosen because of X" would be helpful. The "Note that similar performance benefits" section would lend itself to that. Text suggestion: [messages are provided in Appendix A.] Similarly, The No-Response option can be applied to Block1 requests, but offers no corresponding facility for Block2 responses. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --HoBOzF5stQ3CqCEx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAsWwMACgkQOY0REtOk veE0+g//evS9LOaNlDgc8UJnmAr6U7EFVScfJVd2qZIb2eMaxD0JDDVgYy4pjnoI ekMIvCN65ZNC97y7eTNRH4G9nPrJSJdOBaIB0yLJn7BW4mrgqCWersJ+V0dninR0 PDZGcDGvpOoNvPUWmO2nDTLnS6s2VGTO3PZlxdYgNvk8PVsgOx6nCr5zP0YXIg4a GDSjVhssbBAoMgqDw7E0aok8nntDESjufdA8DTulVXanYI9v48CSvIUcfBiuNdBt hgZ92drQhdpyTQcZt9S4ygapVDpTCEwv6UsxoxdPbZOrwl2OkGjlk6fNdeeNv22X ztgXQ9IkPhf3UOb1st2Jt9dljebGlN36jX/L4zVcItHoQnzi9tRl/XXJTQMgumth hdnp2kOsJUICB6RT3P/6DQGWEEbsRFrKwQwPDFwWuSpCyqBQC5pHkjm+ysKtTKZy BfqdfEyMEGhPL9AQHCYy9snJ+ZXG/f5qP8B7wD3RKB5sHPb82v5h7lqQHn9+rkG9 6V1PE0N0FFqNBLNYP+99RZ/NB7rYb7NHAFINqr4FXOXj6wBIzZyczzMCZE3/WpR6 PDNgjTvDhsw9lQ4iM0ZAXSuq7S/ABHNZ2FWT9gZJK92+cE95y1prL1dADkAb4hW+ kJc7Q3DMGhbwIxExax+rvqNGS/1T8IncgoU4GEK9ul5Bs/h7EnM= =7oZB -----END PGP SIGNATURE----- --HoBOzF5stQ3CqCEx--