Re: [Coin] Comments re. draft-irtf-coinrg-use-cases (was: Re: Cancelling the COINRG meeting at IETF113)

[Dirk Trossen <[e-mail]>]

Toerless, all,

As one of the contributors to the content of the use case draft, let me outline a few things that may help understand how we compiled the overall content (which has grown from at least two different contributions to the RG, complemented then with contributions from co-authors that we had sought through list and personal research interactions) - I hope what I will say below captures the intentions of the author set but I do not claim that, so please (my co-authors) extend on anything I will say, if needed, and apologies upfront if I say something you heavily disagree with:

The point of the document is not to outline THE use case for COIN, maybe even the 'killer use case' (some may like us doing this but I always find such angle of discovery fraught for a variety of reasons I won't go into here). 

Instead, we were looking for use cases that may help us formulate challenges and research questions for COIN at large. We then later decided to frame some of those 'COIN aspects' with those prefixed words you can find in the document. The prefixing is not meant to introduce new terms (nor eliminate important differences) but to delimit the challenges and questions to the aspects of COIN that may matter while there are, of course, large-than-COIN aspects that we may not (want to) care about in order to scope discussions. It may not be the best approach of doing this but it felt like a good one at the time of doing so. But again, 'coining' new words is not really what this is about.

Coming back to the list of use cases: when thinking of challenges and possible research questions, even possible requirements to technologies addressing those challenges, it is clear to me that the use cases are not limited to 'new COIN' stuff only. Yes, some very edge computing looking use cases are part of it (most or all of Section 3), where the question is how COIN capabilities could enable new experiences and improve on existing ones (that improvement may be seen as "new" too, if things like dynamicity of interactions or similar is being improved significantly). You then have use cases that may drive the introduction of new 'COIN' systems, found in Section 4 as well as those improve on or introducing new COIN capabilities (Section 5 and 6, respectively). 

This is unlikely a perfect view of looking at use cases but one that is driven by outlining those areas of research that may be impacted by those use cases or where those (existing) use case may be impacted by COIN solutions. For this reason, we also (for now) adopted the categorization of research questions outlined in Section 7, i.e., those RQs going at the heart of COIN (visions and enabling technologies) but also those related to 'applicability areas' (sticking to this word for now until we find a better one or will like it), i.e., areas that may be impacted by COIN (one of which is routing, which showed up early in the history of this work in one of my use cases); you may recognize those categories as largely being those I discussed in my contribution to the interim, derived from my understanding of COIN (charter and discussions so far over the past 3 years or so). 

So this is not about what may be 'in' or 'not in' network (an interesting question though but I would expect that answer from some sort of vision work on COIN) or the difference to 'just distributed apps' (since COIN will execute distributed apps so it is of interest what, if any, will change for those distributed apps if COIN was made reality). 

From my perspective, key of this work but also the wider work in COIN is to find out what the scope and extent of 'COIN' really is when we write 'COIN system' or similar in use cases like that. It may be a lot, or rather little or simply something rather specific (hopefully) that we can put our finger on once the research progresses. It is not about coining terms though; I'm happy to call it anything one wants if that will make you accept the work better but I find a name discussion before a content discussion to always be a slippery slope.

Best,

Dirk

-----Original Message-----
From: Toerless Eckert [mailto:[e-mail]] 
Sent: 13 March 2022 08:33
To: Sharon Barkai <[e-mail]>
Cc: Schooler, Eve M <[e-mail]>; Marie-Jose Montpetit <[e-mail]>; coinrg-chairs <[e-mail]>; Dirk Trossen <[e-mail]>; coin <[e-mail]>
Subject: Comments re. draft-irtf-coinrg-use-cases (was: Re: [Coin] Cancelling the COINRG meeting at IETF113)

Trying to bring back the reply to what Sharon observes to the RGs work, which so far officially only includes the use-cases it seems.

As a very high-level observation, i find it less than ideal to prefix everything in that document equally just with "COIN" because it eliminates important differences and attaches unnecessary a new term to something that already is well known. It would also be good to remember that just because an RG has a particular name, it is not necessary for all technical classiciations to re-use that RGs name.

To me, the mayority of use-cases presented is really "just" distributed applications, which in my view just "use" the network, but which are not "in" the network. Aka:

These use-cases run predominantly on general-purpose compute (x86/arm/risc5) and this compute is somehow distributed and may include mobile components (like user-endpoints).
And we called this distributed applications for decades without anyone ever complaining about that term.

These applications need some varying degree of better-than-best-effort services from the network, such as controlled or guaranteed throughput, latency, loss and availability, and they also may need some multipoint packet delivery, and some discovery functions from the network to seed their self-orchestration. But that set of requirements does in my book not make them "in" the network. That set of requirements existed for decades as well.

Another example: if a vendor like Cisco or Huawei sells a side-edge-device consisting of a  VM/container host system and you can separately instantiate a router, a firewall, a DNS, an email, a web and a bunch of other servers: That to me is not "compute in the network".
That is just softwareization to combine decade old functions/devices into a single box.

So, to me, 5.3, (Virtual Network Programming), is the only proper "in network" case described in the document. 

Now, my understanding of what's in and whats not in the network might be different from what the RG mayority wants, but at least it would be great to spend more time with a somewhat longer list of examples and explain for each of them whether why and how its considered to be in or out, if in and out is really what the RG wants to define.

IMHO, it would be more productive to come up with a more differentiated set of classifications.
Distributed applications and their needs for better network services do not become less important by NOT giving them a new name COIN.

One could also simply rename the RG to "Computer Over and In the Network" if one feels the risk of kicking all the interesting work out of scope by not declaring it to be "in".

Cheers
    Toerless

On Sat, Mar 12, 2022 at 10:51:14PM +0200, Sharon Barkai wrote:
> There is some duality in the list between those focusing on making switches/routers more like computers, and those focusing on using the network cloud as a well .. a cloud - for when it fits - topology, sharding, privacy etc.
> 
> In my view these are simply bottom-up top-down sides of the same you know… so im sure the chairs will settle this in time with proper frameworks. 
> 
> We needn't start from scratch on neither. Theres been good existing proposals for baseline on both fronts already.  
> 
> --szb
> Cell: +972.53.2470068
> WhatsApp: [phone]
> 
> > On Mar 11, 2022, at 10:36, Schooler, Eve M <[e-mail]> wrote:
> > 
> > 
> > Hi Dirk, All,
> >  
> > My apologies about the ambiguity in the comment about the agenda. It was intended to convey that we struggled to have a FULL agenda, and NOT to pass judgement on the quality of the topics that might have been presented. Of the individuals we reached out to present, many stated the day/timing simply did not work out.
> >  
> > As for transparency…If you are a regular reader of this list, then it is painfully obvious that there has been quite a bit of divisiveness happening both on and off the list. As chairs, given the state of the agenda and the tone of the dialog, we felt the need to take a step back from the vitriol and simply take a deep breath to regroup. 
> >  
> > We certainly have valued the continued involvement of the COIN community, which has made many of the discussions vibrant and rewarding.  
> >  
> > Best regards,
> > Eve
> >  
> > From: Coin <[e-mail]> On Behalf Of Dirk Trossen
> > Sent: Thursday, March 10, 2022 10:30 PM
> > To: Marie-Jose Montpetit <[e-mail]>; coin 
> > <[e-mail]>
> > Cc: coinrg-chairs <[e-mail]>
> > Subject: Re: [Coin] Cancelling the COINRG meeting at IETF113
> >  
> > Hi J/E/M, all,
> >  
> > Now that’s a surprise, not just in content but also in style since the RG community lacks the transparency of this decision.
> >  
> > As a COIN RG member myself for now more than 3 years (spanning two organizations), I had looked forward to discussing at least three activities in which I am involved in, namely the (i) use case advances (trying to formulate and categorize the pertinent research questions in a number of COIN areas), (ii) the applicability of SDN for routing (i.e. the use of DP programmability for realizing novel routing solutions, which according to the chairs is in scope of COIN), and (iii) a discussion on how COIN could help improve on DLT realizations; all activities resulting from research on topics I see as relevant to and within COIN.
> >  
> > So this gives already three agenda items from where I’m coming from (depending on willingness for time allocation, between about 45 to 60mins on an agenda in my mind) but yet we are told at ‘we cannot put a good agenda together’. Is there nothing beyond these items, really, and/or is this a judgement of those items in quality (I would expect good discussions on them but maybe it is just me)?
> >  
> > So I’m disappointed but also shocked by this style of simply cancelling the RG meeting with that (too) thin ‘we cannot put a good agenda together for IETF113’ explanation. I cannot and do not see the reasoning behind it albeit I may speculate but I am not a friend of those second guesses.
> >  
> > Hence, I would ask the community here: what discussions were we looking forward to have? Are those good enough to discuss regardless of the RG meeting being cancelled? If there is no RG meeting for whatever reason, maybe we can simply come together among those interested in those discussions and have them regardless, such as in a side meeting of the ‘COIN community’ (not the RG)?
> >  
> > From my side, I would be highly interested in that since I have valued the COIN discussions over the past years and don’t want to let go of this for reasons that are just not well enough explained below.
> >  
> > Best,
> >  
> > Dirk
> >  
> > From: Coin [mailto:[e-mail]] On Behalf Of Marie-Jose 
> > Montpetit
> > Sent: 11 March 2022 00:45
> > To: coin <[e-mail]>
> > Cc: coinrg-chairs <[e-mail]>
> > Subject: [Coin] Cancelling the COINRG meeting at IETF113
> >  
> > Dear all:
> >  
> > Because of many converging issues, delays and (non) availability of invited researchers and papers we cannot put a good agenda together for IETF113.  Hence we are cancelling the meeting.
> >  
> > We plan to re-group, consult the community and plan for 114.
> >  
> > Discussions on the use cases and other important COIN topics will have to continue or be initiated on the list for now. Of course as the co-author of a draft that was going to be presented I am disappointed.
> >  
> > The co-chairs are in full agreement that this is the right decision at this point and the IRTF leadership has been kept in the loop.
> >  
> > J/E/M
> >  
> > Marie-José Montpetit, Ph.D.
> > [e-mail]
> >  
> >  
> > --
> > Coin mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/coin

> --
> Coin mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/coin


-- 
---
[e-mail]