Re: [Coin] Semantic Routing : Abstract definition? Architectural formulation?

[Toerless Eckert <[e-mail]>]

Thanks, Nirmala

And on top of everything Nirmala nicely summarized, i can pile up another layer
of the problem, which is how to solve all these problems according to the constraints
of the target network.

On one end you can have a constrained IoT network where every hop has a good amount
of compute but you must save every bit on the wire you can and you actually want
the compute to be as seldom as possible, because you also want to save battery by
sleeping the CPU.

On the other end of the spectrum, 100Gbps++, you want to minimize the amount of
memory read-cycles necessary for forwarding, and even more so write cycles. At least
on the fastest of routers, so-called P-nodes. You may be willing to spend maybe
up to 10x the amount of read/write cycles on an edge-node, aka: on the beginning and
end of a path or domain.

And there is a whole set of more issues related to implementation challenges,
or shall i say the programmability model ?

I don't think i have seen these issues collected anywhere well though.

Cheers
    Toerless

On Tue, Mar 08, 2022 at 02:52:42PM +0000, Nirmala Shenoy wrote:
> Hello all 
> See my comments below initialed NS on Carston's suggestions. I would like to investigate our solution options further based on the suggestions by Jon Crowfort, Carston nad Dirk Kutscher - but would appreciate any direction on how to proceed. 
> 
> Thanks
>  Nirmala 
> 
> -----Original Message-----
> From: Coin <[e-mail]> On Behalf Of Adrian Farrel
> Sent: Thursday, March 3, 2022 5:28 PM
> To: [e-mail]
> Cc: 'Carsten Bormann' <[e-mail]>; 'Bernier, Daniel' <[e-mail]>; [e-mail]; 'Dirk Kutscher' <[e-mail]>
> Subject: [Coin] Semantic Routing : Abstract definition? Architectural formulation?
> 
> Hi again,
> 
> Picking up the third thread arising from questions at the interim.
> 
> Joerg Ott asked about the "picture" I had in mind. I think he was objecting to the fragmented and somewhat abstract view that was coming across, and wanted a step-back big picture. Dirk Trossen jumped in to voice his agreement with what Jon Crowcroft had said on the list that, "There needs to be some 'vision', architecture and abstractions." My comment at the time was that this needs to be supplemented with some concrete formulations of the problems that are being addressed.
> 
> All I can say to this is, "Yes." 
> 
> We've started work on this, and (as you might imagine) it is a largish piece of work. That is, it is not a lot of pages, but it is quite an effort to get the taxonomy and ontology tight and precise. We think this will probably turn into a paper.
> 
> I hope that it may lead on to something more concrete. As Carsten Bormann put in the interim, "If we can come up with a labeling system that allows different parts of the overall system to evolve independently, and that provides a reasonable level of incentives to produce/make use of such information, we win."
> 
> NS: This seems to align with some of the features of Expedited Internet Bypass Protocol (EIBP) discussed in some detail in  https://www.ietf.org/archive/id/draft-jia-intarea-internet-addressing-gap-analysis-02.html and more details in the SARNET 21 and NIPAA 2020 (invited talk) publications. EIBP  proposes a modular solution to assign addresses to routers using  physical/virtual structures in networks, thus avoiding the need for routing protocols. This would simplify router operations and speed up packet forwarding significantly. 
> EIBP allows limited domains to use their own addressing scheme suited to their network constraints etc. Thus limited domains and  addresses in the limited domain can evolve independently. 
> 
> 
> Dirk Kutscher framed this with a warning, "The problem is that there is a matrix of desirable functionality and different conceivable technical means (e.g., app-layer overlays, SFC, NFV, IP layer QoS++, programmable forwarding  semantics). You need a[n] architectural formulation to explain why a particular subset is the right one." And Joerg Ott qualified this as, "...for a given problem space." 
> 
> Daniel Bernier took this a step further to ask about the "contractual notion" whereby knowledge of the capabilities of the forwarding entity must be known. This is the classic question that we have seen in various proposals and proto-solutions where, on the one hand the network tells the application what it can do, and on the other hand, the application tells the network what it wants done. Possibly the solution lies with a "broker" in the middle handling the application's declarative requests and mapping them according to what the network has said it can provide before actually instructing the network elements. As Nik Sultana then pointed out, this also has implications for information shared between routing domains.
> 
> I think all of this nicely sets the broad challenge of understanding what semantic routing could offer and what problems it could encounter. And, as I said at the time, it would be good if we could see something that could span multiple problem spaces because generic versus specific is always an interesting trade.
> 
> So, as we work on the abstraction, we are happy to have collaborators.
> 
> Best,
> Adrian
> 
> --
> Coin mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/coin
> 
> -- 
> Coin mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/coin

-- 
---
[e-mail]