Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

Lars Eggert <> Tue, 11 May 2021 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8AEA3A1F7C; Tue, 11 May 2021 10:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vbYkFPIUyX2N; Tue, 11 May 2021 10:26:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 729AB3A1F7A; Tue, 11 May 2021 10:26:47 -0700 (PDT)
Received: from (unknown [IPv6:2a00:ac00:4000:400:1574:cd7a:7f:13e3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 8F2BD60035E; Tue, 11 May 2021 20:26:39 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1620753999; bh=juDurZBI75KS2qUgtA6B9OV2vYTHHs+rKfNwLepNWDo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=ebd6DOBSkEvu+vXU16XVqjkz05+A0cIdQDWA96NMne9q3pTjBydxYcH1svlV25lFj /k4OCkvKY9JhzuM3n67aanExYAgfjDx5mV5/rwk6Syn6GxtHn0Nbwbg3yBBdLmUfVS A1jsQ2JgJfoA4mFnv9PAVg6FR5H8PvnNoD1vygvo=
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_35F07822-74CB-4C6E-8A31-C1EA5FD0A872"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Tue, 11 May 2021 20:26:38 +0300
In-Reply-To: <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Cc: "" <>, "" <>, The IESG <>, "" <>, "" <>
References: <> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3654.
X-MailScanner-ID: 8F2BD60035E.A5C1B
X-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
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, 11 May 2021 17:26:53 -0000


On 2021-5-11, at 16:28, 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?

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?

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.

>> 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?

(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.)

> 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