Re: [Coin] Semantic Routing : Problem and Solution

["King, Daniel" <[e-mail]>]

Hi, all.

Thank you, Adrian, for presenting at the recent interim and continuing the discussion on the list.

I would like to illuminate draft-king-irtf-challenges-in-routing - https://datatracker.ietf.org/doc/html/draft-king-irtf-challenges-in-routing. The work highlights the challenges to the existing routing system that Semantic Routing introduces.

We've had several updates since the document was published last August, reflecting discussion and feedback from several reviewers. One recent topic of interest on the COIN mailing list and discussed in the draft is "Programmable Paths". We cite several proposals for programmable paths, facilitating users and applications to select network paths themselves based on the required path characteristics.

Various programmable path proposals are based on overlay solutions. Typically, this strategy adds significant resource allocation to meet state requirements (network, CPU, memory, et al.). Another option is an entirely new control and forwarding technology, but it requires an altogether new technology domain and greenfield deployment. Regardless of the method, this innovation raises critical challenges from the service provider's perspective - special thanks to Christian Jacquenet for his recent contributions to the discussion.

I'd love to continue capturing the current routing challenges, including those for COIN use cases and applications. Framing them as research questions would be helpful to summarise the situation and the opportunity for further research. The big over-the-top content providers can often deploy innovative technology in isolation; they operate hyperscale domains interconnected via gateways. However, a traditional operator may have to continue to offer legacy technology layers and interfaces, making greenfield deployments more complex and costly. What does the research group think? Do new routing approaches need to be integrated with existing routing/forwarding paradigms, or should we assume greenfield deployments?

BR, Dan.

-----Original Message-----
From: Coin <[e-mail]<mailto:[e-mail]>> On Behalf Of Adrian Farrel
Sent: 28 February 2022 17:00
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; 'Dirk Kutscher' <[e-mail]<mailto:[e-mail]>>
Subject: [Coin] Semantic Routing : Problem and Solution

Hi again,

Two related questions were asked during the interim that may have slightly missed the point of the work we are doing.

Phil Eardley asked about the comparison with MPLS saying, "You just said something like 'Flag packet with behavioural quality that an ISP should provide' - this sounds like MPLS, except you hope the 'flag' is not confined to a domain. Wouldn't that have the same issues that inter-domain MPLS does?"

And Dirk Kutscher noted that, "If the goal is to make the network do something useful for applications, it may be useful to be more specific about that exactly this could entail: Is it QoS on steroids?"

Both of these questions assume that what we are trying to do is engineer a specific solution to a set of problems. But this is back to front. What we have observed is that a lot (and I mean a lot) of technology enhancements have been floated over the years aimed at solving one problem or another.
More proposals are made almost daily. The general problem space that these solutions address can be loosely described as, "Getting the network to differentiate the treatment of packets according to the service that the traffic flows require as indicated by information carried in the packets."
Some of the proposals result in different queueing/forwarding behaviours, while others result in traffic taking different paths through the network, but you can probably safely categorise the whole thing as "QoS on steroids with additional awareness of service functionality."

Our observation leads us to several things we want to see happen:

1. More coordination between research activities into this type of problem/solution so that knowledge is shared and not "rediscovered" or "reinvented" each time.

2. Better awareness of the impact on the routing system of applying these solutions.

3. Greater understanding on the overlap with existing initiatives that are both research and engineering, such as SDN, network programming, compute in the network, etc.

4. A generic abstract definition for the field (building on a taxonomy and an ontology, and which is not self-referential) and the research questions that arise.

The first of these comes through our literature search draft and, of course, by getting people to talk about the work on this list.

The second is initiated by draft-king-irtf-challenges-in-routing. We see this document as a place to capture the current state of the discussion so that no one has to trawl the email archives. It obviously deserves wider review and input from the routing engineering community, too. The end result may well be publication, but whether as a paper or an RFC or something else is a decision to be made far in the future.

The third is definitely work in progress and for discussion. There are several drafts kicking around that start to capture the discussions to date, and (just as important) to open up topics for further debate on the COIN list. We think there are also some papers being written in this area and we hope they will show up in COIN. We are aware of a research project currently seeking funding on this topic.

And finally, yes, there is a significant piece of work needed to abstract the definition of semantic routing. That's going to take quite a lot of effort, but it has started (collaborators welcome!)

As you can see, none of those amount to a technology problem we want to see solved, or specific engineering solution.

I hope this helps answer the questions and also give some context/perspective.

Best,
Adrian