[Dots] draft-ietf-dots-telemetry: Large responses

[Jon Shallow <[e-mail]>]

Hi All,

With support for telemetry status updates, there is a good chance that a
status response will not fit into a single IP packet.

Do we need a new CoAP Option or response code?

These status responses are sent back using CoAP NON-confirmable packets - in
other words the DOTS client does not have to acknowledge receipt of the
packet which works in an environment where there is heavy packet loss in the
same direction as the status packet - the DOTS server is not waiting on
acknowledgement of the previous status packet before sending out the next
one (which too may get dropped).

For the status data that is larger than an IP packet, this can currently be
handled in 2 ways that I can think of
1- Let IP fragmentation be used by sending large data that is fragmented
across several IP packets
2- Make use of the CoAP BLOCK2 option (RFC9759) which is already referred to
in the signal draft to create CoAP fragmentation.

The disadvantage of (1) is that the receiving CoAP library has to have a
large enough receive data buffer size to handle both the encrypted and then
plaintext data.  The libcoap library I use has the default receive buffer
sized for that of an IP packet that is not fragmented.  This buffer can be
made bigger, but how big?
What if the DOTS client is a constrained device with RAM etc. limitations?
There is also a challenge of managing missing IP fragmented packets which is
primarily done by the network stack.

The disadvantage of (2) is that BLOCK2 is a synchronous transmission where
the DOTS client receives a block of data and then has to request the next
block of data.  With a lossy network, if the client does not see a block of
data then this status data transmission will stall and not recover leaving
the DOTS server with outstanding data that cannot be transmitted and hence
the need for garbage collection of failed transmissions.
Furthermore with (2), RFC9759 recommends use of CONfirmable responses to
handle potential packet loss - which does not work with a flooded pipe DDoS
situation.

I agree that if all can fit into one packet then this is not an issue, but
enforcing that is difficult unless there are data reduction policies in
place (such as using Queries or the remainder of the data is not sent
(parameter/values deleted) and a response (may need new code) that says
status is too large to fit into a packet or has been truncated).

Another possibility is to create a new CoAP option that is equivalent to
BLOCK2 in format but does not need to work symmetrically.  Here, the DOTS
server sequentially sends all of the CoAP fragmented data without requiring
the DOTS client to request the next block (just as fragmented IP packets
would be sent).  It would then be up to the DOTS client to do the CoAP plain
text block fragmentation re-assembly (again a limitation requiring more RAM
on the DOTS client and garbage collection if there are missing packets).
Using this new option reduces the load on the DOTS server who could be
serving many DOTS clients.

Thoughts?

Regards

Jon