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

[[e-mail]]

Jon,

If we had https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-08#section-5.7, this would solve the issue. Nevertheless, this is not implemented/deployed. 
Your proposed option mimics the UDP FRAG behavior. 

Because re-assembly would fail if a fragment is missing, notification fragments with the new options should be sent, e.g., three times. 

Ideally, we need a solution that allows to make use of partial responses even if other fragments are lost. 

Before considering a new option, let's see if we can solve this at the DOTS layer. For example, we do have the following to avoid fragmentation: 

   If the total request size exceeds
   the path MTU then the DOTS client MUST split the DOTS signal into
   separate messages; for example, the list of addresses in the 'target-
   prefix' parameter could be split into multiple lists and each list
   conveyed in a new PUT request. 

Does your implementation allow to follow a similar approach when sending notifications? For example, a first notification can include attack-traffic metrics and others include attack-details? 

Because all these notifications are bound to the same tmid, the DOTS client will update its local records with the data received in multiple notifications. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[e-mail]] De la part de Jon Shallow
> Envoyé : lundi 6 avril 2020 11:35
> À : [e-mail]
> Objet : [Dots] draft-ietf-dots-telemetry: Large responses
> 
> 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
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots