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

[Toerless Eckert <[e-mail]>]

On Tue, Mar 08, 2022 at 07:14:43PM -0500, Marie-Jose Montpetit wrote:
> Hi Toerless:
> 
> You are indeed listing issues that may not have been collected although I
> would guess that the Barefoot people and other PISA architecture
> implementers must have addressed at least some if not all of these.
> 
> As worthy as these are we would call these engineering issues (constraints
> of memory, power etc.) and we are not an engineering group. Can you
> formulate research questions around those?

The presentation slot i asked for should be a good start for COIN folks
to understand past and current research questions related to mapping
of network layer protocol/service goals to current or future available
programmable forwarding plane functionalities.

Alas for something like a simple charter ( ;-) ) but luckily for the
variety of researcher interests there is IMHO not the one single simple
question like the "we need more addresses for the future Internet in 1990".
but its a whole forest of questions.

If i where to try to find the range of questions it is maybe from:

  I) what is the maximum/best set of functionality required/beneficial
    hop-by-hop in networks (aka: not better done in higher layers).

    That to me is the semantic addressing question.

down to effectively how to do it:

  II) What is the minimum set of programming paradigms for high-speed hardware
    to build all of I) at minimum cost / maximum flexibility and how to build
    those.

    Examples here are PIFO/PIEO, which are a good maybe with PIEO functionlly
    complete but where i still have not seen goood scaleable logic designs, e.g.:
    that scale with less than #flows supported.

    In contrast, for example the UBS (urgency based scheduling) algorithm
    and mathemathical proof reduced the scale requirements of regulator
    elements from #flows to (#interfaces * #priorities), aka: for
    industrial use an important scale improvement to build less expensive HW.

    Aka: the biggest architectural/research challenge is certainly packet scheduling,
    not packet modifications.

And of course there is a circular relationship. If we come up with semantics
that turn out to be too costly to be done well in hardware, then we likely have
to say that it must better happen at higher layers, or not hop-by-hop but
edge-to-edge. ICN for example is lingering on that IMHO, primarily because
of the storage needs, which are today considered to be inappropriately
expensvie hop-by-hop.

But i think we can have some initial architecture , namely recognizing exactly
those different layers:

  - hop-by-hop programmability / semantics
  - edge-node programmavbility / semantic
  - "compute-only" + more storge programmability / semantics

Just as a rough start this is how i would structure the different targets,
but of course wide open to discussion.

    Implementations btw. means 
    
solution goals and mapping that to the better availavle (or not yet available)
underlying 
The four examples from past and ongoing research that i proposed as a talk
are examples of 
> 
> Thanks
> 
> J/E/M
> 
> Marie-José Montpetit, Ph.D.
> [e-mail]
> 
> 
> 
> From: Toerless Eckert <[e-mail]> <[e-mail]>
> Reply: Toerless Eckert <[e-mail]> <[e-mail]>
> Date: March 8, 2022 at 12:06:05 PM
> To: Nirmala Shenoy <[e-mail]> <[e-mail]>
> Cc: Dirk Kutscher <[e-mail]> <[e-mail]>, [e-mail]
> <[e-mail]> <[e-mail]>, Bernier, Daniel <[e-mail]>
> <[e-mail]>, [e-mail] <[e-mail]>
> <[e-mail]>, Carsten Bormann <[e-mail]> <[e-mail]>,
> [e-mail] <[e-mail]> <[e-mail]>
> Subject:  Re: [Coin] Semantic Routing : Abstract definition? Architectural
> formulation?
> 
> 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