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

[Toerless Eckert <[e-mail]>]

MJM,

[ formatting: I couldn't figure out from the formatting of your reply which text was from
  you and which was mine (no difference in indentation for example). Maybe its in
  a html version, but i do not use html email. So i hope i identify what you
  wrote correctly. ]

On Wed, Mar 09, 2022 at 06:59:00AM -0500, Marie-Jose Montpetit wrote:
> I think many of the “COIN folks” have been involved int research past and
> current on how dataplane programmability impacts network layer protocols.

I think that if they have not worked in vendors of high-speed routers, they
would only have had limited ability to experiment with the realities of
the equipment and type of forwarding planes that make up the Internet and
many private networks sharing that hardware. P4 is unfortunately the only
widely publically available approximation, and it comes mostly from a
Data-Center forwarding plane requirement level only. Smart-NICs exist but
also have seen mostly use in DC, and the work possible with FPGA hardware
such as kit from XiLinx is so complex that the research with that is
typically very limited to specific algorithms at best.

> 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.

That was the intent.

>> Alas for something like a simple charter ( ;-) ) ...
> I think the charter does include this type of research.

I meant that i have a hard time to formulate simple catchy research questions.

>> 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?

When i was (and still am) doing multicast, i was always trying to explain
to mynetorking colleagues that we need to care more about outreach to the
application folks because that is where the requirements are trickling down
from. 

Ultimately the same is true for programmability. But i think we need a hierarchy
of abstractions from application down to programming. And when talk about
programmable networking, then network protocols, addressing and the like
are the intermediate layer in this hierarchy. Yes, we could try to figure
out how to program against every individual application separately, and 
somethings this is good. But most of the time, you try to find reuseable
abstractions, which such semantic addressing is.

> 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?

You tell me after my presentation what you think ;-)

I have read a lot of research that is challenged by the absence of experience
with actual network operations and equipment / protocol building constraints.

I hope the examples coming from me working for a vendor are just another
interesting data point at the least. Maybe more.

But of course ultimately the question is whether COIN has a critical mass
of paticipants interested to take followup action, on anything presented, right ?

> 
> 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.

I was talking about the programmable chip challenges. Packet header modifications
where easy to do for Barefoot. flexible packet scheduling has been a lot more
challenging. And likely of no immediate interest to Barefoot because the
perceived need in DC is rather small compared to wide-area networks.
Research work like PIFO/PIEO show that research interest and
activity is there, so i think that level of programmability could actually
be front and center for COIN if there is enough interest in the group.

But as mentioned above: One of the programs in this programmability space is
that there are a lot of interesting areas and hence a good fragmentation of
the community. 

> 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.

And i am sure that i can also find 100 research papers around Intent and networking
and still NMRG found it a useful task to start writing documents for a taxonomy,
overwiew etc..

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

As i wrote in my original request mail the goal is to explain the linkage
between the network protocol goals and the programmability aspects.

Ultimately i think the goal is to have researchers develop better
protocols including better semantic addressing by understanding what can and
can not be done in high-speed networking equipment, and vice versa we want
whoever does research in high-speed programmavble networking equipment understand
what better networking protocols need the programmable forwarding plane to do.
Right ?

Cheers
    Toerless

> 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

-- 
---
[e-mail]