Re: [Coin] Reminder:Last Call for the use case draft - Comments starting with section 4.3

["Kunze, Ike" <[e-mail]>]

Hi Dave,

Thanks again for taking the time to review the draft and sorry for the late response.
As before, please find my comments to parts that I could directly address below ([IK]) while I will discuss with my co-authors regarding your other comments.

Cheers,
Ike

> On 28. Nov 2023, at 15:46, David R. Oran <[e-mail]> wrote:
> 
> On 21 Nov 2023, at 4:47, JEF wrote:
> 
> Hi, 
> I'd like to remind you that the last call for our use case draft will end this Saturday,&nbsp;25th Nov. We need a rough consensus in this RG before we move it to IRSG review.&nbsp;Please review it and send your comments to this list.&nbsp;
> 
> Below is the link to this draft. 
> https://datatracker.ietf.org/doc/draft-irtf-coinrg-use-cases/
> 
> 
> Continuing my comments, starting with Section 4.3
> 
> Section 4.3
> 
> Not really a criticism on the introductory text, which is fine, but my strongest memory on factory floor safety was the bright red tape marking on the floor surrounding industrial robots, which indicated the maximum physical reach of the device. The person giving the tour pointed these out as the MOST important safety feature by saying that he could re-program the robots from his living room any time so by just watching the cameras and watching the victim, he could whack them with the robot if he wanted.
[IK] I agree. Solutions like that are still very prominent for stationary robots and that is also the reason why we talk about the explicit division of the working area.
I also think the example you mention gives a good sense of what such markings are supposed to achieve, i.e., give humans an understanding of what they might have to expect.
I have added a corresponding sentence to Section 4.3.2.

Changing the scenario to mobile robots, I do not think that a simple red tape will be good enough for much longer which is actually the setting that we are somewhat aiming at.
I will try to sharpen my thoughts there a bit further, so thanks for bringing this up.
> my take is that the software approach likely makes the environment LESS safe, not more. Perhaps one angle on using COIN approaches is that they can provide an independent IN PATH surveillance of software initiated actions to block unsafe commands.
[IK] I understand and somewhat agree with your concern (safety and software often makes me think about this comic although it does not fit to 100 percent: https://xkcd.com/2030).
To me, the main potential lies in exploring ways how safety could be enhanced/extended using such approaches, e.g., giving earlier warnings, while I do not think that getting rid of all hardware safety mechanisms is a good idea just yet.
In fact, I also had approaches similar to the one you mentioned in mind and would add your suggestion to this section.

> Section 7 (security considerations)
> 
> At the risk of being laughed at maybe mention Functional or Homomorphic encryption as a workaround for cleartext data exposure to COIN intermediaries?
> this might be a good place to talk about how applications may need to be cognizant of the presence of COIN intermediaries, and perhaps re-encode their data to do selective encryption that allows the COIN intermediaries to get at the pieces of data they need without exposing everything.
> You need to talk about privacy as well. Not sure what exactly to say, but I’m sure you can come up with something reasonable.

[IK] Thank you for bringing up the security considerations and the privacy aspect!
At the beginning of COIN, the security implications were still very unclear which also explains the current scope of that section.
However, in the meantime, (and now I can only speak for myself) I have worked with a few people on approaches that could provide some of the aspects you mention.
In fact, we have an upcoming AsiaCCS paper that specifically deals with the “selective encryption” bit of your suggestions, essentially giving intermediaries bit-level read/write privileges in a DTLS connection while also providing.
I will ask my co-authors (of the AsiaCCA paper)  and will try to can get a bit more and sharper content into the security (and privacy) considerations section.

For the remaining comments, I will check with my co-authors (of this draft).

> 
> Section 5.1
> 
> In the description, CDNs actually have two purposes. One is to reduce latency, but the other is to reduce load on origin servers. I suspect there are COIN angles to the latter as well as the former.
> A reference to switch-based load balancing (e.g. Silkroad https://dl.acm.org/doi/10.1145/3098822.3098824) would help justify this use case for the reader.
> Under opportunities, I’m not sure why you introduce multicast (e.g. the [FCDN] reference) and then don’t follow it up with any elaboration on where COIN fits in with enabling or optimizing multicast approaches to CDN fanout.
> I didn’t quite follow why you couch the applicability of service based routing in terms of routing to COIN program instances. It would seem the reverse is more compelling - using COIN instances to integrate service measurement data and then route from that COIN instance, to the selected service instance. What am I missing here?
> On a similar vein, the second opportunity talks about how something (you don’t say what) is doing the work to decide which COIN instance to use for something, as opposed to describing what the COIN instance would be doing to make the system better.
> On bullet three, I would have thought using multicast would reduce network utilization, not increase it.
> For the research questions, they seem to be couched in very general terms not specific to, or even oriented to, COIN issues. I’d suggest some re-formulation to target directly at COIN, such as how on-path intermediaries implemented in COIN instances can do the things mentioned in the research questions.
> In RQ 5.1.3 joint optimization of compute and routing may or may not involve and constraint-based computations.
> Section 5.2
> 
> In the description, why limit to Layer 2? in fact, I suspect nearly all the environments you mention use layer 3 topologies, not layer 2 (admittedly, early datacenter interconnects treated L3 as an overlay, but I’m pretty sure that’s no longer the case). For WAN connectivity, a similar evolution is happening.
> The legacy requirement of compute interconnect necessitating direct layering over L2 protocols is rapidly becoming anachronistic. Certainly to my knowledge all the micro-service based approaches assume IP, not L2 connectivity. I’d suggest focusing this use case toward the future, to the past. This applies to the direct use of L2 multicast (as opposed to IP approaches like SSM) as well.
> You mention trust relationships, but then don’t follow that up with any further discussion. If the creation, maintenance, and enforcement of trust relationships is relevant to COIN it would be really useful to discuss that explicitly (my opinion - I think it is relevant).
> No comments on Section 5.3
> 
> Section 6.1
> 
> it would be helpful to separate inference from training, as the requirements are mostly distinct, and the effect on COIN approaches, especially in terms of memory load, are worth separate discussion.
> in the training aspect, I suspect there is a good role for COIN approaches in optimizing back-propagation where there are a plethora edge clients performing inference.
> I’m not sure why you focus again on constraint-based routing in this use case. It may apply, but again I suspect that the actual constraint-based operations are not going to be performed by COIN programs - they are gong to execute the routing/forwarding/processing instructions that are the output of the constraint-based calculations. Perhaps just talk about COIN instances being the recipients of control-plane (or management plane) input to the state held by the COIN program to use in operating on its inputs.
> What does RQ 6.1.2 have to do with this use case? I was scratching my head on why the AI applications in either training or inference generate “rapidly changing receiver sets”.
> In RQ 6.1.4 what’s the relevance of HTTP to the AI use case?
> -- 
> Coin mailing list
> [e-mail]
> https://mailman.irtf.org/mailman/listinfo/coin