Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Fri, 07 May 2021 13:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 757C43A2280; Fri, 7 May 2021 06:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.818
X-Spam-Status: No, score=-2.818 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nce0wg6mGRca; Fri, 7 May 2021 06:56:05 -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 16CE53A227C; Fri, 7 May 2021 06:56:04 -0700 (PDT)
Received: from (unknown [xx.xx.xx.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4FcBmy1g6Wz2y81; Fri, 7 May 2021 15:56:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1620395762; bh=cjzPUKYtbQng5cJaCINn2eTV/p4p2Rx0EsonoT+L7zs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=cIHIh+09YGChO6fvT/m72+Pca9yoSA2lENVhC8FDTob+Q30YMNzBx3OaKpEYA/dcw VuIVeXZ1RgoBZsYvxh59YtPNo3HhAtczaNltfE2gWJvfZmcfYEj4Muk04NSlM/jnLy nlH8fEzFREogqM8lKqKR/3HjtCh6di8GzTKnsxRRGu5upK6AXGj0ZNzkF0AAaoHaYs MmH452auBc4T0J/hEGpd/5yuwU0W9Ku8g6PMsJmx8qv7gM42vyDyYuF8PwVoAafBoT nxs4KKvWliCWHgIrHMmjiGEJ9laqzhBujta5GnCdk6i/qRBD6sw1sORnRBr2VaHfVC NfWtD6Nc5sIIw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4FcBmx759WzCqkf; Fri, 7 May 2021 15:56:01 +0200 (CEST)
To: Lars Eggert <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
Thread-Index: AQHXQz+Tx85/LIwI7Ee6i4xXZSbinKrYAPxQ
Date: Fri, 07 May 2021 13:56:00 +0000
Message-ID: <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Fri, 07 May 2021 13:56:11 -0000

Hi Lars, 

Please see inline. 

Jon & Med

> -----Message d'origine-----
> De : Lars Eggert via Datatracker []
> Envoyé : vendredi 7 mai 2021 14:51
> À : The IESG <>
> Cc :;;
> Objet : Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with
> Lars Eggert has entered the following ballot position for
> draft-ietf-core-new-block-11: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> Please refer to
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ---------------------------------------------------------------------
> -
> ---------------------------------------------------------------------
> -
> [Updating this DISCUSS based on the discussion during the May 6
> telechat.]
> Section 1, paragraph 4, discuss:
> >    There is a requirement for these blocks of data to be
> transmitted at
> >    higher rates under network conditions where there may be
> asymmetrical
> >    transient packet loss (i.e., responses may get dropped).  An
> example
> >    is when a network is subject to a Distributed Denial of Service
> >    (DDoS) attack and there is a need for DDoS mitigation agents
> relying
> >    upon CoAP to communicate with each other (e.g.,
> >    [RFC8782][I-D.ietf-dots-telemetry]).  As a reminder, [RFC7959]
> I understand that COAP was initially chosen to transport DOTS
> signaling messages due to their small size, support for structured
> messages and request/response semantics, as well as the ability to
> function over lossy paths such as found in IoT deployment, which COAP
> is architected for.
> DOTS now seems to desire to transport larger messages, and this
> document extends CORE to enable this functionality. However, this
> CORE extension seems to solely focus on Internet deployment
> scenarios, essentially attempting to re-architect COAP into a general
> Internet transport protocol for transmission over paths with high
> loss rates. It's questionable whether "maintenance of RFC7959" part
> of the current CORE charter covers this document.
> The motivation for this new extension is apparently that RFC7959
> doesn't result in sufficient performance for the DOTS use case,

Actually, the motivation is the lack of support of block-wise for NON messages. This is explicitly indicated in the introduction:

   As a reminder, [RFC7959]
   recommends the use of Confirmable (CON) responses to handle potential
   packet loss.  However, such a recommendation does not work with a
   flooded pipe DDoS situation.

FWIW, here is the full background:


RFC7252 supports two communication types of request in the request/response model as in rfc7252#section-1.2: Confirmable Message and Non-confirmable Message.


CoAP imposes a limitation on the data transmission size as in rfc7252#section-4.6

   A CoAP message, appropriately encapsulated, SHOULD fit within a
   single IP packet (i.e., avoid IP fragmentation) and (by fitting into
   one UDP payload) obviously needs to fit within a single IP datagram.


So then RFC7959 came about to handle single packet limitations by adding in 'block' support. However, it is designed to work with Confirmable, recognizing the limitations of Non-confirmable as in rfc7959#section-1

    The present
   specification minimizes the constraints it adds to those base
   exchanges; however, not all variants of using CoAP are very useful
   inside a block-wise transfer (e.g., using Non-confirmable requests
   within block-wise transfers outside the use case of Section 2.8 would
   escalate the overall non-delivery probability).


draft-ietf-core-new-block provides a missing piece of RFC7959, namely the support of block-wise transfer using Non-confirmable where an entire body of data can be transmitted without the requirement for an acknowledgement.


Like 7959, draft-ietf-core-new-block does not remove any of the constraints posed by the base CoAP specification.

It just 'happens' that there are additional transmission rate benefits (subject to congestion control) when using draft-ietf-core-new-block.

We updated the introduction to clarify this background. Please check: 

Does this clarify your concern?

> timely delivery of larger amounts of data during periods of high
> random loss (i.e., under DDoS). This is a fundamentally hard problem,
> because in order to deliver data in a timely manner in such
> scenarios, the sender needs to be very aggressive, to send enough
> packets into the network so that enough arrive at the receiver to
> make steady progress; and at the same time the feedback channel is
> also severely degraded due to loss.
> The IETF TSV area currently has hence no known good solution for such
> use cases.
> This specification possibly describes such a solution, but I was not
> able to find any evaluation results that would show that this
> proposed mechanism actually delivers the desired performance
> improvements over RFC7959 in the scenarios of interest. I was also
> not able to find any evaluation results of whether the proposed
> mechanism is safe to use in situations that might be easily confused
> with DDoS, such as high-load scenarios that are not of malicious
> origin, or if it even is safe when executing over normal Internet
> paths.
> If such evaluation results exists, would you mind pointing me at
> them?

There is not evaluation paper, but as stated in the thread with Eric V., extensive tests were made that confirmed the benefits. The code giving Q-Block support is out there in the public domain. A pointer is included in the write-up. 

> Without evaluation results that demonstrate that the proposed
> mechanism is effective and safe, I do not believe it should be
> published on the Standards Track. It could go forward as an
> Experimental RFC, supporting an experiment to perform such an
> evaluation.


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.