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

Lars Eggert <> Tue, 11 May 2021 13:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 680523A1736; Tue, 11 May 2021 06:11:43 -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 jQd4GCa1ShuA; Tue, 11 May 2021 06:11:38 -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 14FE43A1738; Tue, 11 May 2021 06:11:38 -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 DB0B260035E; Tue, 11 May 2021 16:11:22 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1620738683; bh=nLDdFA9SpyoFL4QemX73FBEOhm+wDoL/YBi6fSJcH/o=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=QfrSWDUGq1toSpKiAiD6z6xYpN3XnLwQBOdw2EiK5wuFPDYlyDIQMBxTYmIFCP4ay vIyzjWeTiYumiw0mJh3TN7iqCDwXuJNFjNLAZbhFxPgIpxpZlJUh5rVz4fZBeG/GHE PeaCEz9CtImgmLIXC7hzFKG3T1tFSX38juxrUZ40=
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_187EA2A5-6200-42DE-88FB-24032B45B790"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Tue, 11 May 2021 16:11:22 +0300
In-Reply-To: <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@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>
X-Mailer: Apple Mail (2.3654.
X-MailScanner-ID: DB0B260035E.A2484
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 13:11:44 -0000


On 2021-5-11, at 15:05, wrote:
> We prepared some material for your to describe the methodology and to list various interops and other useful pointers:

thanks for the pointer, Med. This is a clear description of the tests that were done, most (all?) of which seem to be focused on regression and interop testing.

What I was hoping to see, however, were some results that quantified the performance and safety aspects of this proposal. I tried to explain what I was looking for in my DISCUSS. draft-ietf-core-new-block basically proposes a send rate control mechanism, to be used in DDoS scenarios, i.e., a component of a transport protocol. The IETF has a pretty well-developed approach for analyzing such mechanisms. As part of that analysis, one would investigate a number of things:

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.

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