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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Mar 2022 22:27:50 -0000

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

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

---

From: Nirmala Shenoy <[email-masked]>
Date: Tue, 8 Mar 2022 14:52:42 +0000

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 <[email-masked]> On Behalf Of Adrian Farrel
Sent: Thursday, March 3, 2022 5:28 PM
To: [email-masked]
Cc: 'Carsten Bormann' <[email-masked]>; 'Bernier, Daniel' <[email-masked]>; [email-masked]; 'Dirk Kutscher' <[email-masked]>
Subject: [Coin] Semantic Routing : Abstract definition? Architectural formulation?

Hi again,

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.

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.

Best,
Adrian

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 8 Mar 2022 18:05:47 +0100

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

-- 
---
[email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 8 Mar 2022 17:25:08 -0000

Thanks Nirmala,

Do you have pointers to your SARNET and NIPAA publications?

Cheers,
Adrian

-----Original Message-----
From: Nirmala Shenoy <[email-masked]> 
Sent: 08 March 2022 14:53
To: [email-masked]; [email-masked]
Cc: 'Carsten Bormann' <[email-masked]>; 'Bernier, Daniel'
<[email-masked]>; [email-masked]; 'Dirk Kutscher'
<[email-masked]>
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 <[email-masked]> On Behalf Of Adrian Farrel
Sent: Thursday, March 3, 2022 5:28 PM
To: [email-masked]
Cc: 'Carsten Bormann' <[email-masked]>; 'Bernier, Daniel'
<[email-masked]>; [email-masked]; 'Dirk Kutscher'
<[email-masked]>
Subject: [Coin] Semantic Routing : Abstract definition? Architectural
formulation?

Hi again,

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. 

Best,
Adrian

---

From: Nirmala Shenoy <[email-masked]>
Date: Tue, 8 Mar 2022 17:36:25 +0000

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 <[email-masked]> On Behalf Of Adrian Farrel
Sent: Tuesday, March 8, 2022 12:25 PM
To: Nirmala Shenoy <[email-masked]>; [email-masked]
Cc: 'Carsten Bormann' <[email-masked]>; 'Bernier, Daniel' <[email-masked]>; 'Dirk Kutscher' <[email-masked]>; [email-masked]
Subject: Re: [Coin] Semantic Routing : Abstract definition? Architectural formulation?

Thanks Nirmala,

Cheers,
Adrian

-----Original Message-----
From: Nirmala Shenoy <[email-masked]>
Sent: 08 March 2022 14:53
To: [email-masked]; [email-masked]
Cc: 'Carsten Bormann' <[email-masked]>; 'Bernier, Daniel'
<[email-masked]>; [email-masked]; 'Dirk Kutscher'
<[email-masked]>
Subject: RE: [Coin] Semantic Routing : Abstract definition? Architectural formulation?

Hello all

Thanks
 Nirmala 

-----Original Message-----
From: Coin <[email-masked]> On Behalf Of Adrian Farrel
Sent: Thursday, March 3, 2022 5:28 PM
To: [email-masked]
Cc: 'Carsten Bormann' <[email-masked]>; 'Bernier, Daniel'

Hi again,

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. 

Best,
Adrian

---

From: Colin Perkins <[email-masked]>
Date: Tue, 8 Mar 2022 20:14:33 +0000

> On 8 Mar 2022, at 17:36, Nirmala Shenoy <[email-masked]> wrote:
> 
> Here they are Adrian

For clarity: the FIPE side meeting was an unofficial side meeting. It was not an IRTF event or research group. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 8 Mar 2022 19:09:09 -0500

Hi Nirmala:

This is interesting research. However we (the chairs) feel it is somewhat
not related to what COIN is about. Would you please highlight what you feel
is related to data plane forwarding? We see this as routing work.

Thanks :)

J/E/M

Marie-José Montpetit, Ph.D.
[email-masked]

From: Nirmala Shenoy <[email-masked]> <[email-masked]>
Reply: Nirmala Shenoy <[email-masked]> <[email-masked]>
Date: March 8, 2022 at 12:37:50 PM
To: [email-masked] <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>
Cc: Carsten Bormann <[email-masked]> <[email-masked]>, Bernier, Daniel
<[email-masked]> <[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>, Dirk Kutscher <[email-masked]>
<[email-masked]>
Subject:  Re: [Coin] Semantic Routing : Abstract definition? Architectural
formulation?

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

Thanks
Nirmala

-----Original Message-----
From: Coin <[email-masked]> On Behalf Of Adrian Farrel
Sent: Tuesday, March 8, 2022 12:25 PM
To: Nirmala Shenoy <[email-masked]>; [email-masked]
Cc: 'Carsten Bormann' <[email-masked]>; 'Bernier, Daniel' <
[email-masked]>; 'Dirk Kutscher' <[email-masked]>; [email-masked]
Subject: Re: [Coin] Semantic Routing : Abstract definition? Architectural
formulation?

Thanks Nirmala,

Cheers,
Adrian

-----Original Message-----
From: Nirmala Shenoy <[email-masked]>
Sent: 08 March 2022 14:53
To: [email-masked]; [email-masked]
Cc: 'Carsten Bormann' <[email-masked]>; 'Bernier, Daniel'

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 <[email-masked]> On Behalf Of Adrian Farrel
Sent: Thursday, March 3, 2022 5:28 PM
To: [email-masked]
Cc: 'Carsten Bormann' <[email-masked]>; 'Bernier, Daniel'

Hi again,

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.

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.

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.

Best,
Adrian

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 8 Mar 2022 19:14:43 -0500

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

From: Toerless Eckert <[email-masked]> <[email-masked]>
Reply: Toerless Eckert <[email-masked]> <[email-masked]>
Date: March 8, 2022 at 12:06:05 PM
To: Nirmala Shenoy <[email-masked]> <[email-masked]>
Cc: Dirk Kutscher <[email-masked]> <[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>, Bernier, Daniel <[email-masked]>
<[email-masked]>, [email-masked] <[email-masked]>
<[email-masked]>, Carsten Bormann <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>
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 ?

Cheers
Toerless

> Cc: 'Carsten Bormann' <[email-masked]>; 'Bernier, Daniel' <
[email-masked]>; [email-masked]; 'Dirk Kutscher' <[email-masked]>

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

-- 
---
[email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 09 Mar 2022 08:23:49 +0000

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.
> 
> <[email-masked]>; 'Dirk Kutscher' <[email-masked]>; 
> [email-masked]
> 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
> 
> 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.
> 
> 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.
> 
> 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.
> 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."
> 
> 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.
> 
> 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.
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Mar 2022 10:47:03 +0100

> 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

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 9 Mar 2022 10:05:42 +0000

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
<[email-masked]> 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:

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 9 Mar 2022 06:59:00 -0500

See inline.

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

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

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

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.

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.

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:

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

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

> to investigate our solution options further based on the suggestions by
Jon
> across, and wanted a step-back big picture. Dirk Trossen jumped in to
voice
> piece of work. That is, it is not a lot of pages, but it is quite an
effort

> matrix of desirable functionality and different conceivable technical
means
> notion" whereby knowledge of the capabilities of the forwarding entity
must

---

From: Nirmala Shenoy <[email-masked]>
Date: Wed, 9 Mar 2022 14:11:07 +0000

Hello Marie-Jose,
   EIBP proposes to use addresses that make routing more efficient and simple. However, EIBP operates at layer 2.5 and forwards the IP packets between source and destination networks/devices.
The goal was to  allow EIBP to work in parallel with IP -- we can turn on EIBP for some or all traffic entering a network.

If I have not clarified – please followup.

Thanks
Nirmala

From: Marie-Jose Montpetit <[email-masked]>
Sent: Tuesday, March 8, 2022 7:09 PM
To: Nirmala Shenoy <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; Carsten Bormann <[email-masked]>; Bernier, Daniel <[email-masked]>; Dirk Kutscher <[email-masked]>
Subject: Re: [Coin] Semantic Routing : Abstract definition? Architectural formulation?

Hi Nirmala:

This is interesting research. However we (the chairs) feel it is somewhat not related to what COIN is about. Would you please highlight what you feel is related to data plane forwarding? We see this as routing work.

Thanks :)

J/E/M

Marie-José Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>

From: Nirmala Shenoy <[email-masked]><mailto:[email-masked]>
Reply: Nirmala Shenoy <[email-masked]><mailto:[email-masked]>
Date: March 8, 2022 at 12:37:50 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Cc: Carsten Bormann <[email-masked]><mailto:[email-masked]>, Bernier, Daniel <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Dirk Kutscher <[email-masked]><mailto:[email-masked]>
Subject:  Re: [Coin] Semantic Routing : Abstract definition? Architectural formulation?

Here they are Adrian

Thanks
Nirmala

-----Original Message-----
From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel
Sent: Tuesday, March 8, 2022 12:25 PM
To: Nirmala Shenoy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: 'Carsten Bormann' <[email-masked]<mailto:[email-masked]>>; 'Bernier, Daniel' <[email-masked]<mailto:[email-masked]>>; 'Dirk Kutscher' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Coin] Semantic Routing : Abstract definition? Architectural formulation?

Thanks Nirmala,

Cheers,
Adrian

-----Original Message-----
From: Nirmala Shenoy <[email-masked]<mailto:[email-masked]>>
Sent: 08 March 2022 14:53
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: 'Carsten Bormann' <[email-masked]<mailto:[email-masked]>>; 'Bernier, Daniel'
<[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Dirk Kutscher'
<[email-masked]<mailto:[email-masked]>>
Subject: RE: [Coin] Semantic Routing : Abstract definition? Architectural formulation?

Hello all

Thanks
Nirmala

-----Original Message-----
From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel
Sent: Thursday, March 3, 2022 5:28 PM
To: [email-masked]<mailto:[email-masked]>
Cc: 'Carsten Bormann' <[email-masked]<mailto:[email-masked]>>; 'Bernier, Daniel'
<[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Dirk Kutscher'
<[email-masked]<mailto:[email-masked]>>
Subject: [Coin] Semantic Routing : Abstract definition? Architectural formulation?

Hi again,

Best,
Adrian

--
Coin mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/coin

--
Coin mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/coin

--
Coin mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/coin

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Mar 2022 19:11:22 +0100

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

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

> from what the community is doing/has been doing will be appreciated.

That was the intent.

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

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

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

> the use of P4 (amongst others). How does your ideas relate or differ from

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 ?

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

> 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

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

-- 
---
[email-masked]