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

[Marie-Jose Montpetit <[e-mail]>]

See inline.

Marie-José Montpetit, Ph.D.
[e-mail]



From: Toerless Eckert <[e-mail]> <[e-mail]>
Reply: Toerless Eckert <[e-mail]> <[e-mail]>
Date: March 9, 2022 at 4:47:07 AM
To: Marie-Jose Montpetit <[e-mail]> <[e-mail]>
Cc: Nirmala Shenoy <[e-mail]> <[e-mail]>, Toerless Eckert
<[e-mail]> <[e-mail]>, [e-mail] <[e-mail]>
<[e-mail]>, [e-mail] <[e-mail]> <[e-mail]>,
[e-mail] <[e-mail]> <[e-mail]>, Carsten
Bormann <[e-mail]> <[e-mail]>, Bernier, Daniel
<[e-mail]> <[e-mail]>, Dirk Kutscher
<[e-mail]> <[e-mail]>
Subject:  Re: [Coin] Semantic Routing : Abstract definition? Architectural
formulation?

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.

I think many of the “COIN folks” have been involved int research past and
current on how dataplane programmability impacts network layer protocols.

Examples of what you feel is missing or what your research is different
from what the community is doing/has been doing will be appreciated.



Alas for something like a simple charter ( ;-) )

I think the charter does include this type of research.

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.

And this is addressing - how does it related to COIN?



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.

There is a lot of research on hardware programmability related to PISA and
the use of P4 (amongst others). How does your ideas relate or differ from
them?



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

Then you agree this in not in the COIN charter? Although one could argue
that scheduling/modifying could be related.



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.

But those are quite generic and well known to the community - we have a
reference list of about 100 papers and books that cover these issues.

So I would hope your presentation will highlight new research in COIN not
in routing.


mjm



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