Subject: [Coin] Starting point for Semantic Routing discussions

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 2 Feb 2022 16:23:51 -0000

Hi all,

Sorry for the lang email, but Marie-Jose suggested that the best approach to
the interim meeting slot on Semantic Routing would be to start some
discussions on the list. That way, when we get to the meeting we may have
some ideas in play and be better able to get on with the discussions.

This thread is intended as a foundation for Semantic Routing. Those who have
read
http://datatracker.ietf.org/doc/draft-farrel-irtf-introduction-to-semantic-r
outing can probably skip this, and those who haven't read the draft yet
might prefer the more detailed introduction in the draft to this email. Even
if I-Ds are out of fashion, they provide a better place to document ideas
and explanations than emails.

Semantic routing is about packet-level (i.e., layer 3) routing and
forwarding. It is not about choosing intermediate processing nodes (for NFV,
SFC, application layer compute, transport layer proxying, or application
layer relay), but it is about how packets navigate the packet-layer network
to get to the interface to which they are addressed. Furthermore, it is not
about building layer 3 (or 3.5) overlays since that approach is, again,
about choosing intermediate nodes and not about hop-by-hop forwarding.

Historically, packets have been forwarded according to network-wide
algorithms using information gathered and distributed by routing protocols.
Thus, for example, the shortest-path first algorithm used to determine how
to forward packets in networks gathering network state and per-hop metrics
using OSPF or IS-IS. One strong reason for using a network-wide algorithm is
the stability and predictability it affords especially in the face of change
within the network.

Over time, more sophistication has been required. Different classes of
service have demanded that packets receive prioritised queueing/forwarding;
different service classes or protection mechanisms have required separation
of traffic flows; and traffic has been steered to resource-rich links and
away from points of congestion. Some approaches to this have been DiffServ,
multi-topology routing, and traffic engineering. All such approaches
utilised "markers" in the packets so that they could receive the right
forwarding treatment, but the algorithms in the network remained
network-wide to maintain the necessary stability.

Semantic Routing is the generic name given to forwarding packets based on
information beyond the regular destination IP address carried in the
packets. That information might be:
- normally present in packet fields
- additionally present in existing packet fields through "overloading" or
other techniques
- carried in additional (new) fields added to packet headers.

The forwarding tables might be fed by established network wide algorithms,
as today, taking state information from routing protocols. Or they might be
programmed by a central controller that is running an algorithm and learning
network state. Or they could be constructed in the network nodes using state
information learned from within the network and applying algorithms that
have been installed (programmed) onto the nodes. The algorithms could even
be dynamic, performing computations (not just simple lookups) on each
packet.

In our work on Semantic Routing we are not looking to establish any specific
solutions, although it may well be that we arrive at some conclusions that
will then feed into the IETF for protocol design work. What we do want to do
is examine several aspects:
- The impact and risk of applying new Semantic Routing schemes to complex
   packet routing systems
- The overlap between Semantic Routing and established practices like SDN
   that have a more centralised (i.e., less distributed) algorithms with
various
   benefits and drawbacks
- The risks and benefits of having different network nodes apply different
   routing/forwarding algorithms drawing, in particular, on lessons learned
   from policy-based routing (in the network, not at ASBRs) and static
routes.
- The benefits of a single Semantic Routing information-carrying scheme
   compared to a mix of multiple concurrent schemes.

Obviously, this topic has seen some light in a number of conference
workshops and papers (as well as seeing very many specific solutions
described in papers over the years). What we are trying to do is bring this
all together by:
- Providing a framework for the discussions
- Outlining the challenges for routing systems that need to be considered
   in research into packet routing/forwarding, but especially for Semantic
   Routing
- Pulling out specific threads for discussion (such as the relationship to
   SDN, and the applicability of in-forwarder compute)

A couple of additional threads will follow to start to scratch at how and
where Semantic Routing might be applicable within COIN. I hope that RG
participants will follow up with their opinions of how we fit in, what work
they have already done in this area, and what additional work would be
appropriate.

Best,
Adrian

---

From: Haoyu Song <[email-masked]>
Date: Wed, 2 Feb 2022 18:43:30 +0000

Hi Adrian,

I enjoyed reading the draft and I think you have provided an excellent summary of the concept and survey of the state-of-art. Also the issues of all aspects we should be concerned are also clearly stated. The conventional policy-based routing as I understood belongs to the broader semantic routing. Given such a wide spectrum of techniques covered by the concept, maybe we should also discuss what's the requirements for routers case by case. If some do need "compute in network" then they are clearly in the scope of  COIN. Of course, what's considered "compute" in the context of "in network" should also be clarified. I'd like to see more discussions on this topic.

Best,
Haoyu

-----Original Message-----
From: Coin <[email-masked]> On Behalf Of Adrian Farrel
Sent: Wednesday, February 2, 2022 8:24 AM
To: [email-masked]
Cc: 'King, Daniel' <[email-masked]>; [email-masked]
Subject: [Coin] Starting point for Semantic Routing discussions

Hi all,

Sorry for the lang email, but Marie-Jose suggested that the best approach to the interim meeting slot on Semantic Routing would be to start some discussions on the list. That way, when we get to the meeting we may have some ideas in play and be better able to get on with the discussions.

This thread is intended as a foundation for Semantic Routing. Those who have read
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-farrel-irtf-introduction-to-semantic-r&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C74ccbb8cc96b419896cc08d9e6687137%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637794158530017204%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=YnA%2B4kZbnuk4XM6AlZ%2BwdcuO1TVet%2Bj5StSPVIJtj%2Bs%3D&amp;reserved=0
outing can probably skip this, and those who haven't read the draft yet might prefer the more detailed introduction in the draft to this email. Even if I-Ds are out of fashion, they provide a better place to document ideas and explanations than emails.

Semantic routing is about packet-level (i.e., layer 3) routing and forwarding. It is not about choosing intermediate processing nodes (for NFV, SFC, application layer compute, transport layer proxying, or application layer relay), but it is about how packets navigate the packet-layer network to get to the interface to which they are addressed. Furthermore, it is not about building layer 3 (or 3.5) overlays since that approach is, again, about choosing intermediate nodes and not about hop-by-hop forwarding.

Historically, packets have been forwarded according to network-wide algorithms using information gathered and distributed by routing protocols.
Thus, for example, the shortest-path first algorithm used to determine how to forward packets in networks gathering network state and per-hop metrics using OSPF or IS-IS. One strong reason for using a network-wide algorithm is the stability and predictability it affords especially in the face of change within the network.

Over time, more sophistication has been required. Different classes of service have demanded that packets receive prioritised queueing/forwarding; different service classes or protection mechanisms have required separation of traffic flows; and traffic has been steered to resource-rich links and away from points of congestion. Some approaches to this have been DiffServ, multi-topology routing, and traffic engineering. All such approaches utilised "markers" in the packets so that they could receive the right forwarding treatment, but the algorithms in the network remained network-wide to maintain the necessary stability.

Semantic Routing is the generic name given to forwarding packets based on information beyond the regular destination IP address carried in the packets. That information might be:
- normally present in packet fields
- additionally present in existing packet fields through "overloading" or other techniques
- carried in additional (new) fields added to packet headers.

The forwarding tables might be fed by established network wide algorithms, as today, taking state information from routing protocols. Or they might be programmed by a central controller that is running an algorithm and learning network state. Or they could be constructed in the network nodes using state information learned from within the network and applying algorithms that have been installed (programmed) onto the nodes. The algorithms could even be dynamic, performing computations (not just simple lookups) on each packet.

In our work on Semantic Routing we are not looking to establish any specific solutions, although it may well be that we arrive at some conclusions that will then feed into the IETF for protocol design work. What we do want to do is examine several aspects:
- The impact and risk of applying new Semantic Routing schemes to complex
   packet routing systems
- The overlap between Semantic Routing and established practices like SDN
   that have a more centralised (i.e., less distributed) algorithms with various
   benefits and drawbacks
- The risks and benefits of having different network nodes apply different
   routing/forwarding algorithms drawing, in particular, on lessons learned
   from policy-based routing (in the network, not at ASBRs) and static routes.
- The benefits of a single Semantic Routing information-carrying scheme
   compared to a mix of multiple concurrent schemes.

Obviously, this topic has seen some light in a number of conference workshops and papers (as well as seeing very many specific solutions described in papers over the years). What we are trying to do is bring this all together by:

A couple of additional threads will follow to start to scratch at how and where Semantic Routing might be applicable within COIN. I hope that RG participants will follow up with their opinions of how we fit in, what work they have already done in this area, and what additional work would be appropriate.

Best,
Adrian

--
Coin mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcoin&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C74ccbb8cc96b419896cc08d9e6687137%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637794158530017204%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HMfqE2blEZPQJVy8pkZrDWet060HjoigZkSzN2fcJFA%3D&amp;reserved=0

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 2 Feb 2022 19:25:56 -0000

Thanks for this Haoyu,

Indeed, the next mail in this little collection of threads will be about
challenges to the routing system. I think that will seed the "requirements"
discussion that you are looking for.

It is notable that some previous discussions of solutions within the space
that we may call "semantic routing" have given inadequate consideration to a
number of aspects of how the routing system works. In particular a
much-overlooked aspect has been "privacy" with a few poorly-expressed
solutions threatening to severely violate users' privacy and with their
proponents failing to recognise that privacy was a fundamental requirement.

That is why we want to step back from individual use cases or solutions and
consider the more general situation and the needs of the routing/forwarding
system itself. Only by doing this will we avoid being dragged into the
specifics of certain scenarios that tempt researchers to become engineers
solving a problem in a particular space without proper consideration of its
impacts and wider utility.

Cheers,
Adrian

-----Original Message-----
From: Coin <[email-masked]> On Behalf Of Haoyu Song
Sent: 02 February 2022 18:44
To: [email-masked]; [email-masked]
Cc: 'King, Daniel' <[email-masked]>; [email-masked]
Subject: Re: [Coin] Starting point for Semantic Routing discussions

Hi Adrian,

I enjoyed reading the draft and I think you have provided an excellent
summary of the concept and survey of the state-of-art. Also the issues of
all aspects we should be concerned are also clearly stated. The conventional
policy-based routing as I understood belongs to the broader semantic
routing. Given such a wide spectrum of techniques covered by the concept,
maybe we should also discuss what's the requirements for routers case by
case. If some do need "compute in network" then they are clearly in the
scope of  COIN. Of course, what's considered "compute" in the context of "in
network" should also be clarified. I'd like to see more discussions on this
topic.

Best,
Haoyu

-----Original Message-----
From: Coin <[email-masked]> On Behalf Of Adrian Farrel
Sent: Wednesday, February 2, 2022 8:24 AM
To: [email-masked]
Cc: 'King, Daniel' <[email-masked]>; [email-masked]
Subject: [Coin] Starting point for Semantic Routing discussions

Hi all,

This thread is intended as a foundation for Semantic Routing. Those who have
read
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdatatracker
.ietf.org%2Fdoc%2Fdraft-farrel-irtf-introduction-to-semantic-r&amp;data=04%7
C01%7Chaoyu.song%40futurewei.com%7C74ccbb8cc96b419896cc08d9e6687137%7C0fee8f
f2a3b240189c753a1d5591fedc%7C1%7C0%7C637794158530017204%7CUnknown%7CTWFpbGZs
b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
0&amp;sdata=YnA%2B4kZbnuk4XM6AlZ%2BwdcuO1TVet%2Bj5StSPVIJtj%2Bs%3D&amp;reser
ved=0
outing can probably skip this, and those who haven't read the draft yet
might prefer the more detailed introduction in the draft to this email. Even
if I-Ds are out of fashion, they provide a better place to document ideas
and explanations than emails.

Best,
Adrian

--
Coin mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.o
rg%2Fmailman%2Flistinfo%2Fcoin&amp;data=04%7C01%7Chaoyu.song%40futurewei.com
%7C74ccbb8cc96b419896cc08d9e6687137%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7
C0%7C637794158530017204%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HMfqE2blEZPQJVy8pkZr
DWet060HjoigZkSzN2fcJFA%3D&amp;reserved=0

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

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 02 Feb 2022 21:45:11 +0000

i'm still lost as to what new knowledge that research will generate - as opposed to
the shopping list of problems that need fixes.

and requirements are part of engineering. research isn't a requirement, it is curiosity led.

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 3 Feb 2022 07:51:17 +0000

Jon,

If there's a shopping list of problems that need fixes, it may also warrant research to do so, not just engineering. 

Let me take COIN as an example. 'Computing in the networking' is not really new, is it? We've done that before. AN is a (bad) example with many problems outlined, e.g., how to program those distributed nodes, how to deploy them, how to secure them (and the execution). We've had SDN for some time, P4 emerged around the time of COIN (not sure of the exact timing here), and hey, we can just stick a server next to a network node as a crude approach. So in manner, compute in the network is something we know (quite well, in fact) but may not be happy with how it's solved so far. But the questions asked in those efforts are similar to those we ask in COIN.

In another conversation, you pointed me to the COIN charter text that is capturing the broad essence of what COIN is about, namely "Research on novel architectures, data-plane abstractions and new network protocol designs to efficiently federate decentralized  computing resources, across the infrastructure regardless of where in the network the compute is placed (the DC, the core, the edge, and even in the end-user devices).". It is this that binds the questions above (which could easily be diced and sliced for being addressed in other places of the IRTF or IETF) into an architectural context, asking for new abstractions and architectures that may be doing a better job than what we have done so far. 

But aren't there parallels to the discussion on semantic routing? The survey draft outlines the many ways in which it's been done so far with many (sliced and diced) solutions having emerged. What may be missing are the issues stemming from that point-wise approach to it, granted. But it's not difficult to see for me how a similar "research on novel..." can be formulated for semantic routing, progressing from the way it's been done until today. Questions may be similar to those above (on securing, deploying, programming) but they may also be different, something to figure out properly. 

My main point is that COIN can be seen as purely addressing a shopping list of problems that need fixes or taking an architectural view in addressing them (possibly different to when addressing the shopping list one by one in a 'fixing' approach). Semantic routing is no different to me on that; it's positioning the advancement of the area against the possible progress at architectural level (for which we need research) rather than at the engineering level (which is what we've been doing so far with all the issues that come with it). 

As for COIN and semantic routing together, determining the common threads (vs those that may be distinctly different) is key to the activities here, which why I had seen semantic routing as an 'applicability area', using the term introduced in the email to the list that stirred much of the recent discussion.

Best,

Dirk

-----Original Message-----
From: Coin [mailto:[email-masked]] On Behalf Of Jon Crowcroft
Sent: 02 February 2022 22:45
To: [email-masked]
Cc: 'Haoyu Song' <[email-masked]>; 'King, Daniel' <[email-masked]>; Jon Crowcroft <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Coin] Starting point for Semantic Routing discussions

i'm still lost as to what new knowledge that research will generate - as opposed to the shopping list of problems that need fixes.

> Thanks for this Haoyu,
> 
> Indeed, the next mail in this little collection of threads will be 
> about challenges to the routing system. I think that will seed the 
> "requirements"
> It is notable that some previous discussions of solutions within the 
> space that we may call "semantic routing" have given inadequate 
> consideration to a number of aspects of how the routing system works. 
> In particular a much-overlooked aspect has been "privacy" with a few 
> poorly-expressed solutions threatening to severely violate users' 
> privacy and with their proponents failing to recognise that privacy 
> was a fundamental requirement.
> 
> That is why we want to step back from individual use cases or 
> solutions and consider the more general situation and the needs of the 
> routing/forwarding system itself. Only by doing this will we avoid 
> being dragged into the specifics of certain scenarios that tempt 
> researchers to become engineers solving a problem in a particular 
> space without proper consideration of its impacts and wider utility.
> 
> Cheers,
> Adrian
> 
> summary of the concept and survey of the state-of-art. Also the issues 
> of all aspects we should be concerned are also clearly stated. The 
> conventional policy-based routing as I understood belongs to the 
> broader semantic routing. Given such a wide spectrum of techniques 
> covered by the concept, maybe we should also discuss what's the 
> requirements for routers case by case. If some do need "compute in 
> network" then they are clearly in the scope of  COIN. Of course, 
> what's considered "compute" in the context of "in network" should also 
> be clarified. I'd like to see more discussions on this topic.
> 
> Best,
> Haoyu
> 
> Sorry for the lang email, but Marie-Jose suggested that the best 
> approach to the interim meeting slot on Semantic Routing would be to 
> start some discussions on the list. That way, when we get to the 
> meeting we may have some ideas in play and be better able to get on 
> with the discussions.
> 
> outing can probably skip this, and those who haven't read the draft 
> yet might prefer the more detailed introduction in the draft to this email.
> Even
> if I-Ds are out of fashion, they provide a better place to document 
> ideas and explanations than emails.
> 
> forwarding. It is not about choosing intermediate processing nodes 
> (for NFV, SFC, application layer compute, transport layer proxying, or 
> application layer relay), but it is about how packets navigate the 
> packet-layer network to get to the interface to which they are 
> addressed. Furthermore, it is not about building layer 3 (or 3.5) 
> overlays since that approach is, again, about choosing intermediate 
> nodes and not about hop-by-hop forwarding.
> 
> Thus, for example, the shortest-path first algorithm used to determine 
> how to forward packets in networks gathering network state and per-hop 
> metrics using OSPF or IS-IS. One strong reason for using a 
> network-wide algorithm is the stability and predictability it affords 
> especially in the face of change within the network.
> 
> service have demanded that packets receive prioritised 
> queueing/forwarding; different service classes or protection 
> mechanisms have required separation of traffic flows; and traffic has 
> been steered to resource-rich links and away from points of 
> congestion. Some approaches to this have been DiffServ, multi-topology 
> routing, and traffic engineering. All such approaches utilised 
> "markers" in the packets so that they could receive the right 
> Semantic Routing is the generic name given to forwarding packets based 
> on information beyond the regular destination IP address carried in 
> the packets. That information might be:
> The forwarding tables might be fed by established network wide 
> algorithms, as today, taking state information from routing protocols. 
> Or they might be programmed by a central controller that is running an 
> algorithm and learning network state. Or they could be constructed in 
> the network nodes using state information learned from within the 
> network and applying algorithms that have been installed (programmed) 
> onto the nodes. The algorithms could even be dynamic, performing 
> computations (not just simple lookups) on each packet.
> 
> In our work on Semantic Routing we are not looking to establish any 
> specific solutions, although it may well be that we arrive at some 
> conclusions that will then feed into the IETF for protocol design 
> work. What we do want to do is examine several aspects:
> described in papers over the years). What we are trying to do is bring 
> this all together by:
> A couple of additional threads will follow to start to scratch at how 
> and where Semantic Routing might be applicable within COIN. I hope 
> that RG participants will follow up with their opinions of how we fit 
> in, what work they have already done in this area, and what additional 
> work would be appropriate.
> 
> Best,
> Adrian
> 
> --
> Coin mailing list
> [email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 03 Feb 2022 09:13:41 +0000

in network compute is not active networking.

the active network program was started by David Tennenhouse at DARPA with the bold idea that
packet headers could be programs. that was very clearly a moonshot, designed to make people
think.

some folks looked at how you might make small, complex programs in packet headers safe

but in the end, in practice, it led to SDN - see the very well researched paper here:
https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/sdnhistory.pdf

some of the cool work on SDN controllers inherited the computer science problem of making 
them safe through verification, thus fulfilling prt of scott shenker's vision on this area of
injecting some of the computer science advances of the past 20 years into the 50 year old
space of network engineering

at the same time, industry folks and others looked at another sequence of owrk from generalsed
switch management protocols, and what might be done in switches, and out came openflow and P4
(and ongoing work there too)...

the  in-network compute now continues in that vein..

so where does semantic routing fit?
firstly, all routing is semantic routing already. we have pretty clear definitions
from way back of how routes are computed and how forwarding is done. and the 
interaction between the two.

we also have a long list of perceived limitations of how that doesn't do (well, or at all)
some things some people think routing should do

we also have some limited domains where people already ignore that, and just get on with
solving those problems in a specialised context (e.g. data centers, edge iot nets, space
networks, etc etc)

but if you want a research program in semantic routing, i think you need a vision like
tennenhouse's original one  for active networks, that gets away from just federating a bunch
of specialised solutions, and brings some sort of unifying abstraction 

you actually need to define "semantics" - it isn't pixie dust - people have a bunch of tools
in computer science for doing that  - and there are also a few papers out there that have
tried to tackle this 
https://www.cl.cam.ac.uk/~tgg22/metarouting/
http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/06/abc.pdf
https://arxiv.org/abs/1606.07523
etc etc

what would this unifying abstraction for what's in packets, what's in router state and
how/when did it get there, and formally, how these relate (semantically)?
initially, perhaps, relatively unconstrained , but then a program of research
to figure out how practically to constrain those semantics so we don't have something where
all the tools of CS (implementation, performance, correctness) are insoluble?

right now, I am missing that unifying abstraction....

> 
> If there's a shopping list of problems that need fixes, it may also 
> warrant research to do so, not just engineering.
> 
> Let me take COIN as an example. 'Computing in the networking' is not 
> really new, is it? We've done that before. AN is a (bad) example with 
> many problems outlined, e.g., how to program those distributed nodes, how 
> to deploy them, how to secure them (and the execution). We've had SDN for 
> some time, P4 emerged around the time of COIN (not sure of the exact 
> timing here), and hey, we can just stick a server next to a network node 
> as a crude approach. So in manner, compute in the network is something we 
> know (quite well, in fact) but may not be happy with how it's solved so 
> far. But the questions asked in those efforts are similar to those we ask 
> in COIN.
> 
> In another conversation, you pointed me to the COIN charter text that is 
> capturing the broad essence of what COIN is about, namely "Research on 
> novel architectures, data-plane abstractions and new network protocol 
> designs to efficiently federate decentralized  computing resources, 
> across the infrastructure regardless of where in the network the compute 
> is placed (the DC, the core, the edge, and even in the end-user 
> devices).". It is this that binds the questions above (which could easily 
> be diced and sliced for being addressed in other places of the IRTF or 
> IETF) into an architectural context, asking for new abstractions and 
> architectures that may be doing a better job than what we have done so 
> far.
> 
> But aren't there parallels to the discussion on semantic routing? The 
> survey draft outlines the many ways in which it's been done so far with 
> many (sliced and diced) solutions having emerged. What may be missing are 
> the issues stemming from that point-wise approach to it, granted. But 
> it's not difficult to see for me how a similar "research on novel..." can 
> be formulated for semantic routing, progressing from the way it's been 
> done until today. Questions may be similar to those above (on securing, 
> deploying, programming) but they may also be different, something to 
> figure out properly.
> 
> My main point is that COIN can be seen as purely addressing a shopping 
> list of problems that need fixes or taking an architectural view in 
> addressing them (possibly different to when addressing the shopping list 
> one by one in a 'fixing' approach). Semantic routing is no different to 
> me on that; it's positioning the advancement of the area against the 
> possible progress at architectural level (for which we need research) 
> rather than at the engineering level (which is what we've been doing so 
> far with all the issues that come with it).
> 
> As for COIN and semantic routing together, determining the common threads 
> (vs those that may be distinctly different) is key to the activities 
> here, which why I had seen semantic routing as an 'applicability area', 
> using the term introduced in the email to the list that stirred much of 
> the recent discussion.
> 
> Best,
> 
> Dirk
> 
> Cc: 'Haoyu Song' <[email-masked]>; 'King, Daniel' 
> <[email-masked]>; Jon Crowcroft <[email-masked]>; 
> [email-masked]; [email-masked]
> i'm still lost as to what new knowledge that research will generate - as 
> opposed to the shopping list of problems that need fixes.
>

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 3 Feb 2022 10:03:29 +0000

-----Original Message-----
From: Jon Crowcroft [mailto:[email-masked]] 
Sent: 03 February 2022 10:14
To: Dirk Trossen <[email-masked]>
Cc: Jon Crowcroft <[email-masked]>; [email-masked]; 'Haoyu Song' <[email-masked]>; 'King, Daniel' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Coin] Starting point for Semantic Routing discussions

the active network program was started by David Tennenhouse at DARPA with the bold idea that packet headers could be programs. that was very clearly a moonshot, designed to make people think.

some of the cool work on SDN controllers inherited the computer science problem of making them safe through verification, thus fulfilling prt of scott shenker's vision on this area of injecting some of the computer science advances of the past 20 years into the 50 year old space of network engineering

at the same time, industry folks and others looked at another sequence of owrk from generalsed switch management protocols, and what might be done in switches, and out came openflow and P4 (and ongoing work there too)...

the  in-network compute now continues in that vein..
[DOT] I'm not saying COIN is AN but your last statement above seems to place AN in the lines of thinking that is COIN, which is along the lines of my point. 

so where does semantic routing fit?
firstly, all routing is semantic routing already. we have pretty clear definitions from way back of how routes are computed and how forwarding is done. and the interaction between the two.
[DOT] This aligns with the survey draft, I'd say. 

we also have a long list of perceived limitations of how that doesn't do (well, or at all) some things some people think routing should do

we also have some limited domains where people already ignore that, and just get on with solving those problems in a specialised context (e.g. data centers, edge iot nets, space networks, etc etc)

but if you want a research program in semantic routing, i think you need a vision like tennenhouse's original one  for active networks, that gets away from just federating a bunch of specialised solutions, and brings some sort of unifying abstraction 
[DOT] I do agree on that need for a vision indeed. But given that you said that 'in network compute is not active networking', aren't we similarly still searching for that abstraction for COIN, as also solicited in its charter, or do you see Tennenhouse applying to COIN, i.e., it is the founding vision? So while I agree that striving for such abstraction is key, is it a prerequisite for starting work on it? 

you actually need to define "semantics" - it isn't pixie dust - people have a bunch of tools in computer science for doing that  - and there are also a few papers out there that have tried to tackle this https://www.cl.cam.ac.uk/~tgg22/metarouting/
http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/06/abc.pdf
https://arxiv.org/abs/1606.07523
etc etc
[DOT] Yes, I do agree on that.

what would this unifying abstraction for what's in packets, what's in router state and how/when did it get there, and formally, how these relate (semantically)?
initially, perhaps, relatively unconstrained , but then a program of research to figure out how practically to constrain those semantics so we don't have something where all the tools of CS (implementation, performance, correctness) are insoluble?
[DOT] Agree, key point for a consolidated research would also be what 'semantics' are indeed feasible and which others (for what reasons) simply are not. I would expect insights that tell us what information one should not rely on in a routing problem.

> many problems outlined, e.g., how to program those distributed nodes, 
> how to deploy them, how to secure them (and the execution). We've had 
> SDN for some time, P4 emerged around the time of COIN (not sure of the 
> exact timing here), and hey, we can just stick a server next to a 
> network node as a crude approach. So in manner, compute in the network 
> is something we know (quite well, in fact) but may not be happy with 
> how it's solved so far. But the questions asked in those efforts are 
> similar to those we ask in COIN.
> 
> In another conversation, you pointed me to the COIN charter text that 
> is capturing the broad essence of what COIN is about, namely "Research 
> on novel architectures, data-plane abstractions and new network 
> protocol designs to efficiently federate decentralized  computing 
> resources, across the infrastructure regardless of where in the 
> network the compute is placed (the DC, the core, the edge, and even in 
> the end-user devices).". It is this that binds the questions above 
> (which could easily be diced and sliced for being addressed in other 
> places of the IRTF or
> survey draft outlines the many ways in which it's been done so far 
> with many (sliced and diced) solutions having emerged. What may be 
> missing are the issues stemming from that point-wise approach to it, 
> granted. But it's not difficult to see for me how a similar "research 
> on novel..." can be formulated for semantic routing, progressing from 
> the way it's been done until today. Questions may be similar to those 
> above (on securing, deploying, programming) but they may also be 
> different, something to figure out properly.
> 
> addressing them (possibly different to when addressing the shopping 
> list one by one in a 'fixing' approach). Semantic routing is no 
> different to me on that; it's positioning the advancement of the area 
> against the possible progress at architectural level (for which we 
> need research) rather than at the engineering level (which is what 
> we've been doing so far with all the issues that come with it).
> 
> As for COIN and semantic routing together, determining the common 
> threads (vs those that may be distinctly different) is key to the 
> activities here, which why I had seen semantic routing as an 
> 'applicability area', using the term introduced in the email to the 
> list that stirred much of the recent discussion.
> 
> Best,
> 
> Dirk
> 
> i'm still lost as to what new knowledge that research will generate - 
> as opposed to the shopping list of problems that need fixes.
> 
> > solutions and consider the more general situation and the needs of 
> > the routing/forwarding system itself. Only by doing this will we 
> > avoid being dragged into the specifics of certain scenarios that 
> > tempt researchers to become engineers solving a problem in a 
> > particular space without proper consideration of its impacts and wider utility.
> >
> > Cheers,
> > Adrian
> >
> > I enjoyed reading the draft and I think you have provided an 
> > excellent summary of the concept and survey of the state-of-art. 
> > Also the issues of all aspects we should be concerned are also 
> > clearly stated. The conventional policy-based routing as I 
> > understood belongs to the broader semantic routing. Given such a 
> > wide spectrum of techniques covered by the concept, maybe we should 
> > also discuss what's the requirements for routers case by case. If 
> > some do need "compute in network" then they are clearly in the scope 
> > of  COIN. Of course, what's considered "compute" in the context of 
> > "in network" should also be clarified. I'd like to see more discussions on this topic.
> >
> > Best,
> > Haoyu
> >
> > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdat
> > at
> > racker
> > .ietf.org%2Fdoc%2Fdraft-farrel-irtf-introduction-to-semantic-r&amp;d
> > at
> > a=04%7
> > C01%7Chaoyu.song%40futurewei.com%7C74ccbb8cc96b419896cc08d9e6687137%
> > 7C
> > 0fee8f
> > f2a3b240189c753a1d5591fedc%7C1%7C0%7C637794158530017204%7CUnknown%7C
> > TW
> > FpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > 3D
> > %7C300
> > 0&amp;sdata=YnA%2B4kZbnuk4XM6AlZ%2BwdcuO1TVet%2Bj5StSPVIJtj%2Bs%3D&a
> > mp
> > ;reser
> > ved=0
> > (for NFV, SFC, application layer compute, transport layer proxying, 
> > or application layer relay), but it is about how packets navigate 
> > the packet-layer network to get to the interface to which they are 
> > Thus, for example, the shortest-path first algorithm used to 
> > determine how to forward packets in networks gathering network state 
> > and per-hop metrics using OSPF or IS-IS. One strong reason for using 
> > a network-wide algorithm is the stability and predictability it 
> > affords especially in the face of change within the network.
> >
> > Over time, more sophistication has been required. Different classes 
> > of service have demanded that packets receive prioritised 
> > mechanisms have required separation of traffic flows; and traffic 
> > has been steered to resource-rich links and away from points of 
> > congestion. Some approaches to this have been DiffServ, 
> > utilised "markers" in the packets so that they could receive the 
> > right forwarding treatment, but the algorithms in the network 
> > remained network-wide to maintain the necessary stability.
> >
> > Semantic Routing is the generic name given to forwarding packets 
> > based on information beyond the regular destination IP address 
> > carried in the packets. That information might be:
> > Or they might be programmed by a central controller that is running 
> > an algorithm and learning network state. Or they could be 
> > constructed in the network nodes using state information learned 
> > from within the network and applying algorithms that have been 
> > installed (programmed) onto the nodes. The algorithms could even be 
> > dynamic, performing computations (not just simple lookups) on each packet.
> >
> > - The overlap between Semantic Routing and established practices 
> > like
> SDN
> > described in papers over the years). What we are trying to do is 
> > bring this all together by:
> > - Pulling out specific threads for discussion (such as the 
> > relationship
> to
> > A couple of additional threads will follow to start to scratch at 
> > how and where Semantic Routing might be applicable within COIN. I 
> > hope that RG participants will follow up with their opinions of how 
> > we fit in, what work they have already done in this area, and what 
> > additional work would be appropriate.
> >
> > Best,
> > Adrian
> >
> > --
> > Coin mailing list
> > [email-masked]
> > rg%2Fmailman%2Flistinfo%2Fcoin&amp;data=04%7C01%7Chaoyu.song%40futur
> > ew
> > ei.com
> > %7C74ccbb8cc96b419896cc08d9e6687137%7C0fee8ff2a3b240189c753a1d5591fe
> > dc
> > %7C1%7
> > C0%7C637794158530017204%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> > LC
> > JQIjoi
> > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HMfqE2blEZPQ
> > JV
> > y8pkZr

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Feb 2022 16:31:35 -0000

Hi Jon,

I think I am mainly in agreement with you, and in some disagreement with
Haoyu.

I think there are different concepts of "requirements".

Many (most?) requirements drive engineering. That is, "We have a specific
problem we need a solution for: here are the requirements."

And it is true that some research is totally open in the mode of, "Let's do
some stuff and see what happens: then maybe we will learn stuff that can be
applied to known problems."

But I think some research is deliberately constrained by requirements. Most
obviously, in human medicine, we may try out all sorts of concoctions, but
we are usually constrained by the requirement that we don't kill the
experimental subjects, and we are often constrained by trying to understand
specific situations, how they manifest, and what changes them.

In this case, it is fine (and probably good) that some networking research
tries out new weird and wonderful ideas. One might hope that such research
is not held back by people's opinions of whether it will be harmful or not,
and why should we worry if researchers spend their efforts on something that
is no use to anyone? But, when the research is into "modifications we can
make to the existing routing systems" it may be helpful to understand what
questions the research must answer as part of evaluating its value and
likelihood to influence the engineering community.

Thus, this document attempts to collect those questions. In trying to bridge
the gap between what Haoyu was saying and what this document does, I used
the phrase 
> I think that will seed the "requirements"
Perhaps that looks too much like engineering requirements. On the other
hand, there are some basic "requirements" (like ability to actually deliver
packets) that are real and must be used to assess research outcomes.

But, as my grandmother used to say (missing the accents because I can't be
bothered to find out how to persuade Microsoft to include them), "Nrad
sprchenk, mai blsanchka en drodny."

Best,
Adrian

-----Original Message-----
From: Jon Crowcroft <[email-masked]> 
Sent: 02 February 2022 21:45
To: [email-masked]
Cc: 'Haoyu Song' <[email-masked]>; [email-masked]; 'King, Daniel'
<[email-masked]>; [email-masked]; Jon Crowcroft
<[email-masked]>
Subject: Re: [Coin] Starting point for Semantic Routing discussions

opposed to

and requirements are part of engineering. research isn't a requirement, it
is curiosity led.

> queueing/forwarding;
> specific
> this

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 3 Feb 2022 08:46:12 -0800

I think another starting point could be “what is the network that COIN
enables” and see where semantic routing fits.

In my class I told my students that in a COIN world the network is more
like a multiprocessor computer board with CPUs and memory mets distributed
throughout. So not a packetized “telephone network”.

In fact someone on the list said in the past that if the network is a
computer board then the (IP) protocols become the OS. So how is semantic
routing part of that OS (and of course COIN could define that OS).

mjm

Marie-José Montpetit, Ph.D.
[email-masked]

From: Adrian Farrel <[email-masked]> <[email-masked]>
Reply: [email-masked] <[email-masked]> <[email-masked]>
Date: February 3, 2022 at 11:32:10 AM
To: Jon Crowcroft <[email-masked]> <[email-masked]>
Cc: Haoyu Song <[email-masked]> <[email-masked]>, King,
Daniel <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]>
<[email-masked]>, [email-masked] <[email-masked]>
<[email-masked]>
Subject:  Re: [Coin] Starting point for Semantic Routing discussions

Hi Jon,

and why should we worry if researchers spend their efforts on something
that

Thus, this document attempts to collect those questions. In trying to
bridge
the gap between what Haoyu was saying and what this document does, I used
the phrase

Best,
Adrian

-----Original Message-----
From: Jon Crowcroft <[email-masked]>
Sent: 02 February 2022 21:45
To: [email-masked]
Cc: 'Haoyu Song' <[email-masked]>; [email-masked]; 'King, Daniel'

> It is notable that some previous discussions of solutions within the
space

> Thus, for example, the shortest-path first algorithm used to determine
how
> The forwarding tables might be fed by established network wide
algorithms,

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 3 Feb 2022 17:01:33 +0000

Marie-Jose,

Let’s just follow through with this still rather high-level abstraction. Aren’t what I called ‘applicability areas’ for COIN all those algorithmic problems that COIN may well enable (although note that I would argue that those algorithmic problems may well be solved without a notion of a ‘network is the computer’ world to emerge), i.e., the ‘programs’, including a notion of an OS, that may run on that computer?

So again, it poses the question as to which algorithmic problems should be of interest to COIN and why? The OS argument does not convince me since, if anything, the appeal of having a general purpose computing network would be to NOT have some form of ‘defined OS’.

Dirk

From: Coin [mailto:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: 03 February 2022 17:46
To: [email-masked]; Jon Crowcroft <[email-masked]>
Cc: King, Daniel <[email-masked]>; Haoyu Song <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Coin] Starting point for Semantic Routing discussions

I think another starting point could be “what is the network that COIN enables” and see where semantic routing fits.

In my class I told my students that in a COIN world the network is more like a multiprocessor computer board with CPUs and memory mets distributed throughout. So not a packetized “telephone network”.

In fact someone on the list said in the past that if the network is a computer board then the (IP) protocols become the OS. So how is semantic routing part of that OS (and of course COIN could define that OS).

mjm

Marie-José Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>

From: Adrian Farrel <[email-masked]><mailto:[email-masked]>
Reply: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Date: February 3, 2022 at 11:32:10 AM
To: Jon Crowcroft <[email-masked]><mailto:[email-masked]>
Cc: Haoyu Song <[email-masked]><mailto:[email-masked]>, King, Daniel <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject:  Re: [Coin] Starting point for Semantic Routing discussions

Hi Jon,

Best,
Adrian

-----Original Message-----
From: Jon Crowcroft <[email-masked]<mailto:[email-masked]>>
Sent: 02 February 2022 21:45
To: [email-masked]<mailto:[email-masked]>
Cc: 'Haoyu Song' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'King, Daniel'
<[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Jon Crowcroft
<[email-masked]<mailto:[email-masked]>>
Subject: Re: [Coin] Starting point for Semantic Routing discussions

> From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of Haoyu Song
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: 'King, Daniel' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel
> To: [email-masked]<mailto:[email-masked]>
> Cc: 'King, Daniel' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
.ietf.org<http://ietf.org>%2Fdoc%2Fdraft-farrel-irtf-introduction-to-semantic-r&amp;data=04%7
C01%7Chaoyu.song%40futurewei.com<http://40futurewei.com>%7C74ccbb8cc96b419896cc08d9e6687137%7C0fee8f
> [email-masked]<mailto:[email-masked]>
>
rg%2Fmailman%2Flistinfo%2Fcoin&amp;data=04%7C01%7Chaoyu.song%40futurewei.com<http://40futurewei.com>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Feb 2022 17:02:48 -0000

Oh, that’s a fun and valuable way to cut the problem.

> enables” and see where semantic routing fits.

In fact, I would find that a really helpful place to start, but I am not a COIN expert and I don’t know where to turn to understand what that network is.

> In my class I told my students that in a COIN world the network is

> more like a multiprocessor computer board with CPUs and memory

> mets distributed throughout. So not a packetized “telephone network”.

Yeah

> computer board then the (IP) protocols become the OS.

And that seems (to me) to be a confused analogy.

It may be that the protocols that decide to which component to next move some data are the OS, but I think that the protocols that are responsible for getting the data to the next component are the bus.

> So how is semantic routing part of that OS (and of course COIN could define that OS).

So, in my view, semantic routing (being part of the packet forwarding layer) is about the bus, not the OS. 

That is not to say that there isn’t an important interaction and overlap. The OS says where the data must get to next, and the bus has to work out how to do that. The OS may place specific requirements on the delivery to the next component (latency, privacy, taste, aeration), and the bus has to work out how to meet those requirements.

Further, there may be a feedback where the bus is able to tell the OS what services it can provide. But I don’t see the bus as part of the OS just as I don’t see the CPU, memory, etc. as part of the OS.

Ciao,

Adrian

From: Adrian Farrel  <mailto:[email-masked]> <[email-masked]>
Reply: [email-masked] <mailto:[email-masked]>   <mailto:[email-masked]> <[email-masked]>
Date: February 3, 2022 at 11:32:10 AM
To: Jon Crowcroft  <mailto:[email-masked]> <[email-masked]>
Cc: Haoyu Song  <mailto:[email-masked]> <[email-masked]>, King, Daniel  <mailto:[email-masked]> <[email-masked]>, [email-masked] <mailto:[email-masked]>   <mailto:[email-masked]> <[email-masked]>, [email-masked] <mailto:[email-masked]>   <mailto:[email-masked]> <[email-masked]>
Subject:  Re: [Coin] Starting point for Semantic Routing discussions 

Hi Jon, 

Best, 
Adrian 

-----Original Message----- 
From: Jon Crowcroft <[email-masked] <mailto:[email-masked]> > 
Sent: 02 February 2022 21:45 
To: [email-masked] <mailto:[email-masked]>  
Cc: 'Haoyu Song' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; 'King, Daniel' 
<[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Jon Crowcroft 
<[email-masked] <mailto:[email-masked]> > 
Subject: Re: [Coin] Starting point for Semantic Routing discussions 

> From: Coin <[email-masked] <mailto:[email-masked]> > On Behalf Of Haoyu Song 
> To: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]>  
> Cc: 'King, Daniel' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>  
> To: [email-masked] <mailto:[email-masked]>  
> Cc: 'King, Daniel' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>  
.ietf.org <http://ietf.org> %2Fdoc%2Fdraft-farrel-irtf-introduction-to-semantic-r&amp;data=04%7 
C01%7Chaoyu.song%40futurewei.com <http://40futurewei.com> %7C74ccbb8cc96b419896cc08d9e6687137%7C0fee8f 
> [email-masked] <mailto:[email-masked]>  
> 
rg%2Fmailman%2Flistinfo%2Fcoin&amp;data=04%7C01%7Chaoyu.song%40futurewei.com <http://40futurewei.com>  
> [email-masked] <mailto:[email-masked]>  
> [email-masked] <mailto:[email-masked]>  

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