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.
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.
Document Shepherd: Marco Tiloca <firstname.lastname@example.org>
Area Director: Francesca Palombini <email@example.com>