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

[Jon Crowcroft <[e-mail]>]

there's a nice list of use cases in
https://dl.acm.org/doi/pdf/10.1145/3452296.3472905

first parageaph of introduction
see refs
distributed applications [45, 47, 67, 73, 78].
> 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]
> 
> --
> Coin mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/coin
>