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

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

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?

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

-- 
---
[e-mail]

-- 
Coin mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/coin