Re: [core] Large asynchronous notifications under DDoS: New BLOCK Option?

[Christian Amsüss <[e-mail]>]

Hello Jon, hello Med,

I don't have full answers, but some data points (also pulling in the
cited mail):

> and a response (may need new code) that says status is too large to
> fit into a packet or has been truncated).

That an observation with blockwise would already do: If the observed
resource changes to have its representation larger than the block size
or MTU, it'd send the first block.

> The observer will follow a SACK-like approach to request
> retransmission of missing fragments.

There was a draft around on non-traditional responses[1] some time ago
that would provide building blocks from which a server could send
follow-up blocks in an unsolicited fashion: The second block would be a
message in the style of "This is a 2.05 Content response, which you
would have received as a response had you requested block2 of /path".

Those messages would not be ack'ed if they are NON, and the client can
selectively request blocks it thinks it missed (but, in such a setup,
would do that after a suitable timeout to not request something that is
already in flight).

That draft was not followed up on directly, but some of its ideas wound
up in [2] where observe notifications are sent to a multicast group. In
particular, the topic of which tokens would be usable for unsolicited
responses to unicast addresses has not received the discussion it'd
probably need.

Kind regards
Christian

[1]: https://tools.ietf.org/html/draft-bormann-core-responses-00
[2]: https://tools.ietf.org/html/draft-tiloca-core-observe-multicast-notifications-02


-- 
The detailed semantics of CoAP methods are "almost, but not entirely
unlike" [HHGTTG] those of HTTP methods.
[HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979.
  -- Shelby, et al., Internet-Draft Constrained Application Protocol (CoAP)