Subject: [Coin] Comments on draft-kunze-coin-industrial-use-cases

From: <[email-masked]>
Date: Mon, 2 Nov 2020 16:43:33 +0000

Ike, Klaus,

A couple of comments on https://datatracker.ietf.org/doc/html/draft-kunze-coin-industrial-use-cases-03

S4.1

<<Apart from the control model, the quality of the control primarily
   depends on the timely reception of the sensor feedback, because the
   controller can only react if it is notified of changes in the system
   state.  Depending on the dynamics of the controlled system, the
   control can be subject to tight latency constraints, often in the
   single-digit millisecond range.  While low latencies are essential,
   there is an even greater need for stable and deterministic levels of
   latency,

The figure implies that the feedback can come from multiple sensors. There may be scenarios (maybe S6?) where this adds to the difficulty of ensuring the feedback latency is low and stable /deterministic - for instance the data from different sensors follows a different network path

S5.1
Your discussion about data rates (generated vs capacity) suggests to me that filtering &/or aggregation is a key functionality. This implies, I think, that it's done before the data is encrypted (may be OK local to the sensors) or the filtering device can decrypt, & re-encrypt, the data (assuming homomorphic approaches are further in the future). The approach (in S5.2.1) of letting through every fifth packet implies that the filter can identify which of the encrypted packets contain the sensor data (as opposed to other msgs), and that a packet contains a complete measurement (no chance of being split between packets) - not sure these generally hold.

Thanks for the document,
Best wishes,
Phil

---

From: Ike Kunze <[email-masked]>
Date: Tue, 3 Nov 2020 08:07:15 +0000

Hi Phil,

thanks for taking the time to read the draft and for your comments.
Please see inline.

Best,
Ike

On 2. Nov 2020, at 17:43, [email-masked]<mailto:[email-masked]> wrote:

Ike, Klaus,

S4.1

The figure implies that the feedback can come from multiple sensors. There may be scenarios (maybe S6?) where this adds to the difficulty of ensuring the feedback latency is low and stable /deterministic – for instance the data from different sensors follows a different network path

[IK] Thanks for pointing that out. You are correct. Depending on the scenario, multiple sensors might indeed be used for the control process and this makes the whole thing more difficult. While the control loop should be dominated by the sensor with the slowest response, it requires stable/deterministic responses for all sensors.
That is certainly an aspect that we can emphasize in the next update.

S5.1
Your discussion about data rates (generated vs capacity) suggests to me that filtering &/or aggregation is a key functionality. This implies, I think, that it’s done before the data is encrypted (may be OK local to the sensors) or the filtering device can decrypt, & re-encrypt, the data (assuming homomorphic approaches are further in the future). The approach (in S5.2.1) of letting through every fifth packet implies that the filter can identify which of the encrypted packets contain the sensor data (as opposed to other msgs), and that a packet contains a complete measurement (no chance of being split between packets) – not sure these generally hold.

[IK] Yes, growing data volumes are key challenges for the industrial domain and our discussions in that section, and in most other sections, currently assume that data is not encrypted (something we could observe in many ‘closed’ industrial settings). Decrypting and re-encrypting encrypted data for aggregation is of course an option if/once the required capabilities are there; for now I think that aggregation is not really possible on encrypted data.

Regarding filtering, you are right that we have some implicit assumptions in there that might not hold in general (we should clarify them in the next update).
Additionally, I believe that the aspects you mention might be closely related to some of the discussions on the transport issues (https://datatracker.ietf.org/doc/draft-kunze-coinrg-transport-issues/).
It is, e.g., an open question how COIN functionality should be addressed by the end-hosts. In the filtering setting, packets destined for filtering, i.e., those containing sensor data, could then include such an addressing for the filtering mechanism while other msgs might not need it. This way, the filtering mechanism could identify which packets to filter even if the actual content is under encryption.
Similarly, we have an open question regarding the ‘flow granularity’ which, e.g., entails the question in which units data should be fed to COIN functionality such as the filtering.
Depending on the results of the corresponding discussions, COIN functionality might use a data granularity beyond the notion of ‘packets’ and instead, e.g., work on messages.
In that context, our example of dropping every fifth packet is of course obsolete.
Perhaps a more general description of the scenario combined with pointing out the implicit assumptions is a way to move forward.

Thanks for the document,
Best wishes,
Phil

--
Coin mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/coin