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

[[e-mail]]

Hi Christian,

Thank you for sharing your thoughts. 

I don't see where in the two drafts an observer can request a particular missing fragment. 

Cheers,
Med

> -----Message d'origine-----
> De : Christian Amsüss [mailto:[e-mail]]
> Envoyé : mardi 7 avril 2020 15:10
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [e-mail]; Jon Shallow ([e-mail]);
> [e-mail]
> Objet : Re: [core] Large asynchronous notifications under DDoS: New
> BLOCK Option?
> 
> 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)