Re: [Coin] Cancelling the COINRG meeting at IETF113

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

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

On 13 Mar 2022, at 11:03, Toerless Eckert wrote:

> On Sun, Mar 13, 2022 at 09:51:05AM +0000, Jon Crowcroft wrote:
>> 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.
>
> 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 ;-)
>
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 :-) )

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

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

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

>> 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...
>
> We surely will find more interesting semantics as soon as we expand 
> the scope of
> 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
> non-computational object ?.
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).

>
>> 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!
>
> 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,
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
> via appropriate application address semantics down to Gigbps 
> programmable forwarding planes
> would IMHO make a lot of sense for next-gen industrial.
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.

>
> Cheers
>     Toerless
>
>>>>> On Fri, Mar 11, 2022 at 08:35:16AM +0000, Schooler, Eve M wrote:
>>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>>> 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]<mailto:[e-mail]>>
>>>>>> Cc: coinrg-chairs
>>>>> <[e-mail]<mailto:[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
>>>>>>
>>>
>>> --
>>> 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
DaveO