Subject: [Coin] Cancelling the COINRG meeting at IETF113

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 10 Mar 2022 15:45:05 -0800

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.
[email-masked]

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 11 Mar 2022 06:29:46 +0000

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:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: 11 March 2022 00:45
To: coin <[email-masked]>
Cc: coinrg-chairs <[email-masked]>
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.

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.
[email-masked]<mailto:[email-masked]>

---

From: Ike Kunze <[email-masked]>
Date: Fri, 11 Mar 2022 07:09:25 +0000

Hi Dirk, all,

I would also be interested in understanding what makes the currently planned agenda “not a good agenda”.
If it is just a lack of quantity, I would actually look forward to once having a meeting where discussions are not cut short due to time limits :)

If, however, the RG meeting is indeed cancelled, count me in for the “COIN community side meeting”.

Best,
Ike

On 11. Mar 2022, at 07:29, Dirk Trossen <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>> wrote:

Hi J/E/M, all,

Best,

Dirk

From: Coin [mailto:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: 11 March 2022 00:45
To: coin <[email-masked]<mailto:[email-masked]>>
Cc: coinrg-chairs <[email-masked]<mailto:[email-masked]>>
Subject: [Coin] Cancelling the COINRG meeting at IETF113

Dear all:

J/E/M

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

---

From: "Schooler, Eve M" <[email-masked]>
Date: Fri, 11 Mar 2022 08:35:16 +0000

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 <[email-masked]> On Behalf Of Dirk Trossen
Sent: Thursday, March 10, 2022 10:30 PM
To: Marie-Jose Montpetit <[email-masked]>; coin <[email-masked]>
Cc: coinrg-chairs <[email-masked]>
Subject: Re: [Coin] Cancelling the COINRG meeting at IETF113

Hi J/E/M, all,

Best,

Dirk

Dear all:

J/E/M

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 11 Mar 2022 08:55:42 +0000

Hi Eve,

Thanks, I appreciate addressing the ambiguity; I did not seriously expect you would have a truly negative view on the contributions suggested so far but it may be good for others to have this clarified.

My comment on transparency was purely related to the fact that I do not know which topics could have made an agenda since slot requests are often sent directly to the chairs, not the list, so I don’t know how much ‘not full’ there is or isn’t it.

I clearly recognize the issues on the list in the recent past but this seems to be somewhat orthogonal to not get a full agenda (in terms of items) since your text seems to imply that this recent discussion may have contributed to the cancellation of the meeting. If that is so, then this is something I am worried about since it indicates an apparent chasm and I’ve never been friend of ‘camp culture’ – in particular for the recent discussion, I’m somewhat in both those camps as a member of COIN with lots of understanding for your reasoning (and own ongoing work that I see fully aligned with COIN) but also being involved in the argumentation that routing research deserves a place in the IRTF (for which COIN is only a home in a very limited way).

This leaves me now at the point where I agree that we need to address this chasm and resolve the potential impact on COIN but do think that this should not happen at the cost of not having an RG. Maybe as a compromise, having ‘just’ a community meeting is a way forward to keep the community work alive and going forward, while the RG takes the ‘deep breath’ as an organization, as you suggest.

Best,

Dirk

From: Schooler, Eve M [mailto:[email-masked]]
Sent: 11 March 2022 09:35
To: Dirk Trossen <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; coin <[email-masked]>
Cc: coinrg-chairs <[email-masked]>
Subject: RE: [Coin] Cancelling the COINRG meeting at IETF113

Hi Dirk, All,

Best regards,
Eve

From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of Dirk Trossen
Sent: Thursday, March 10, 2022 10:30 PM
To: Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>; coin <[email-masked]<mailto:[email-masked]>>
Cc: coinrg-chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Coin] Cancelling the COINRG meeting at IETF113

Hi J/E/M, all,

Best,

Dirk

Dear all:

J/E/M

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 11 Mar 2022 18:49:15 +0100

> 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 s…

I am sorry to hear that you feel that way. But you can imagine that
anybody who might feel addressed by your "vitriol" would not be happy about that
name calling either. I for once don't that anybody did spill vitriol, and especially
if you think i did, then i would very much appreciate if you would call such
a perception out, for example in private mail, before making it lead to such
choices for the RG.

I am also not sure where there would be divisiveness in the community wrt. COIN work.
As i said, with a charter as openly written, there is a lot of freedom to put
work items in or out of scope, and the chairs did attempt to define a line
what was in and out. In response, i was suggesting a technical presentation
that was intended to describe the intricate dependencies between what was
declared to be in and what was maybe? declared out (not to dissimilar to what IMHO
the use-case draft has), but with use-case examples focussed on what i think
we would call semantic addressing. To help continue that technical/research discussion.

In any case, it would be nice to understand if/when you would make a decision
whether to accept my proposal for a presentation based on the outline i sent.

Cheers
    Toerless

> [email-masked]

-- 
---
[email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 11 Mar 2022 21:49:21 +0000

sorry, but you are wrong.

> > 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
> >
> > 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
> >
> > Cc: coinrg-chairs 
> <[email-masked]<mailto:[email-masked]>>
> > 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.
> >
> > 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
> >

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 11 Mar 2022 23:42:57 +0100

> sorry, but you are wrong.

About what ?

---

From: Sharon Barkai <[email-masked]>
Date: Sat, 12 Mar 2022 22:51:14 +0200

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: +1.650.492.0794

> On Mar 11, 2022, at 10:36, Schooler, Eve M <[email-masked]> wrote:
> 
> 
> Hi Dirk, All,
>

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 13 Mar 2022 08:33:00 +0100

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

-- 
---
[email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 13 Mar 2022 09:51:05 +0000

> About what ?

if several people perceive divisiveness in a debate, then it is there, by definition.
if you don't perceive it, that's fine, but that doesn't make it not so.

talking about the tone or a dialog is not name calling. it is an observation.

perhaps we need an in-network moderator for this group - 

now there's an "AI in a switch" challenge, 
especially if you consider the ethical challenges of such a technology :-)
(not least privacy and key sharing with third parties)....

going back on topic, for me, the scoping problem with the semantic routing&addressing work
is that it was originated in response to soling limitations of routing and addressing, but is
clearly not rooted in what one would design for identifying and path finding to and between
distributed applications running in switches and routers as well as end systems, beyond
applications that were only concerned with the business of routing....

identifiers and locators for distributed computational objects in general would have a whole
slew of other attrbutes and characterists (I would guess) that would deal with the
requirements (e.g. from other coin type use cases than routing) of those applications...

i think t his is a post-layering type challenge - of course, one can hack up a network layer
identifier system to name/find computational stuff (especially with big ipv6 identiefiers) -
or one can do this with application layer ids (URIs etc), or one could try to design something
fit for purpose from scratch (just for example thinking about security needs of such systems,
seems different, in general, than those for the routing infrastructure)....

now t hat'd be a fun project!

> > > name calling either. I for once don't that anybody did spill vitriol, 
> and
> > > especially
> > > if you think i did, then i would very much appreciate if you would 
> call
> > > such
> > > a perception out, for example in private mail, before making it lead 
> to
> > > such
> > > choices for the RG.
> > >
> > > As i said, with a charter as openly written, there is a lot of 
> freedom to
> > > put
> > > declared to be in and what was maybe? declared out (not to dissimilar 
> to
> > > what IMHO
> > > whether to accept my proposal for a presentation based on the outline 
> i
> > > sent.
> > >
> > > Cheers
> > >     Toerless
> > >

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sun, 13 Mar 2022 05:08:49 -0700

Toerless:

The work of the RG is not only about use cases. You are evaluating the work
of a RG like the one of a WG namely in the number of drafts (and BTW we
have a few others). Producing drafts is not the goal. We have a strong
recommendations from Colin to create an agora for researchers to come and
present their research. That may or may not result in drafts. We also had a
number of hackathons (and we may start them again now that P4 has been
ported to PIs) to try out some “in network” ideas in P4. I would refer you
to the work presented in our meetings in the past 3 years and please tell
me that they are only use cases on distributed applications.

As per the use case it is an attempt to see what happens to a number of
applications once that computing is available in the network elements. You
are not the first one to comment on that. There has been a lof discussion
about the difference between in network (in the router) and adding a side
device. Of course the side device becomes an edge and there is a fine line.
I would refer to yo the now seminal Netcache paper that combines PISA
switching and GPU. And Dave Oran also discussed on this list and in
meetings about the difference between “in” and “on” network. That’s the
beauty of a RG we can discuss this and do not have to produce drafts. If
you have specific recommendations for the draft please make them. As a
co-author I note your recommendations.

Personally my view for COIN is that of an Internet that resembles a
computer board (not a telephone network) and we are in someway defining its
elements and its operating system. Traditional operations including routing
may take a new life. And I tell my students to think of the “life of a
packet” when network elements can modify the packet not just forward them
(from the stack in their phones all the way to the data centers). Noa
Zilberman of Oxford U. talks of computing service providers when computing
is available in the network in RANs for example. There is a large community
of researchers looking at how to create new paradigms for assembling
compute/forward elements to offer new functionalities (in video for
example). In that context many concepts may change, including routing. This
is the research I am interested in. Maybe there will be drafts. Maybe not.

I note the suggestion for a name change but I do not think it will happen
based on your (mis)understanding of one draft.

And I would respectfully request a toning down of your snide comments. You
may not think our work is to your liking and this is fine. You may think we
need people like you to anchor of blue sky thoughts in reality and we thank
you but a more positive approach would yield better results. Criticism is
too easy.. And if you think the RG is not doing quality work or the the
chairs are incompetent or ineffectual raise it with Colin and even the the
IAB. We are ready for any review.

mjm

From: Toerless Eckert <[email-masked]> <[email-masked]>
Reply: Toerless Eckert <[email-masked]> <[email-masked]>
Date: March 13, 2022 at 3:33:21 AM
To: Sharon Barkai <sharon.barkai=[email-masked]>
<sharon.barkai=[email-masked]>
Cc: Schooler, Eve M <[email-masked]>
<[email-masked]>, Marie-Jose
Montpetit <[email-masked]> <[email-masked]>, coinrg-chairs
<[email-masked]> <[email-masked]>, Dirk Trossen
<dirk.trossen=[email-masked]>
<dirk.trossen=[email-masked]>, coin <[email-masked]>
<[email-masked]>
Subject:  [Coin] Comments re. draft-irtf-coinrg-use-cases (was: Re:
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.
> > 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.
> > Now that’s a surprise, not just in content but also in style since the
RG community lacks the transparency of this decision.
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.
(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.
> > 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.
> > 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.

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 13 Mar 2022 16:03:40 +0100

> if you don't perceive it, that's fine, but that doesn't make it not so.

Thanks for explaining. Interesting definition. I am not sure i can draw that definition
from what i can find on Merriam-Webster or the like though. My comment came from thinking
divisiveness is a judgmenet about somebody else's intent, and i don't think anyone here
has the intent to be divisive. But of course: good intentions are the shortest path to hell ?
(i am probably not correctly restating that old saying either ;-)

> applications that were only concerned with the business of routing....

Ok. Thats dense for me (as in "i may not fully grasp it"). As said in my other mail, i'd be
happy to even just consider classical distributd applications utilizing network services
without even thinking of what it means for an application to be "in the network".

So, historically for example, we had
application layer routing/forwarding, for example in CDN, hop-by-hop across "web-caches".
Then we tried to define the next-gen of that application layer routing/forwarding via
ICN/CCN as a new network layer. Arguably a form of semantic routing (to me). Is that not
an example contradicting your claim ? How about all those other "URL" application routing
systems, MQTT, XMPP and the like ? Or historic ones like UUCP/usenet ? Haven't network layers
not always been an attempts to extract the pieces necessary for hop-by-hop operations
from distributed  application layers to speed up applications and be able to put the
forwarding/routing into faster/cheaper devices ? 

> requirements (e.g. from other coin type use cases than routing) of those applications...

We surely will find more interesting semantics as soon as we expand the scope of
entities to forward/route beyond datagrams. We already see this in ICN, where i think
we would call the entities transations? And of course, whereever we have flows, our
entities are connections.Not sure what a "computational object" is though. What is a
non-computational object ?.

> or one can do this with application layer ids (URIs etc), or one could try to design
> something > fit for purpose from scratch (just for example thinking about security needs of
> such systems, seems different, in general, than those for the routing infrastructure)....

> now t hat'd be a fun project!

Sure. On the other hand, if we wanted to explore the name space for semantics first
that do not create privacy concerns, then we would likely exclude those application
specific options. But IMHO still keep a large amount of interesting, not well explored
options on the table. Btw: i am a big fan of being able to use application-semantics
in forwarding, because moving something like MQTT/XMPP style application orchestration
via appropriate application address semantics down to Gigbps programmable forwarding planes
would IMHO make a lot of sense for next-gen industrial.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 13 Mar 2022 16:43:08 +0100

On Sun, Mar 13, 2022 at 05:08:49AM -0700, Marie-Jose Montpetit wrote:
> And I would respectfully request a toning down of your snide comments.

I have absolutely no idea how you come to call my email "snide comments".
I do not appreciate such uncalled for accusations and would appreciate if you would only
make then by explicitly citing what you think is evidence thereof, because i certainly did not
intend any of my input to be anything else than productive, helpfull input to the RG.

> You may not think our work is to your liking and this is fine.

I think i was overall very positive in my remarks and my concerns where very specific,
and mostly about terminology/taxonomy. So i think it is a gross misrepresentation to
claim that COIN-RG work is not to my liking.

> You may think we need people like you to anchor of blue sky thoughts in
> reality and we thank you but a more positive approach would yield better results.

> Criticism is too easy..

Actually, it is not. At least not when one like me tries to formulate constructive
criticism intended to create positive discussion and help improve the work,
but then one gets a reply like yours.

> And if you think the RG is not doing quality work or the the
> chairs are incompetent or ineffectual

I have no idea what in my email makes you say that.

> raise it with Colin and even the the IAB. We are ready for any review.

I have lost faith in getting fair and equal treatment from relevant leadership
a good amount of time ago. I will try to stick to only technical discussions with
the community and do my best to professionally answer to attacks like the one you
just gave me.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "David R. Oran" <[email-masked]>
Date: Sun, 13 Mar 2022 12:06:33 -0400

I wade in here with more than a little trepidation hopefully 
contributing signal and not noise.

> (i am probably not correctly restating that old saying either ;-)
I believe the original is “The road to hell is paved with good 
intentions”. (it needn’t be the least cost or fewest hops path :-) )

> without even thinking of what it means for an application to be "in 
Well, as Marie Jose attributed to me, trying to think clearly about what 
it means to be “in” the network as opposed “on” the network can 
be either illuminating or a philosophical (reference intended) 
“semantic trap”.

In fact, by using the term “network services” in the above, 
there’s an implication that the existing architectural boundary that 
constitutes “network services” is the right abstraction in today’s 
world where distributed applications are multi-party, micro-service 
based, and exploiting resources that could be instantiated in lots of 
places including in devices that classically performed only 
“transparent” forwarding functions. There is likely a pretty high 
bar for justifying extra complexity in data forwarding functions or the 
way sources and sinks of data flows are identified by those functions 
when it may be just as easy to interpose application entities and their 
necessary state in the places where previously you just forwarded 
packets.

> ICN/CCN as a new network layer. Arguably a form of semantic routing 
> (to me).

I beg to differ. The key architectural change introduced by ICN was not 
some new routing semantic (or as you say semantic routing), but actually 
a fundamentally different service model and layering structure from the 
one in TPC/IP (e.g. NDN and CCNx even lack a separate transport layer). 
The substantially different forwarding design flows directly from that 
change in service model, which would make little or no sense if your 
application did not adopt an ICN design. I’m not going to pollute this 
thread with a long treatise on ICN, however I am at pains to assert that 
to the extent I understand the evolution of ICN, there was a strong 
principle to **avoid** introducing any semantics into the forwarding 
model itself, but only to do semantic-blind LNPM (longest name prefix 
match) as the basic next-hop determination machinery. Anything beyond 
that was abstracted into things called “forwarding strategies” which 
supposedly were there to provide some degree of flexibility under 
control of applications. Ironically, this is one part of the NDN and 
CCNx designs that has turned out to be problematic and not terrible 
useful in practice. So, I think we are accumulating some evidence in the 
ICN world that “semantic routing” is not necessary and may in fact 
not be desirable. (two examples: 
https://dl.acm.org/doi/10.1145/3267955.3267963, 
https://ieeexplore.ieee.org/document/8905382). That lesson may or may 
not apply in the IP world however.

> Is that not
No, I don’t think so. Actually I see it as the reverse - the most 
stable proven characteristic has been keeping the network service model 
dead simple and consequently limiting the complexity of the elements 
tasked to provide the transitive connectivity among all the endpoints. 
The upper layers have therefore had to jump through significant 
complexity hoops to be able to get the performance, robustness, and 
flexibility we see today. Historically that has been a winning tradeoff, 
and in a very big way. If we’re to revisit this, whether via something 
like ICN or something else, it seems that placing these application 
functions in networking devices has a better chance of succeeding than 
trying to enhance the existing forwarding paradigm on the justification 
(to be proven) that applications will actually benefit.

> entities to forward/route beyond datagrams.
They exist, but as I tried to point out above, they exist at higher 
layers. The point of view I think you are taking is that pushing these 
down into the network layer forwarding model is an attractive way 
forward. I don’t share that optimism, but perhaps this will succeed. 
It’s a stretch for me to see how this will help move the mission of 
COIN forward though.

> We already see this in ICN, where i think
> we would call the entities transations?
Huh? They are called “producers” and “consumers”. Is introducing 
new terminology helpful here to promote understanding?

> And of course, whereever we have flows, our
> entities are connections.
Well, ICNRG doesn’t have “flows” in the classic sense, and it 
certainly doesn’t have “connections” In fact, as I mentioned 
above, it doesn’t even have a transport layer.

> Not sure what a "computational object" is though. What is a
While I share a certain degree of you’re uncertainty what this refers 
to, I believe the distinction is intended to distinguish the retrieval 
of static data from the request for the results of a dynamic 
computation. In ICN these two are not any different in the service model 
and definitively no different in the forwarding machinery. However, they 
can be different in how applications use the service model (e.g. RICE, 
CFN).

> in forwarding,
Perhaps we’re making progress in communicating, because for the 
record, I am not a fan of this direction.

> because moving something like MQTT/XMPP style application 
> orchestration
Or, perhaps instead distribute the computations themselves, especially 
for things like data fusion and coordinated control of actuators, rather 
than try to build things like that into forwarding.

I don’t mean for this to start another long and divisive thread, so 
please either absorb before replying or delete as unhelpful.

Thanks,
DaveO.

>>>>> anybody who might feel addressed by your "vitriol" would not be 
>>>>> happy
>>>>> about that
>>>>> I am also not sure where there would be divisiveness in the 
>>>>> community
>>>>> wrt. COIN work.
>>>>> work items in or out of scope, and the chairs did attempt to 
>>>>> define a
>>> line
>>>>> that was intended to describe the intricate dependencies between 
>>>>> what
>>> was
>>>>> the use-case draft has), but with use-case examples focussed on 
>>>>> what i
>>>>> think
>>>>> In any case, it would be nice to understand if/when you would make 
>>>>> a
>>>>> decision
>>>>> (trying to formulate and categorize the pertinent research 
>>>>> questions
>>> in a
>>>>> 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.
>>>>>>
>>>>> invited researchers and papers we cannot put a good agenda 
>>>>> together
>>> for
>>>>>> The co-chairs are in full agreement that this is the right 
>>>>>> decision
>>> at
DaveO

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sun, 13 Mar 2022 11:07:56 -0700

Thanks for your wisdom and I subscribe to the “trepidation”. It reminds me
of the IETF of old before we became inclusive :)

I will do a lot of “snip snip” but one think you just said chimed with the
work I currently do.

snip/snip

Or, perhaps instead distribute the computations themselves, especially for
things like data fusion and coordinated control of actuators, rather than
try to build things like that into forwarding.

That’s exactly what we do in the networked IoT applications I am working
on. Distribute the computation in the edge/fog and in the network elements
there. And that forces to revisit some assumptions about what is in or out
of the network. And we (the IoT people) owe a lot to ICN as because we are
data driven we worry a lot about finding the right information - once we
find it getting it to where it needs to go is somewhat easier :)

I don’t mean for this to start another long and divisive thread, so please
either absorb before replying or delete as unhelpful.

Please don’t apologize. We need to continue the work of the RG.

mjm

---

From: Dirk Trossen <[email-masked]>
Date: Mon, 14 Mar 2022 08:12:53 +0000

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:[email-masked]] 
Sent: 13 March 2022 08:33
To: Sharon Barkai <[email-masked]>
Cc: Schooler, Eve M <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; coinrg-chairs <[email-masked]>; Dirk Trossen <[email-masked]>; coin <[email-masked]>
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

-- 
---
[email-masked]

---

From: Ike Kunze <[email-masked]>
Date: Tue, 15 Mar 2022 07:01:07 +0000

Dirk, Toerless, all,

@Toerless: Thanks for your comments. I appreciate the input! It’s always good to get some more “outside” perspective so as to not get too focused on the (sometimes echoing) opinion of the author group + COINRG!
Let me add my two cents to some of your and Dirk’s comments inline. 

Best,
Ike

> On 14. Mar 2022, at 09:12, Dirk Trossen <dirk.trossen=[email-masked]> wrote:
> 

[IKE] I would like to emphasize that adding the “COIN” prefixes is really only intended to make it absolutely clear that we focus on COIN-specific challenges, questions, etc.
As Dirk says, there are also “larger-than-COIN” aspects, but we have tried to gradually turn their volume within the document down.
See also Dirk’s last comment regarding “calling it anything…”.

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

[IKE] Just to add on here: Our goal is to find common research questions, challenges and requirements for COIN and we chose to do this in a use-case-driven way so that we do not end up with some set of artificial RQs, etc. that no one cares about.
As a consequence, our current findings are, of course, tied to the underlying use cases and, thus, also somewhat influenced by them, e.g., in the form of how we align the use cases.
However, all of this additional ordering, be it in Sections 3-6 or in our analysis in Section 7, is only intended to help us make sense of commonalities between the use cases.
In short: we are aware that this is possibly not the best way to do things, but the one that we felt most comfortable with and the one we chose to get started with this.
Based on our findings, we might later choose a different way.

> 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 distribute…

[IKE] Yep, we do not aim to answer any of those questions, but actually want to raise questions :)

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

[IKE] I fully agree. Our goal is to raise questions that help in finding out the scope/extent of COIN. Our goal is not to propose new terms. In fact, we have only introduced them to better align the different use cases so that we can analyze them easier. Thus, for me, renaming them in our document is on the table and I actually advocate for having one central place where we define general “COIN”-related terms.

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

[IKE] See Dirk’s and my comments above.

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

[IKE] This is the interesting point of this RG. Your view of “using" the network vs “in” the network is different from mine which is different from Dirk’s which is different from …
I think that one of the main goals of this RG is to make sense of all these views and discuss which of them might make the most sense.
For this, the use cases present different scenarios that some of us believe to be “in” the network and now it is up to the RG to discuss about this.
In this context, our draft is intended to support this discussion by bringing out similarities, differences, nuances, etc.

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

[IKE] I don’t believe that there is an RG majority on all the different things that might be in/out. If that would be the case we would not be needing the discussions.
Regarding the “longer list of examples”: We had several calls for use cases and those that we have at the moment are those that we got. At the moment, we analyze this (incomplete) list of examples as detailed by Dirk and myself above.
In this context, we will also consider whether some of the use cases might actually be out-of-scope, but we have not gotten that far, yet.
Thus, for the moment, our list of use cases is fixed so that we can make progress with the analysis, but at later stages we would be happy to include additional examples to enrich the discussion and/or see whether they bring new RQs, challenges, etc. to the table.

> Distributed applications and their needs for better network services do not become less important by NOT giving them a new name COIN.

[IKE] If you still have this opinion following Dirk’s and my comments, I would be happy to hear what kind of “more differentiated set of classifications” you have in mind.