Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
supjps-ietf@jpshallow.com Wed, 12 May 2021 09:36 UTC
Return-Path: <jon.shallow@jpshallow.com>
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 3B7643A3B67 for <core@ietfa.amsl.com>; Wed, 12 May 2021 02:36:49 -0700 (PDT)
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=unavailable 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 MJVCzkOk4-gP for <core@ietfa.amsl.com>; Wed, 12 May 2021 02:36:43 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 B9E5C3A3B68 for <core@ietf.org>; Wed, 12 May 2021 02:36:43 -0700 (PDT)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1lglIG-0004KH-Gh; Wed, 12 May 2021 10:36:40 +0100
From: supjps-ietf@jpshallow.com
To: 'Lars Eggert' <lars@eggert.org>, mohamed.boucadair@orange.com
Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, 'The IESG' <iesg@ietf.org>, core@ietf.org, marco.tiloca@ri.se
References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <47273993-E4D3-4042-85B5-17163C984B18@eggert.org> <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <39AC6D5F-0FA3-4FE3-BD59-302B65CFDE49@eggert.org>
In-Reply-To: <39AC6D5F-0FA3-4FE3-BD59-302B65CFDE49@eggert.org>
Date: Wed, 12 May 2021 10:36:43 +0100
Message-ID: <03a501d74712$516f6fc0$f44e4f40$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEp71xGbs3/HDljMxiZ+ChpLivgHgKIHcrlApPqG38CEWvyxQJ3w676AJILkT0BGVdVmavfrZtg
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/lcweSLRKYWpKv6l-dNITuK3fhDI>
Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2021 09:36:49 -0000
Hi Lars, I will come up with draft changes if the below is acceptable to you. Please see inline. Regards Jon > -----Original Message----- > From: Lars Eggert [mailto: lars@eggert.org] > Sent: 11 May 2021 18:27 > To: mohamed.boucadair@orange.com > Cc: draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG; > core@ietf.org; marco.tiloca@ri.se > Subject: Re: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with > DISCUSS and COMMENT) > > Hi, > > On 2021-5-11, at 16:28, mohamed.boucadair@orange.com wrote: > >> 1. The motivation for draft-ietf-core-new-block seems to be a lack of > >> performance with RFC7959. For a Proposed Standard, I would expect > >> there to be an evaluation that draft-ietf-core-new-block achieves > >> that desired level of performance over RFC7959, in a number of > >> scenarios of interest. This is to establish that the proposed > >> mechanism is fit for purpose. > > > > [Med] We thought that this is covered by this part of the text: > > > > == > > Libcoap was tested with complete packet loss in one direction (for NON) > confirming data still gets through, albeit more slowly with the > NON_TIMEOUT timeout for every MAX_PAYLOADS packets adding to the > overall transmission time. Note that CON fails under these conditions, and > as such RFC7959 fails to retrieve the body. > > == > > > > The performance comparison is straightforward as RFC7959 (with CON > messages) fails while the body is successfully retrieved using the new- > block. > > this says that draft-ietf-core-new-block works where RFC7959 fails. While > it's technically true that this makes draft-ietf-core-new-block infinitely > faster then RFC7959, I didn't understand that that was what the title, > abstract and some other places in the document meant - it sounded to me > that a performance difference compared to RFC7959 was the motivation for > draft-ietf-core-new-block? [Jon] No- performance was not the original motivation. We appear to have been focused on highlighting the performance benefits rather that this draft is supporting a missing piece out RFC7252/RFC7959, namely robustly supporting of Non-Confirmable using a block-wise transfer. It just happened that there was a performance benefit (as seen with TCP sliding window where each packet does not have to be acknowledged before sending the next one) which we got excited about. [Jon] I will look at updating the emphasis in the draft, including the title and abstract which were there from the initial drafts and never properly revisited. [Jon] The presentation given at Interim Core 13 May 2020 https://datatracker.ietf.org/meeting/interim-2020-core-04/materials/slides-i nterim-2020-core-04-sessa-new-coap-block-wise-transfer-options-draft-bosh-co re-new-block-01.pdf Slide 4 highlights the RFC7959 issue when using Non-Confirmable and lossy traffic, Slides 5 - 9 working through the issues we had found up to that point. [Jon] As can be seen the IETF 109 presentation https://datatracker.ietf.org/meeting/109/materials/slides-109-core-sessa-dra ft-ietf-core-new-block-01.pdf Slide 5 there was a lot of debate over the naming of this Block option and ended up with Q-Block - again implying performance. [Jon] As a side note, if returning acknowledgement traffic from the remote peer is getting dropped, the large request (or large response) will still get through, albeit with a timeout of NON_TIMEOUT every MAX_PAYLOADS. It is more important (certainly in the DOTS case) to get the information through than how fast could it get there. (Overall transmission rate is kept low, covered by PROBING_WAIT, with an upper limit wait timeout of NON_PROBING_WAIT). > > Because if it's purely about not failing, you could make draft-ietf-core-new- > block (much) less aggressive and all my issues would go away. Is that a way > forward here? [Jon] Yes, agreed. > > If not, and a performance difference is part of the motivation, I think a > Proposed Standard should refer to some analysis that demonstrates that in > a number of scenarios of interest. [Jon] I don't think that this is needed now. > > >> 2. For a Proposed Standard, I would also expect to see an evaluation > >> whether draft-ietf-core-new-block achieves that desired level of > >> performance in non-DDoS scenarios *without* unduly affecting > >> competing traffic. (Or else there needs to be an applicability > >> statement that draft-ietf-core-new-block MUST only be used under > >> DDoS, and a reference needs to be given for how a DDoS scenario can > >> be reliably determined.) > > > > [Med] We do have the following applicability scope (an excerpt below): > > > > The block-wise transfer specified in [RFC7959] covers the general > > case, but falls short in situations where packet loss is highly > > asymmetrical. The mechanism specified in this document provides > > roughly similar features to the Block1/Block2 Options. It provides > > additional properties that are tailored towards the intended use case > > of Non-Confirmable transmission. Concretely, this mechanism > > primarily targets applications such as DDoS Open Threat Signaling > > (DOTS) that cannot use CON responses to handle potential packet loss > > and that support application-specific mechanisms to assess whether > > the remote peer is not overloaded and thus is able to process the > > messages sent by a CoAP endpoint (e.g., DOTS heartbeats in > > Section 4.7 of [RFC8782]). > > ... > > This mechanism is not intended for general CoAP usage, and any use > > outside the intended use case should be carefully weighed > > > > I think that we do already have the guards clearly explained. If you don't > think so, can you please share which change you would like see in the > applicability scope? > > This says "only use this for DOTS". But it doesn't discuss whether draft-ietf- > core-new-block is only deemed safe for DOTS scenarios in which a DDoS is > present, or also in cases where a DDoS is absent, and it doesn't cite any > analysis into *why* this recommendation can safely be made. If DOTS uses > draft-ietf-core-new-block, what is the impact on crosstraffic? [Jon] Good point. I cannot think of any reason as to why it would not be safe for any environment that supports Q-Block (subject to the noted limitations list - hence comment about "intended use case should be carefully weighed") . As Q-Block1 and Q-Block2 are 'Critical', then if an agent does not support Q-Block, there can be a fall-back to RFC7959 Block. Also see next comment. > > (Also, in the IESG discussion the point was brought up that draft-ietf-core- > new-block may form the basis for a revision of RFC7959, so it's a bit odd to > see this strict limitation on one application and/or a very specific scenario.) > [Jon] Initially, the WG were concerned that people would see this draft as an alternative to RFC7959 (e.g. draft name of new-block) and wanted us to highlight the limitations and indicate that it had come about from the DOTS requirements. At that point, it was looking as if we may have to alter some RFC7959 block characteristics to get things working. After much discussion / brainstorming ways to handle Congestion Control / Recovery there is no longer any need to violate any of the RFC7252/RFC7959 principles. Hence the later WG thinking about the possibility of using this draft as material for a RFC7959-bis. > > This is so the proposed mechanism can be > >> recommended as the IETF solution for a given use case, without too > >> many restrictions. > >> > >> To be clear, that is not material that would be in the specification. > >> Such material would probably be presented to the WG early during the > >> standardization process (often at adoption time), and referred to in > >> the specification. In other words, I'm not asking you or the WG to > >> now go and perform this analysis - I'm asking whether it has been > >> performed already, because that is to me the deciding factor in > >> whether I can ballot "no objection" to publishing this as a Proposed > >> Standard. > >> > >> I hope this clarifies things further? > >> > >> Thanks, > >> Lars
- [core] Lars Eggert's Discuss on draft-ietf-core-n… Lars Eggert via Datatracker
- Re: [core] Lars Eggert's Discuss on draft-ietf-co… mohamed.boucadair
- Re: [core] Lars Eggert's Discuss on draft-ietf-co… Lars Eggert
- Re: [core] Lars Eggert's Discuss on draft-ietf-co… mohamed.boucadair
- Re: [core] Lars Eggert's Discuss on draft-ietf-co… Lars Eggert
- Re: [core] Lars Eggert's Discuss on draft-ietf-co… mohamed.boucadair
- Re: [core] Lars Eggert's Discuss on draft-ietf-co… Lars Eggert
- Re: [core] Lars Eggert's Discuss on draft-ietf-co… supjps-ietf
- Re: [core] Lars Eggert's Discuss on draft-ietf-co… supjps-ietf
- Re: [core] Lars Eggert's Discuss on draft-ietf-co… Lars Eggert
- Re: [core] Lars Eggert's Discuss on draft-ietf-co… mohamed.boucadair