[core] Protocol Action: 'Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission' to Proposed Standard (draft-ietf-core-new-block-14.txt)
The IESG <firstname.lastname@example.org> Thu, 27 May 2021 13:59 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 307C93A0D77; Thu, 27 May 2021 06:59:42 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: The IESG <email@example.com>
To: IETF-Announce <firstname.lastname@example.org>
Cc: The IESG <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
Content-Type: text/plain; charset="utf-8"
Date: Thu, 27 May 2021 06:59:42 -0700
Subject: [core] Protocol Action: 'Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission' to Proposed Standard (draft-ietf-core-new-block-14.txt)
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2021 13:59:42 -0000
The IESG has approved the following document: - 'Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission' (draft-ietf-core-new-block-14.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ Technical Summary The document defines two new options for the Constrained Application Protocol (CoAP), namely Q-Block1 and Q-Block2. The two options enable effective block-wise transfers of large data payload, also under network conditions where asymmetrical transient packet loss may be experienced. The main use case addressed by this document is a network under Distributed Denial of Service (DDoS) attack, where DDoS mitigation agents are still required to exchange large amount of data using CoAP. This use case is especially targeted in the DOTS Working Group, where the use of the two new options is suggested in its DOTS Telemetry, see https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ Compared to the similar options Block1 and Block2 defined in RFC 7959 --- which are based on synchronous, lock-step exchanges of blocks, and thus can be ineffective or even prohibitive to use under a DDoS situation --- the new options enable faster transmission rates with less packet interchanges, as well as faster recovery of lost blocks. The document also defines congestion control procedures to be used when the Q-Block1 and Q-Block2 Options are used over an unreliable transport. Working Group Summary The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews. During and after Working Group Last Call, effort was also put in better reflecting how design choices align with the intended scope of the document, i.e. to serve especially use cases with asymmetrical transient packet loss and particularly the DOTS Telemetry, see https://datatracker.ietf.org/doc/html/rfc8782 and https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ Consensus has been reached on the scope, content and level of detail of the document. Document Quality A Pull-Request of an author's implementation to "libcoap" is available at https://github.com/obgm/libcoap/pull/611 Feedback from the implementation activity has contributed to the design and refinement of specific aspects, notably: - Limiting new mechanics for congestion control only to CoAP Non-Confirmable messages. - Not mixing CoAP Confirmable and Non-Confirmable messages for a same request/response body. - The 'Continue' indication of successfully received blocks. - The discovery of server support for the Q-Block1 and Q-Block2 Options. - Further lessons learned highlighted as "Implementation note" in the document. Personnel Document Shepherd: Marco Tiloca <firstname.lastname@example.org> Area Director: Francesca Palombini <email@example.com>