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

[Toerless Eckert <[e-mail]>]

The problem to me is that IETF leadership seemingly does not want to support either
an experimental WG or RG to work on better network protocols and their aspects
such as semantic addressing. Something like IP-NG on steroids except for not
calling in victory when an IPv4 with just fixed 128 bit addresses emerges as
the solution to all (Internet) problems. Like we did in the 90. And not even
doing any experimental work on a lot of good IP-NG work from back then.

The problem for COIN with these leadership dogmas is that research into the programmability of
forwarding planes is intrinsically tied to the protocols/forwarding planes using it.

If we only stick with our 40 year old IP protocol (with only 20 year old addresses ;-),
then there is very little research needed for better programmable forwarding planes,
except for trying to figure out what higher-up-the-stack functionality can be
done with the programmable forwarding planes. Where we would run into the same
issue too: As soon as you start focusing on new highler layer protocols to better
suit specific constrained programming environments, you would again be questioned
like i am being questioned here: how does that protocol then belong into COIN ?

Cheers
    Toerless

On Wed, Mar 09, 2022 at 10:05:42AM +0000, Jon Crowcroft wrote:
> nicely put - so in some sense coin could contribute the programmable
> _reduction_ in functionality that  a lot of systems want voluntarily
> to incur...
> 
> On Wed, Mar 9, 2022 at 9:58 AM Toerless Eckert
> <[e-mail]> wrote:
> >
> > Jon, *:
> >
> > Obviously self-serving giving my draft-eckert-intarea-functional-addr-internets,
> > but even without that i will claim that the past 30 years have shown that a
> > single global end-to-end address space does not only have benefits. For
> > all intent and purpose, rfc1981 might have provided more benefits than downsides,
> > privacy addressing in IPv6 seems to be a proof point of that, like do solutions
> > like MUD. How can we continue to claim that we want an unfethered end-to-end
> > Internet model and that that is sufficient for everything, when nobody in their
> > right might would connect anything critical directly to the Internet without
> > a firewall. An element in the path for which i still have seen no good architectural
> > document in the IETF.
> >
> > I think it would be architecturally prudent to acknowledge reality and recognize
> > the Internet as a network not connecting only devices end-to-end but networks
> > that do provide additionals functions for the devices behind them. And that
> > these networks want to share as much as possible of the IETF TCP/IP protocol
> > architecgture, but need more freedom in addressing, filtering, privacy and so on.
> >
> > Just saying..
> >
> > Cheers
> >     Toerless
> >
> >
> > On Wed, Mar 09, 2022 at 08:23:49AM +0000, Jon Crowcroft wrote:
> > > interesting stuff - most these sorts of scehemes run into trouble (as does  the whole history
> > > of cidr/longest prefix stuff & aggregation) when you have multihoming...
> > >
> > > by the way, i recall charigin the BOF on IPng requirements (20+ years ago) and we very
> > > specifically considered most the same questions (certainly, very large numbers of small
> > > footprint devices was absolutely on topic then - folks at boeing had come in with some
> > > interesting estimates which raised eyebrows a bit, but are looking pretty solid 2 decades
> > > later)  - was captured in
> > > https://datatracker.ietf.org/doc/html/draft-ipng-recommendation-00
> > >
> > > I'm not sure much has changed :-)
> > >
> > >
> > >
> > >
> > > > Here they are Adrian
> > > >  1.     Nirmala Shenoy, Shreyas, Peter Willis, 'A Structured Approach to
> > > > Routing in the Internet' workshop on Semantic Routing and Addressing for
> > > > Future Networks, SARNET 21 in the International Conference on High
> > > > Performance Routing and Switching. 2021, 7-10 June Paris, France.
> > > >
> > > > 2. Nirmala Shenoy, Peter Willis, "Expedited Internet Bypass Protocol",
> > > > Invited Talk, NIPAA, New Internet Protocols Architectures and Algorithms,
> > > > 28th IEEE International Conference on Network Protocols, Oct 13-16 2020.
> > > >
> > > > 3. Nirmala Shenoy, "An Expedited Internet Bypass Protocol - Improving
> > > > Internet Performance", Invited Talk, FIPE Future Internet Protocol
> > > > Evolution, IETF 109 side meeting, IRTF Research Group. 18th Nov. 2020
> > > >
> > > > I have also included an invited talk presentation at FIPE.
> > > >
> > > > Thanks
> > > > Nirmala
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Coin <[e-mail]> On Behalf Of Adrian Farrel
> > > > Sent: Tuesday, March 8, 2022 12:25 PM
> > > > To: Nirmala Shenoy <[e-mail]>; [e-mail]
> > > > Cc: 'Carsten Bormann' <[e-mail]>; 'Bernier, Daniel'
> > > > <[e-mail]>; 'Dirk Kutscher' <[e-mail]>;
> > > > [e-mail]
> > > > Subject: Re: [Coin] Semantic Routing : Abstract definition? Architectural
> > > > formulation?
> > > >
> > > > Thanks Nirmala,
> > > >
> > > > Do you have pointers to your SARNET and NIPAA publications?
> > > >
> > > > Cheers,
> > > > Adrian
> > > >
> > > > -----Original Message-----
> > > > From: Nirmala Shenoy <[e-mail]>
> > > > Sent: 08 March 2022 14:53
> > > > To: [e-mail]; [e-mail]
> > > > Cc: 'Carsten Bormann' <[e-mail]>; 'Bernier, Daniel'
> > > > <[e-mail]>; [e-mail]; 'Dirk Kutscher'
> > > > <[e-mail]>
> > > > Subject: RE: [Coin] Semantic Routing : Abstract definition? Architectural
> > > > formulation?
> > > >
> > > > 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-an
> > > > alysis-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