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

["\"David R. Oran\"" <[e-mail]>]

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, 25th Nov. We need a rough consensus in this RG before we move it to IRSG review. Please review it and send your comments to this list. 
>
> 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.
	- 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.

- 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?

- 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.