Re: [Coin] Starting point for Semantic Routing discussions

[Dirk Trossen <[e-mail]>]

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

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

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
> 
> -----Original Message-----
> From: Coin [mailto:[e-mail]] On Behalf Of Jon Crowcroft
> Sent: 02 February 2022 22:45
> To: [e-mail]
> Cc: 'Haoyu Song' <[e-mail]>; 'King, Daniel' 
> <[e-mail]>; Jon Crowcroft <[e-mail]>; 
> [e-mail]; [e-mail]
> 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.
> 
> and requirements are part of engineering. research isn't a 
> requirement, it is curiosity led.
> 
> > 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 <[e-mail]> On Behalf Of Haoyu Song
> > Sent: 02 February 2022 18:44
> > To: [e-mail]; [e-mail]
> > Cc: 'King, Daniel' <[e-mail]>; 
> > [e-mail]
> > 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 <[e-mail]> On Behalf Of Adrian Farrel
> > Sent: Wednesday, February 2, 2022 8:24 AM
> > To: [e-mail]
> > Cc: 'King, Daniel' <[e-mail]>; 
> > [e-mail]
> > 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%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
> > 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
> >
> > --
> > Coin mailing list
> > [e-mail]
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > irtf.o
> > 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
> > DWet060HjoigZkSzN2fcJFA%3D&amp;reserved=0
> >
> > --
> > Coin mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/coin
> >
> > --
> > Coin mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/coin
> >
> --
> Coin mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/coin
>