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 14:59 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 C47F43A0883 for <core@ietfa.amsl.com>; Wed, 12 May 2021 07:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 JhCX-w7a6wsg for <core@ietfa.amsl.com>; Wed, 12 May 2021 07:59:44 -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 839483A0874 for <core@ietf.org>; Wed, 12 May 2021 07:59:44 -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 1lgqKr-0004UL-4v; Wed, 12 May 2021 15:59:41 +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:
Date: Wed, 12 May 2021 15:59:43 +0100
Message-ID: <041601d7473f$7113e540$533bafc0$@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+ChpLivgHgKIHcrlApPqG38CEWvyxQJ3w676AJILkT0BGVdVmQE5F4wPq9ZR+dA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Jj2nOToYMfU9MGII6soWCNyoW3A>
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 14:59:50 -0000
Hi Lars, I have come up with some initial draft changes - do these work for you? Please see https://www.ietf.org/rfcdiff?url1=draft-ietf-core-new-block&url2=https://raw .githubusercontent.com/core-wg/new-block/emphasis/draft-ietf-core-new-block. txt Regards Jon > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: 12 May 2021 10:37 > To: 'Lars Eggert'; '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 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-interim-2020-core-04-sessa-new-coap-block-wise- > transfer-options-draft-bosh-core-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- > draft-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