Re: [Coin] Minutes of the interim meeting and some words from thecochairs

[Toerless Eckert <[e-mail]>]

Sharon:

Given Colins ask to the folks like Adrian focussing on semantic addressing to
first go to coin, i think any such problems should maybe start using COIN at
least as a dispatch, and either the discussion about a specific topic

a) fits coin and might result in adopted work
b) does not fit coin but subsides
c) does not fit coin, does not subside and should then be moved
   to another forum in IETF/IRTF or at least be given a mailing list.

That is at least what i have seen as logical processes in the past.

But logistics aside (boooring ;-)

The generic problem you describe has been around forever but indeed will need
different optimizations based on its specific parameters. When subscription patterns
do for example map well with the network topology (vehicles subscribe to interest
channels specific to their vicinity and network topology is vicinity based), then
a lot of optimizations can be done.

I observed similar application requirements from the 90th on, first with
hundreds of thousands of financial instrument event channels (stock tickers),
and brokers as subscribers. That problem had much lower subscriber counts,
but no locality matching. First solutions did use multicast, but then when
software compute/networking (DC servers) became cheap enough vs. the required
bandwidth it was moved up the stack because it allowed the application developers
to not depend on "network operators" to ask "vendors" about forwarding plane
functions that their applications required, because that multi-party development
loop made the agility of solution development compete with continental drift.

This is why why i think programmable slices (where the actual
forwarding is programmable by the application owner) are a mandatory requirement
to make progress in leveraging high-speed programmable forwarding planes in
shared networks: The wide-area network operators will not be able to drive
requirements on behalf of such specialized application owners. Those application
owners have to be able to program what they want themselves.

ICN btw. did and does promise to solve these type of content stream distribution
model fairly well. In fact i would claim it did develop out of use cases like
the one i described because multicast itself didn't get to the point of
standardizing the required reliability, mostly because of IETF's bureaucracy
around the RMT WG, which is a whole other annoying IETF story...

Cheers
    Toerless

On Wed, Mar 09, 2022 at 03:38:13PM +0200, Sharon Barkai wrote:
> Here is an example of a big cloud computation problem,
> turned into a simple application routing problem:
> 
> - A very big table of Vehicle.Location (Ms) 
> - Needs to be joined with Event.Location (100Ks)
> - In order to generate vehicle push notifications
> - Both tables keep changing by the second
> - Join compute time is much longer than that
> 
> The programmable routing solution:
> 
> - The join column e.g. “location" is an IP multicast channel for notifications
> - Both events and subscriptions are designated to addressable “locations"
> - The logical meaning of the channel is a shared system convention
> - It leverages standard routing to designate events to addresses 
> - It leverages MLD and signal-free multicast RFCs to subscribe
> 
> The question is - does COIN facilitate such research use-cases,
> based on what terminology and open contribution framework?
> 
> This a simple example with multiple possible solutions.
> There are many more like that with increased complexity.
> So COIN may or may not be the right place for these.
> 
> 
> 
> 
> > On Mar 9, 2022, at 11:29, Schooler, Eve M <[e-mail]> wrote:
> > 
> > I include my comments below. Having not discussed my remarks with my co-chairs, please consider this note as being from me (vs from J/E/M).
> > Best regards,
> > Eve
> >  
> > From: Coin <[e-mail] <mailto:[e-mail]>> On Behalf Of JEF
> > Sent: Friday, March 4, 2022 5:03 PM
> > To: Adrian Farrel <[e-mail] <mailto:[e-mail]>>
> > Cc: iMac <[e-mail] <mailto:[e-mail]>>; coin <[e-mail] <mailto:[e-mail]>>
> > Subject: [Coin] Re：Re: Minutes of the interim meeting and some words from thecochairs
> >  
> > Hi Adrian,
> > 
> > Please see in lines. COIN chairs will meet next week to discuss this. Below are my personal comments and suggestions.
> > 
> >  
> > 
> > Original
> > 
> > From:"Adrian Farrel"< [e-mail] <mailto:[e-mail]> >;
> > 
> > Date:2022/3/4 0:43
> > 
> > To:"jefhe"< <<[e-mail] <mailto:[e-mail]>>> >;
> > 
> > CC:"coin"< [e-mail] <mailto:[e-mail]> >;
> > 
> > Subject:Re: [Coin] Minutes of the interim meeting and some words from thecochairs
> > 
> >  
> > 
> > Thanks, Jef, for sharing this, and to you and your co-chairs for putting it together.
> > This is the guidance we’ve been asking for. So it is most welcome.
> > First and foremost, the focus in the IRTF is on research, not standardization. As such, it is appropriate to propose a vision for a COIN-based future network infrastructure. However it is equally important to ground the vision in an architecture and in concrete problem formulations. Some of the agreed upon core COIN RG goals are to examine the architectural implications of programmable routing and in-network compute, thus mechanisms to develop more programmable and more flexible packet forwarding could be in scope for COINRG – but only if new routing mechanisms leverage the programmable data plane or routing algorithms are supposed to be run on an in-network computing platform.
> > 
> > I may be wrong, but I think that, with the exception of some very old technologies, all routing algorithms are run on in-network computing platforms. There is no reason to assume that this would change with any approach to Semantic Routing, so that puts all of the routing side of Semantic Routing firmly in scope. Agreed?
> > 
> > [Jeffrey HE] In the context of data plane programmability, such in-network platform here is different from the CPUs in traditional network devices which are used mainly for the control plane. A simple difference is certainly the processing speed. Could we break current routing algorithms into different functions and allocate some of them into a programmable data plane? I have no answer, but this is potential. Is a function of routing algorithm allocated in the data plane still qualified to be called part of the routing? Let’s leave the discussion of naming till we see it.
> > 
> > Simply put, routing is not the sole focus of COIN.
> > 
> > Well, I would hope not!
> > 
> > [Eve] The focus is meant to be on computation.
> > 
> > I look forward to reading a lot of material that is not related to routing as it is brought to the RG.
> > 
> > In fact, the group has a strong interest in and believes its mission is to go well beyond traditional packet interception -  to support computations that go beyond packet header processing, whether to go deeper into packets for contextual info to be included in that computation, or that are part of distributed or federated apps that marshal the inclusion of network-based entities (physical or virtualized) that one wouldn’t normally consider as traditional “routers” (e.g., elements focused on compute, storage).
> > 
> > It is good to know that computations that stop at packet header (for some definition thereof) are not out of scope.
> > 
> > [Eve] The intended meaning of the paragraph above was the opposite of your reading.
> > 
> > I look forward to reading about mechanisms that go deeper into packets and how they work in the presence of privacy/security-protecting end-to-end encryption.
> > 
> > I think a “router” is defined by the processing components that build routing tables and forward packets. Of course, it is very interesting to compose paths through the network that include nodes that perform routing as well as additional functions whether that be functions that provide services and are composed into chains, or other functions that the payload requires.
> > 
> > One epiphany gleaned from the meeting's discussion was that there is an ongoing tussle between compute in the service of routing and routing in the service of compute; both offer interesting research challenges. 
> > 
> > No reason why this has to be a tussle. But it is good to recognise that the two things exist and both need work, and they need to co-exist.
> > 
> > However, the strong desire in COIN RG is to make a dramatic departure from focusing on classical layer 3 IP address spaces, labelling, and identifiers.
> > 
> > ** This is the statement I most need help with. Is the extent of that strong desire for a dramatic departure such that any work on layer 3 routing and forwarding is not of interest? Maybe this depends on what “classical” means.
> > 
> > [Jeffrey HE] I don’t think that statement excludes Layer 3 as a whole. One example in my mind is the notion of coflow[1], which is a group of flows sharing a collective objective in distributed computing such as mapReduce. When the traffic pattern is multi-point2multi-point, compute-in-the-network has potentials to improve the routing and forwarding by taking the states of member flows at the running time into account. There is a line of research how to optimise a coflow and multi-point2multi-point communications. So I think it is more about if we leverage the data plane programmability in network devices. [1]https://www2.eec <https://www2.eec/>s.berkeley.edu/Pub <http://s.berkeley.edu/Pub>s/TechRpts/2012/EECS-2012-184.pdf
> > 
> > And an interesting question raised during the interim was if programmable routing (especially at the application layer) requires that we reconsider/redefine what routing convergence actually means in the presence of COIN-based infrastructure.
> > 
> > Well, of course, routing convergence at the application layer may have a very different meaning from the previous understanding derived from the packet/frame layers, but that is understandable as routing at the application layer also has a different meaning.
> > 
> > But I think you are referring to the question raised by Nik in the chat (there is nothing in the minutes about convergence). It’s good that you are opening that question up to include the concept of convergence in application layer routing, but (Nik can correct me) I didn’t read his question as having anything to do with application layer routing per se.
> > 
> > The three cochairs (J/E/M) thought the presentation “Flightplan” from Nik Sultana was a good example of an effective way to contribute to a research group like COIN; bring in concrete research results that offer a solution to a honed research problem. According to the feedback received from RG meetings and the mailing list, this kind of research topic formulation is most beneficial to the audience.
> > 
> > Given the fact that semantic routing has taken a major part of the discussion on the list lately, the chairs would like to request the following. The research on semantic routing that overlaps with COIN needs to be better articulated: (1) to focus the mailing list discussion on those topics that genuinely relate to data plane programmability and in-network compute, (2) to define which (or any) of the current drafts apply to the RG, (3) and to concentrate on the research that advances networking, now that programmability and in-network compute exists at every level in the core-edge continuum.
> > 
> > Given that we have been reliably and repeatedly told that a good proportion of semantic routing fits within the scope of COIN,
> > 
> > [Eve] I beg to differ. The feedback has been that only some of it may fit.
> > 
> > and absent anywhere else in the IRTF to have these discussions, I think I will continue to discuss the issues and concepts related to semantic routing on the COIN list.
> > 
> > [Eve] Because there is nowhere else to have these discussions does not make it appropriate to post everything semantic routing related here. Please re-read the 3 recommendations in the paragraph above.
> > 
> > The chairs are welcome to tell me on a thread-by-thread basis which pieces are not in scope for COIN, and I will stop talking about those topics.
> > 
> > [Eve] And I will respectfully request that you make an equal effort before posting to ask yourself if the subject is on topic.
> > 
> > My aim in my emails is to solicit opinions and contributions to the discussion – the IRTF is not just about presenting research papers that have already been published/presented in other venues (although that can be a useful thing, too).
> > 
> > [Jeffrey HE] You’re right, it doesn’t make sense that only published papers are allowed to be presented in COIN. That didn’t happen to COIN either. But as a research group, discussions are expected to be about related research activities. I think you have had described and summarized semantic routing in this list. Among 250+ members in this list, if some of them are interested, these people should have approached to you or joined your mailing list whatever the answer to the scope question is. I would suggest we start from the part that we have already agreed in the scope of COIN, aiming at interesting techinical discussions to the group, that is how the idea of semantic routing may leverage or benefit from the network programmability. If you agree, I would say this is similar to one of your questions in your last slide in the interim: "What programmability (in the network) does Semantic Routing require? What would it drive?” For your other technical questions, the answsers depand on whether the programmabilty in the data plane and future in-network computing platform are included in your research alternatives or not. It would be out of scope of COIN if your research is aiming to extend the current understanding of the routing mechanism/theory in a general way, say without an assumption for a programmable data plane or in-network computing.
> > 
> > [Eve] I agree with Jeffrey’s comments: asking how does semantic routing research overlap with/drive/influence/advance programmability in the data plane and in-network computing. And that general routing is out of scope.
> > 
> > Anyway, I feel the discussions at the concept levels are usually useful at the beginning, but at this stage I am afraid we need to see more concrete research contents if this group expect to benefit from the discussion. We will understand the concept better if we “see” it. 
> > 
> > [Eve] Agreed. 
> > 
> > Best,
> > 
> > Adrian
> > 
> > -- 
> > Coin mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.irtf.org/mailman/listinfo/coin <https://www.irtf.org/mailman/listinfo/coin>

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


-- 
---
[e-mail]