Subject: Re: [arch-d] [icnrg] recasting address semantics

From: "David R. Oran" <[email-masked]>
Date: Thu, 24 Feb 2022 17:42:47 -0500

On 24 Feb 2022, at 5:45, Dirk Trossen wrote:

> Hi Dirk, all,
>
> Interesting post, indeed. I came across it shortly after posting since 
> Geoff has been engaged (as he alludes to in the blog) in the internet 
> addressing discussion in the INTArea, so he'd fed back his view of 
> "perhaps an address these days is just an ephemeral transport token 
> that distinguishes one packet flow from another, and really has little 
> more in the way of semantic meaning. " to us in the discussions on the 
> ongoing drafts in the INT area.
>
Well, I’d say that it’s a 5-tuple that distinguishes flows, while a 
single IP address identifies one (or a set of equivalent) attachment 
points to a network. That seems to be unchanged since the earliest days 
of IP networking. When used as a destination address, the expectation is 
that some of you packets going there will get delivered as long as the 
network is “working”. When used as a source address, it means that 
if somebody got a packet with this, if it sends a packet to that address 
as a destination, it’s reasonably likely it will get to that 
attachment point.

So, that’s the “semantic meaning” of an address (as one would say 
in the department of redundancy department).

As I interpret this, the crux of Geoff’s point isn’t that the 
semantics are wrong, or somehow different from the early days, but that 
the utility of IP addresses as important stable identifiers has declined 
to the point of near irrelevance, and attempts to “reinvigorate” the 
role of IP addresses for sophisticated services or as identifiers of 
more than ephemeral value to higher layers are a waste of effort. Modern 
transports like QUIC already accommodate ephemeral IP addresses through 
multi path and path shifting. Layers above transport no longer expect 
that arbitrary pairs of endpoint interfaces can directly exchange 
packets and instead build their own logical topologies through proxies 
or application intermediaries running in data center virtual machines.

Now, it’s somewhat of a leap from this to say that it’s a total 
waste of time to try to enhance IP layer routing to do a better job of 
delivering packets among network interfaces because the problems of 
addresses becoming ephemeral mitigates against attempts to be overly 
clever, while at the same time all the interesting stuff happens on top. 
However, it isn’t that much of a leap and I’m more than little 
sympathetic to Geoff’s analysis here.

> But I find this insight little interesting, I must say, since 
> depending on where you are looking from, this isn't particularly 
> interesting at all but merely a recognition of how 'service 
> dispatching' at higher layers works once I have arrived at the network 
> location where this problem needs to be dealt with.
>
I may be misinterpreting you here, but I read this as being exactly 
backwards. As opposed to what you said, I think first you do “service 
dispatching” and then you figure out how to get packets to where you 
dispatched the service. Or, if you want to get really sophisticated, you 
do some joint scheduling that both instantiates computation and installs 
routes to get packets there. This however is not something you want to 
delegate to routing, as the owners of the computing resources and the 
owners of the communication resources are not necessarily the same, 
which argues for this to be a layer 7, and possibly a layer 8 function, 
and not a layer 3 function.

Some of the most illuminating examples here are in the large-scale Video 
streaming systems, which combine the management of origins with the 
allocation of CDN resources, coordinated with the edge delivery from 
access network POPs. A whole business has grown up around this - e.g. 
Conviva (https://www.conviva.com)

> Of course, this view aligns with Geoff's other expressed view that 
> "Internet communication" has converged to a centralized PoP-based 
> model (see, among other occasions, at 
> https://github.com/danielkinguk/sarah/blob/main/conferences/ietf-112/materials/Huston-2021-11-10-centrality.pdf). 
> So when considering his observation on that aspect of centralization, 
> the task of reaching the place of where dispatching to the right 
> service takes place has become rather trivial and it all boils down to 
> his first quoted statement that "perhaps an address these days is just 
> an ephemeral transport token that distinguishes one packet flow from 
> another, and really has little more in the way of semantic meaning. ".
>
> In the context of that centralization observation, however, I find it 
> somewhat disturbing to position the development of IPv6 as "...an 
> IETF-led command-and-control effort that attempted to anticipate 
> future industry needs and produce a technology that would meet these 
> needs". I personally do not believe that this was wrong as an effort 
> and even goal, on the contrary.
>
A time traveler would have gone back and whacked the Berkeley students 
who invented “get host by name” in the sockets API upside the head. 
Exposing IP addresses above the bottom of the transport layer basically 
doomed IPv6 from rapid adoption by requiring you to upgrade the network, 
the host operating systems, and the applications all at once.

> What I find wrong is to manifest the observation of "Today's Internet 
> is dominated by Content Distribution Networks (CDNs) and their 
> associated 'clouds'." as an apparent guidance for developing Internet 
> technologies that may want to go beyond this model since it bears the 
> danger of skewing technology development along a dominant economic 
> model.
I think there are three things to be disentangled here:
1. Physical centralization in data centers as the economics of computing 
has strongly favored that deployment model.
2. Administrative centralization where there are only a few dominant 
players, because all of them were able to leverage existing investments 
in their computing infrastructures to capture large market share (e.g. 
Google through search, Amazon through product sales and fulfillment, 
etc.).
3. More sophisticated applications requiring multi-party distributed 
operation rather than simple pint-to-point data transfer. This could be 
just for scaling (e.g. machine learning, map-reduce data analysis), for 
robustness against outages and unreliable performance characteristics 
(e.g. Akamai CDNs), or for economics of communication pricing (video 
CDNs).

Some would say that either 1 or 3 inevitably leads to 2 unless mitigated 
by laws or regulation. I don’t take a position on that, but whether or 
not we are doomed to be stuck with #2, the other two phenomena by 
themselves reduce the importance of layer 3 routing 
services/capabilities relative to those done above.

> I would argue that the strength of the Internet's original innovation 
> philosophy to enable serendipitous discovery and permissionless 
> innovation is something that may go down the drain with that view. Or 
> vice versa, I wonder if most of what we enjoy as 'the Internet' today 
> would have emerged if this attitude had been at the forefront of its 
> origin some 40 odd years ago (I can hear similar "Today's..." 
> statement, just from a different community back then, wondering what 
> those IP people really want...). Maybe we simply observe the 
> innovator's dilemma here?
>
No, there’s lots of innovation happening. Just not in L3 routing. The 
few substantive attempts to change the architecture at layer 3 to better 
match the evolution of the Internet have not gotten much if any traction 
(e.g. ICN, XIA, Mobility First), but at least they didn’t start by 
accepting the constraints of the IP packet format nor the addressing and 
routing mind set it engenders.

Sorry for the long ramble. The more I read about the “semantic 
routing” work the more pessimistic I am that it will lead anywhere 
useful. Perhaps you will prove me wrong in the end.

Best,
DaveO

> Best,
>
> Dirk
>
> -----Original Message-----
> From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
> Sent: 24 February 2022 11:19
> To: ICNRG <[email-masked]>
> Subject: [icnrg] recasting address semantics
>
> Hi ICNRG,
>
> you may find Geoff's recent blog post interesting:
>
> https://blog.apnic.net/2022/02/01/address-semantics/
>
> Best regards,
> Dirk
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
DaveO

---

From: Geoff Huston <[email-masked]>
Date: Fri, 25 Feb 2022 00:25:48 +0000

> A time traveler would have gone back and whacked the Berkeley students who invented “get host by name” in the sockets API upside the head. Exposing IP addresses above the bottom of the transport layer basically doomed IPv6 from rapid adoption by requiring you to upgrade the network, the host operating systems, and the applications all at once.
> 
> What I find wrong is to manifest the observation of "Today's Internet is dominated by Content Distribution Networks (CDNs) and their associated 'clouds'." as an apparent guidance for developing Internet technologies that may want to go beyond this model since it bears the danger of skewing technology development along a dominant economic model.

I suppose that from at least where I sit there are a couple of views about the process of evolution of Internet technologies (and yes, that may be a false dichotomy, but please bear with me!) The first is the process as a reasoned exercise of trying to construct a response to a collection of identified “needs” and the second is a more chaotic process of market dynamics. Like it or not we threw out most aspects of the former form of “structured” evolution when we deregulated this industry, and in its place we rely solely to market signals to support technology evolution. There is no telephone cartel to orchestrate the actions of various component suppliers and assemble the pieces into a whole. In its place are a set of independent actors each trying to carve out a place within the market. So in my mind, if you accept that view of evolution as a market signalling process the corollary appears to be “follow the money” to find evidence of evolutionary pressures. And yes that places higher rewards on the dominant economic model, for  better or worse.

It's pretty clear where the money is these days, and it's not in the lower layers of the protocol stack. The monetary pressure is to build out larger and faster content and service platforms, not bigger transit networks, and the evidence is all over the place (when was the last NANOG talk about operators fine-tuning BGP for fun and profit? These days the NANOG conversation is about fibre for the Data Centre.) The impoortant corollary is that such innovation has niether the time, patience nor even the willingness to redefine the lower layers of existing infrastructure. The obvious response is to push the innovation further up the protocol stack and ‘hide’ it from the lower layers so they cannot interfere with the new mechanism. We see this with DNS over encrypted channels running within the application, and not in the platform. We see with with QUIC which lifts the transport protocol off the platform and into user space and “hides” the end-to-end transport controls from the network elements. I would argue BBR is a similar step, which further reduces the level of inter-dependency between the transport protocol and the network’s infrastructure. Now in another time and another context where the transport and carriage folk were the domionant economic actors such efforts might have been doomed from the start. But today the money has drifted away from transport and carriage to the point were they have little room to move.

All of this is I suppose a background commentary to why I think the evolution in the treatment of IP addresses away from a stable anchor point in the network that ties together the identity of a service to its location within the network to a far more fluid concept whose major role is to help the network to keep the packet flows distinct! We seem confident that we can repurpose the DNS to carry the bulk of the semantic role that addresses played in the past, and our efforts have been to increasingly customise DNS responses to match eveer more complex rendezvous requirements to allow a client to reach a service (think Client Subnet, think dynamically computed SVCB records and similar). 

The strength of the innovation of the Internet for me lies in the deregulated nature of the activity. There is little to say “you can’t do that!” But the market is also a harsh judge, and concepts that are not economically viable are rapidly discarded, irrespective of any other merits they may have had. In my view what seems to work these days are evolutionary paths that do not attempt to redefine the underlying existing infrastructure, but, in gross terms, ignore it as far as possible!

> 
> The more I read about the “semantic routing” work the more pessimistic I am that it will lead anywhere useful. Perhaps you will prove me wrong in the end.

I also don’t have much optimism about the prospects for “semantic routing”, but I am pretty sure that what will determine the fate of this and similar efforts is simply whether it achieves a stable and viable niche in the market space that collectively we call “the Internet”. i.e. the determination of success or otherwise these days is ultimately based on the deregulated market.

kind regards,

   Geoff

---

From: Christian Huitema <[email-masked]>
Date: Thu, 24 Feb 2022 16:53:14 -0800

On 2/24/2022 4:25 PM, Geoff Huston wrote:

> It's pretty clear where the money is these days, and it's not in the lower layers of the protocol stack.

... with the exception of the physical layer. For example, people are 
paying good money to get their phone connected to a wireless network, 
and wireless companies would not try overbid each other to buy 
frequencies if the business was not profitable.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Feb 2022 14:00:45 +1300

On 25-Feb-22 11:42, David R. Oran wrote:
...
> 
> I may be misinterpreting you here, but I read this as being exactly backwards. As opposed to what you said, I think first you do “service dispatching” and then you figure out how to get packets to where you dispatched the service. 

This. In draft-jiang-service-oriented-ip (which was very preliminary) we made the notion of dispatcher explicit.

Also see https://doi.org/10.1109/INFOCOMWKSHPS50562.2020.9162749 (IEEE paywall).

    Brian

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 25 Feb 2022 08:01:28 +0000

Hi Dave,

Thanks for the thoughts. Please see inline.

Adding RTGWG since Jeff did so after a later  post, so trying to widen the reply audience.

Best,

Dirk

From: David R. Oran [mailto:[email-masked]]
Sent: 24 February 2022 23:43
To: Dirk Trossen <[email-masked]>
Cc: Dirk Kutscher <[email-masked]>; [email-masked]
Subject: Re: [icnrg] recasting address semantics

Hi Dirk, all,

Interesting post, indeed. I came across it shortly after posting since Geoff has been engaged (as he alludes to in the blog) in the internet addressing discussion in the INTArea, so he'd fed back his view of "perhaps an address these days is just an ephemeral transport token that distinguishes one packet flow from another, and really has little more in the way of semantic meaning. " to us in the discussions on the ongoing drafts in the INT area.

Well, I’d say that it’s a 5-tuple that distinguishes flows, while a single IP address identifies one (or a set of equivalent) attachment points to a network. That seems to be unchanged since the earliest days of IP networking. When used as a destination address, the expectation is that some of you packets going there will get delivered as long as the network is “working”. When used as a source address, it means that if somebody got a packet with this, if it sends a packet to that address as a destination, it’s reasonably likely it will get to that attachment point.

So, that’s the “semantic meaning” of an address (as one would say in the department of redundancy department).

As I interpret this, the crux of Geoff’s point isn’t that the semantics are wrong, or somehow different from the early days, but that the utility of IP addresses as important stable identifiers has declined to the point of near irrelevance, and attempts to “reinvigorate” the role of IP addresses for sophisticated services or as identifiers of more than ephemeral value to higher layers are a waste of effort. Modern transports like QUIC already accommodate ephemeral IP addresses through multi path and path shifting. Layers above transport no longer expect that arbitrary pairs of endpoint interfaces can directly exchange packets and instead build their own logical topologies through proxies or application intermediaries running in data center virtual machines.

Now, it’s somewhat of a leap from this to say that it’s a total waste of time to try to enhance IP layer routing to do a better job of delivering packets among network interfaces because the problems of addresses becoming ephemeral mitigates against attempts to be overly clever, while at the same time all the interesting stuff happens on top. However, it isn’t that much of a leap and I’m more than little sympathetic to Geoff’s analysis here.

But I find this insight little interesting, I must say, since depending on where you are looking from, this isn't particularly interesting at all but merely a recognition of how 'service dispatching' at higher layers works once I have arrived at the network location where this problem needs to be dealt with.

[DOT] It is purposefully backwards from the perspective of how I interpret approaches that simply focus on funneling traffic to the DC and let the DC do the dispatching job. Radical propositions like CloudFlare’s ‘single IP for millions of services’ reduce the role of routing of laying a pipe to the DC. The result looks backwards to how I see service dispatching to be done (i.e. along the lines you point out).

Or, if you want to get really sophisticated, you do some joint scheduling that both instantiates computation and installs routes to get packets there. This however is not something you want to delegate to routing, as the owners of the computing resources and the owners of the communication resources are not necessarily the same, which argues for this to be a layer 7, and possibly a layer 8 function, and not a layer 3 function.

[DOT] As Brian points out in a later reply, L3 may play a role here, particularly when the scheduling decision is among distributed network locations and possibly dynamic in nature. Of course, L7/L8 mechanisms do play a role in setting up computation resources and signaling constraints of their use (captured in the CAN pre-BoF as ‘compute-aware networking’). So it isn’t about delegating dispatching as a whole to L3 but about the role L3 may play in the overall process.

Some of the most illuminating examples here are in the large-scale Video streaming systems, which combine the management of origins with the allocation of CDN resources, coordinated with the edge delivery from access network POPs. A whole business has grown up around this - e.g. Conviva (https://www.conviva.com)

Of course, this view aligns with Geoff's other expressed view that "Internet communication" has converged to a centralized PoP-based model (see, among other occasions, at https://github.com/danielkinguk/sarah/blob/main/conferences/ietf-112/materials/Huston-2021-11-10-centrality.pdf). So when considering his observation on that aspect of centralization, the task of reaching the place of where dispatching to the right service takes place has become rather trivial and it all boils down to his first quoted statement that "perhaps an address these days is just an ephemeral transport token that distinguishes one packet flow from another, and really has little more in the way of semantic meaning. ".

In the context of that centralization observation, however, I find it somewhat disturbing to position the development of IPv6 as "...an IETF-led command-and-control effort that attempted to anticipate future industry needs and produce a technology that would meet these needs". I personally do not believe that this was wrong as an effort and even goal, on the contrary.

  1.  Physical centralization in data centers as the economics of computing has strongly favored that deployment model.
[DOT] no disagreement there

  1.  Administrative centralization where there are only a few dominant players, because all of them were able to leverage existing investments in their computing infrastructures to capture large market share (e.g. Google through search, Amazon through product sales and fulfillment, etc.).
[DOT] again agree.

  1.  More sophisticated applications requiring multi-party distributed operation rather than simple pint-to-point data transfer. This could be just for scaling (e.g. machine learning, map-reduce data analysis), for robustness against outages and unreliable performance characteristics (e.g. Akamai CDNs), or for economics of communication pricing (video CDNs).

Some would say that either 1 or 3 inevitably leads to 2 unless mitigated by laws or regulation. I don’t take a position on that, but whether or not we are doomed to be stuck with #2, the other two phenomena by themselves reduce the importance of layer 3 routing services/capabilities relative to those done above.

[DOT] My main point was that the view on “today’s” economic situation is possibly not the best starting point for developing something forward looking, including on L3 routing – see my point below.

I would argue that the strength of the Internet's original innovation philosophy to enable serendipitous discovery and permissionless innovation is something that may go down the drain with that view. Or vice versa, I wonder if most of what we enjoy as 'the Internet' today would have emerged if this attitude had been at the forefront of its origin some 40 odd years ago (I can hear similar "Today's..." statement, just from a different community back then, wondering what those IP people really want...). Maybe we simply observe the innovator's dilemma here?

No, there’s lots of innovation happening. Just not in L3 routing. The few substantive attempts to change the architecture at layer 3 to better match the evolution of the Internet have not gotten much if any traction (e.g. ICN, XIA, Mobility First), but at least they didn’t start by accepting the constraints of the IP packet format nor the addressing and routing mind set it engenders.

Sorry for the long ramble. The more I read about the “semantic routing” work the more pessimistic I am that it will lead anywhere useful. Perhaps you will prove me wrong in the end.

[DOT] Time will tell although, related to this discussion, this wasn’t about semantic routing. As you know, I’ve been active in L3 innovation for some time, including ICN, and its lack of traction in favour of a dominant economic model has been troubling me all along.

Best,
DaveO

Best,

Dirk

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: 24 February 2022 11:19
To: ICNRG <[email-masked]<mailto:[email-masked]>>
Subject: [icnrg] recasting address semantics

Hi ICNRG,

Best regards,
Dirk

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

DaveO

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 25 Feb 2022 08:08:17 +0000

Brian, all,

Thanks for the pointer. The CAN pre-BoF, currently prepared for IETF113, addresses the same space. As pointed out in my reply, I don't see this problem not necessarily as an L7/L8 one only but one where L3 can play a role albeit being conscious of the needed stakeholder exchange that needs to happen in any solution (e.g., signaling suitable metrics for a decision).

Best,

Dirk

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: 25 February 2022 02:01
To: David R. Oran <[email-masked]>
Cc: [email-masked]; Dirk Trossen <[email-masked]>
Subject: Re: [arch-d] [icnrg] recasting address semantics

    Brian

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 25 Feb 2022 08:15:10 +0000

...my household bill for access is certainly much higher than my internet service bill (OTT video, streaming audio, ...) but maybe I'm just not en vogue enough.

Dirk

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]] 
Sent: 25 February 2022 01:53
To: Geoff Huston <[email-masked]>; David R. Oran <[email-masked]>
Cc: [email-masked]; Dirk Trossen <[email-masked]>
Subject: Re: [arch-d] [icnrg] recasting address semantics

> It's pretty clear where the money is these days, and it's not in the lower layers of the protocol stack.

... with the exception of the physical layer. For example, people are paying good money to get their phone connected to a wireless network, and wireless companies would not try overbid each other to buy frequencies if the business was not profitable.

-- Christian Huitema

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 25 Feb 2022 09:18:44 +0100

On Thu, Feb 24, 2022 at 04:53:14PM -0800, Christian Huitema wrote:
> ... with the exception of the physical layer. For example, people are paying
> good money to get their phone connected to a wireless network, and wireless
> companies would not try overbid each other to buy frequencies if the
> business was not profitable.
> 
> -- Christian Huitema

And how much are IPv4 addresses selling for these days ?

And why do we have multiple working groups to innovate routing for DC networks ?
Because thats where the people with the money actually do invest into as they
own it and see it as a strong competitive advantage if they manage to get more
out of it through better technology.

The money is where the people who make it must or want to put it. Arguably
the folks who make the money feel more comfortable to build their solutions at
application layer as much aspossible, and they also go to IETF to push against
innvation in the wide-area network layer functionality because they want it
purely as a commodity.

We IMHO primarily have a problem because the Internet Architecture was never
designed to be a money sucking machinery like todays winning OTT platforms are.

So we should also not judge it on pure commercial comparison. We just have to
be cognicant that we can not simply hope that drivers for new technologies
in the Internet Architecture will be those players that at best want it as a
commodity. But that should not stop us to innovate on it.

Cheers
    Toerless

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 25 Feb 2022 08:34:54 +0000

[SNIP - not to judge your observations negatively but merely agreeing with them at large] 

[DOT] we are coming to the crux here, namely should activities on routing innovation happen or not and, also, how should the IETF support such activities. It is one aspect that ANY innovation is judged ultimately by the market and I cannot and do not disagree with it. But the question here is whether activities on routing (whether 'semantic routing' or others) should be (mainly/purely?) judged by current economic conditions or should be fostered in the spirit of what you call a 'deregulated nature of the activity', i.e. enabling the possibility to form those stable and viable niches in the market (which themselves may grow or disappear altogether).

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 25 Feb 2022 10:31:07 +0100

> I also don’t have much optimism about the prospects for “semantic routing”, but I am pretty sure that what will determine the fate of this and similar efforts is simply whether it achieves a stable…

Lets not forget that the term "semantic routing" is primarily an attempt
to overcome useless procedural hurdles put up against the desire to bring back 
routing research into the IETF. And that is putting what i think we
have experienced over the past years very mildly. And i think the IETF
should be ashamed of itself.

I think we have shown ample of evidence that there is a lot of good
routing research out there through various side meetings, but obviously
such series of one-off meetings without any IETF endorsement or
communications forum like an IRTF mailing list is no basis from which the
IETF can attract a better ongoing basis of collaboration about routing
research with the research community.

An actual routing research group could and would do that. But it would 
take time to have more researchers learn how their work could profit
from such a research group. Such as using it as a basis for discussing,
exploring, collecting information from the technology experts in the
IETF, getting ideas about what routing research ideas would have real
interest from the industry and so on. And it takes time to build such
a community, because evenin research it is widely scattered and it will
take time to go out to research conferences and educate reserchers
about thesenew opportunities with the IETF.

The NMRG chairs for example are great in doing that for network management.
And NMRG is similarily open ended in its scope as we IMHO need an open
ended routing research group. So why can we have it in network management,
but not in routing ? I never get answers to those fundamental questions
from IETF leadership.

In other areas of the IETF, we have also shown that we can attract
communities that have escaped us, with efforts such as iotops or mops. But in both
cases we had IETF leadership actively pushing for these rather
untypical groups. In the case of the IRTF we have the opposite push.

Maybe we should simply do some doodle poll asking the IETF community if
it wants / would support an routing research group.

Oh, and i think "routing semantics" is a great new field for taxonomy
and construction and analysis of common mechanisms to serve a broader
 set of use-cases (semantics). Heck, we have never even managed to
find a common framework around unicast and anycast and variations
thereof, and we repeatedly get someone trying to open that
can of worms with badly informed protocol proposals.

This would be an example similarily good research work as the ongoing
taxonomy/methodology work on "intent" going on in NMRG. Which 
also was a work item that could only evolve because NMRG wasn't
given IRTF process hazing.

Cheers
    Toerless

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 25 Feb 2022 11:27:16 +0100

Hi Toerless, All,

> On 25 Feb 2022, at 10:31, Toerless Eckert <[email-masked]> wrote:
> 

A few people felt that would be good to transform those side meetings in a recurrent event, realizing and agreeing that (weirdly enough) routing research has not a dedicated home in the IETF/IRTF.

This has been captured in the addressing manifesto document: https://datatracker.ietf.org/doc/draft-iannone-routing-and-addressing-manifesto/ <https://datatracker.ietf.org/doc/draft-iannone-routing-and-addressing-manifesto/>

The document also point to a etherpad where people can support explicitly the idea contained in the document:
https://etherpad.wikimedia.org/p/routing.addressing.manifesto <https://etherpad.wikimedia.org/p/routing.addressing.manifesto>

There are a few of us support the idea to have a routing and addressing regular event.
I miss your name there ;-)

> about thesenew opportunities with the IETF.

This is exactly the point  I was trying to make for years.
Because there is no dedicate home to routing in the IETF/IRTF, researchers working in the field do not come to us.
What we need is to make the effort to go out there and reach out for those researchers.
Work to create a communication channel that allows us to attract researchers to be willing to expose their research to us.
Making a proactive work to look for interesting stuff.
Also, in a post pandemic life the IETF will again have physical meeting in various parts of the world. It would be nice to look in the local academic world to invite researchers to present their work.
I have quite few ideas long these lines…  ;-)    

> but not in routing ? I never get answers to those fundamental questions

I would add MAPRG. They have a nice format. There are very interesting talks.

Ciao

L.

> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Feb 2022 10:45:51 -0000

This thread seems to have wandered around a bit: arch-discuss, ICNRG, RTGWG.
And yet, we're told that the home for discussing "semantic routing" is COINRG.

Anyway, since I coined the term "semantic routing" in this incarnation, perhaps I should comment?

I'm a little disturbed by the engineering interpretation of "semantic routing" like it has been proposed as a solution for a specific problem (or worse, a solution in search of a problem). Far from it! This work originates from observing that there are already very many schemes proposed, researched, and deployed that enable routing and forwarding based on more than the destination address, and more than the classic 5-tuple. We started to collect these schemes in draft-king-irtf-semantic-routing-survey although we got a little dispirited when we found out exactly how many such schemes there are.

Our next observation was that most of these approaches assumed deployment in some form of "limited domain". This limitation ranged from regular routing domains (areas/levels or ASes) to specific technology or use case environments. This meant that many different schemes were being proposed/developed with no consideration of interoperability and no thought to general applicability.

Of course, we have a proud history of developing routing systems for specific environments or use cases. Likewise encapsulations. But many of these ways of enabling semantic routing are placing new information in existing IP header fields (addresses, Flow Label, Traffic Class, ...), introducing new header fields (mainly as Extension Headers), or proposing new encapsulations. I was most concerned about the "overloading" (or meaning change) of existing fields, because this seemed often to not consider what happens if a packet "escapes" the limited domain, when domains are merged, or when traffic has to transit multiple domains. So we started work on draft-king-irtf-challenges-in-routing as a way of capturing the things people should think about when proposing new semantic routing schemes. This rapidly grew into considerations for all new routing research as we have observed that routing research often experiments with very simplistic topologies and is rarely independently verifiable.

As we started to talk about these two drafts, people kept asking "Yes, but what do you mean by Semantic Routing?" So we produced draft-farrel-irtf-introduction-to-semantic-routing to describe the sort of schemes we are looking at. Sadly, many have assumed that this document is a proposal to build a specific solution rather than a scoping of the problem space. Of course, it would be good to move on from this introduction to see whether an abstract definition and architecture of "semantic routing" can be produced, and that might lead on to research into a more generic solution (which can be seen impinging on IETF discussions, such as APN).

Further discussions in the COIN context (especially with regard to seeing how Semantic Routing might be in scope for COIN) led us to consider network programmability and network compute. The first of these clearly splits into programming of devices, and programming of the whole network: draft-boucadair-irtf-sdn-and-semantic-routing starts to collect thoughts on this. The second consideration needs further thought, but topics might include how to install different routing or forwarding algorithms on network devices.

(Ideas of "Active Networking," with micro-programs embedded in the header fields of packets, are not in scope for *our* discussion of Semantic Routing.)

Why is this all relevant to this thread on "recasting address semantics"? Well, many existing Semantic Routing schemes rely on placing additional meaning on the IPv6 destination address. These approaches may be "safe" because they only play with the low-order bits of an address that are (probably) not used by existing routers for routing purposes. Others may be less easily integrated into existing routing systems with the result that we are looking at network-wide upgrades within out limited domains, significant risks resulting from leakage, and gateways needed at the domain borders.

And, finally, it was at the recent COIN interim that "all routing is semantic routing." To some extent that is true, but it would be better to say "we have always supplemented routing on the destination address with routing on other fields in order to achieve service differentiation." What we are seeing now, however, is all sorts of different niche requirements to provide enhanced service differentiation in the network (enhanced VPNs, network slicing, latency aware routing, energy-aware routing, ...) with no coordination, no big picture, and no consideration of the impact on the stability and utility of the integrated whole.

So, I think 
> The more I read about the “semantic routing” work the more pessimistic
> I am that it will lead anywhere useful.
Indicates a failure to understand what is being talked about.

Cheers,
Adrian

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Fri, 25 Feb 2022 02:51:24 -0800

Toerless and all:

Semantic routing was heavily discussed on the COIN mailing list, given a
major spot in our interim and offered to be part of a research into what
routing becomes or how it evolves when nodes offer processing not just
forwarding.

Of course you will argue this is not a “routing group” but it is
highlighting/promoting the research activities in an IRTF forum.

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

From: Toerless Eckert <[email-masked]> <[email-masked]>
Reply: Toerless Eckert <[email-masked]> <[email-masked]>
Date: February 25, 2022 at 4:31:37 AM
To: Dirk Trossen <dirk.trossen=[email-masked]>
<dirk.trossen=[email-masked]>
Cc: [email-masked] <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]>
<[email-masked]>
Subject:  [arch-d] Routing research group (was: Re: [icnrg] recasting
address semantics)

> > The more I read about the “semantic routing” work the more pessimistic
I am that it will lead anywhere useful. Perhaps you will prove me wrong in
the end.
>
> I also don’t have much optimism about the prospects for “semantic
routing”, but I am pretty sure that what will determine the fate of this
and similar efforts is simply whether it achieves a stable and viable niche
in the market space that collectively we call “the Internet”. i.e. the
determination of success or otherwise these days is ultimately based on the
deregulated market.

to overcome useless procedural hurdles put up against the desire to bring
back

In other areas of the IETF, we have also shown that we can attract
communities that have escaped us, with efforts such as iotops or mops. But
in both
cases we had IETF leadership actively pushing for these rather
untypical groups. In the case of the IRTF we have the opposite push.

Cheers
Toerless

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Feb 2022 11:00:08 -0000

Good conversation Luigi and Toerless.

I “coordinated” three side meetings (IETF-111, interim between 111 and 112, IETF-112) loosely under the umbrella of “Semantic Routing” but what we were actually doing was highlighting some important/interesting recent research that we came across while researching Semantic Routing. We felt that the IETF routing community would be interested in and benefit from a chance to hear the researchers speak and to discuss their work. 

Since those meetings were not compulsory and involved people investing time to attend, we took attendance figures of more than 100 at each meeting to mean that they were of interest.

I would be happy to continue to organise such meetings under whatever auspices, but we got the very distinct impression that organising research-oriented side meetings was heavily frowned upon by the I* “management”. That may be a false impression, in which case I apologise. 

But it’s hard, isn’t it? Where do we talk about routing research? Semantic Routing has been directed to the COIN RG as it has “considerable overlap”. RTGWG has always been welcoming, but (of course) it also has engineering work to do. The Routing Area meeting and the Routing-Discussion mailing list have some space, but they are mainly concerned with coordinating the work of the Routing Area.

So, while I am not a great signer of petitions (I am old and jaundiced and no longer go on demonstrations, either), I sympathise with Luigi’s “manifesto”. The IETF/IRTF needs a place to talk about the future of routing.

Regards,

Adrian

From: Architecture-discuss <[email-masked]> On Behalf Of Luigi Iannone
Sent: 25 February 2022 10:27
To: Toerless Eckert <[email-masked]>
Cc: [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]>; [email-masked]
Subject: Re: [arch-d] Routing research group (was: Re: [icnrg] recasting address semantics)

Hi Toerless, All,

On 25 Feb 2022, at 10:31, Toerless Eckert <[email-masked] <mailto:[email-masked]> > wrote:

This has been captured in the addressing manifesto document: https://datatracker.ietf.org/doc/draft-iannone-routing-and-addressing-manifesto/

https://etherpad.wikimedia.org/p/routing.addressing.manifesto

 

 

Ciao

L.

Cheers
   Toerless

_______________________________________________
Architecture-discuss mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: Colin Perkins <[email-masked]>
Date: Fri, 25 Feb 2022 11:14:45 +0000

Adrian, all,

You may, of course, organise whatever side meetings you want.

The feedback I gave, and the feedback I have given to the other people proposing similar work, was that to the extent there was research being proposed, rather than engineering, it overlapped substantially in scope with COINRG. As such, we have an existing IRTF venue for the work.

Colin

> On 25 Feb 2022, at 11:00, Adrian Farrel <[email-masked]> wrote:
> 
> From: Architecture-discuss <[email-masked] <mailto:[email-masked]>> On Behalf Of Luigi Iannone
> To: Toerless Eckert <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Dirk Trossen <dirk.trossen=[email-masked] <mailto:dirk.trossen=[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> On 25 Feb 2022, at 10:31, Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> https://www.ietf.org/mailman/listinfo/architecture-discuss <https://www.ietf.org/mailman/listinfo/architecture-discuss>
>  
> https://www.ietf.org/mailman/listinfo/architecture-discuss <https://www.ietf.org/mailman/listinfo/architecture-discuss>

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 25 Feb 2022 13:10:07 +0100

Hi Colin

> On 25 Feb 2022, at 12:14, Colin Perkins <[email-masked]> wrote:
> 
> Adrian, all,
> 
> The feedback I gave, and the feedback I have given to the other people proposing similar work, was that to the extent there was research being proposed, rather than engineering, it overlapped substantially in scope with COINRG.

There is certainly overlap and routing research might be presented in COINRG.
However, this is one side of the “coin”. 

In the draft and in my previous email I shared my opinion that we should do more in terms of outreach. 
Being more proactive in bringing people that are not necessarily in the orbit of the IETF/IRTF to present their work to us.
What can we do to improve this aspect?

Ciao

L.

> As such, we have an existing IRTF venue for the work.
> 
> Colin
> 
> 
> 
>> On 25 Feb 2022, at 11:00, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Fri, 25 Feb 2022 04:15:08 -0800

We also have discussed how to attract more people to the IETF and IRTF. I
would say there is no “global answer” but I think the answer is that WE
have to be proactive. Having a new WG or RG is not going to get anyone in.
We can take that discussion off thread.

mjm

From: Luigi Iannone <[email-masked]> <[email-masked]>
Reply: Luigi Iannone <[email-masked]> <[email-masked]>
Date: February 25, 2022 at 7:10:36 AM
To: Colin Perkins <[email-masked]> <[email-masked]>
Cc: Toerless Eckert <[email-masked]> <[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>, Dirk Trossen
<dirk.trossen=[email-masked]>
<dirk.trossen=[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>
Subject:  Re: [arch-d] Routing research group (was: Re: [icnrg] recasting
address semantics)

Hi Colin

Adrian, all,

The feedback I gave, and the feedback I have given to the other people
proposing similar work, was that to the extent there was research being
proposed, rather than engineering, it overlapped substantially in scope
with COINRG.

There is certainly overlap and routing research might be presented in
COINRG.
However, this is one side of the “coin”.

In the draft and in my previous email I shared my opinion that we should do
more in terms of outreach.
Being more proactive in bringing people that are not necessarily in the
orbit of the IETF/IRTF to present their work to us.
What can we do to improve this aspect?

Ciao

L.

Colin

I “coordinated” three side meetings (IETF-111, interim between 111 and 112,
IETF-112) loosely under the umbrella of “Semantic Routing” but what we were
actually doing was highlighting some important/interesting recent research
that we came across while researching Semantic Routing. We felt that the
IETF routing community would be interested in and benefit from a chance to
hear the researchers speak and to discuss their work.

Since those meetings were not compulsory and involved people investing time
to attend, we took attendance figures of more than 100 at each meeting to
mean that they were of interest.

I would be happy to continue to organise such meetings under whatever
auspices, but we got the very distinct impression that organising
research-oriented side meetings was heavily frowned upon by the I*
“management”. That may be a false impression, in which case I apologise.

But it’s hard, isn’t it? Where do we talk about routing research? Semantic
Routing has been directed to the COIN RG as it has “considerable overlap”.
RTGWG has always been welcoming, but (of course) it also has engineering
work to do. The Routing Area meeting and the Routing-Discussion mailing
list have some space, but they are mainly concerned with coordinating the
work of the Routing Area.

So, while I am not a great signer of petitions (I am old and jaundiced and
no longer go on demonstrations, either), I sympathise with Luigi’s
“manifesto”. The IETF/IRTF needs a place to talk about the future of
routing.

Regards,
Adrian

*From:* Architecture-discuss <[email-masked]> *On
Behalf Of *Luigi Iannone
*Sent:* 25 February 2022 10:27
*To:* Toerless Eckert <[email-masked]>
*Cc:* [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]
>; [email-masked]
*Subject:* Re: [arch-d] Routing research group (was: Re: [icnrg] recasting
address semantics)

Hi Toerless, All,

The more I read about the “semantic routing” work the more pessimistic I am
that it will lead anywhere useful. Perhaps you will prove me wrong in the
end.

I also don’t have much optimism about the prospects for “semantic routing”,
but I am pretty sure that what will determine the fate of this and similar
efforts is simply whether it achieves a stable and viable niche in the
market space that collectively we call “the Internet”. i.e. the
determination of success or otherwise these days is ultimately based on the
deregulated market.

A few people felt that would be good to transform those side meetings in
a recurrent event, realizing and agreeing that (weirdly enough) routing
research has not a dedicated home in the IETF/IRTF.

This has been captured in the addressing manifesto document:
https://datatracker.ietf.org/doc/draft-iannone-routing-and-addressing-manifesto/

The document also point to a etherpad where people can support explicitly
the idea contained in the document:
https://etherpad.wikimedia.org/p/routing.addressing.manifesto

There are a few of us support the idea to have a routing and addressing
regular event.
I miss your name there ;-)

This is exactly the point  I was trying to make for years.
Because there is no dedicate home to routing in the IETF/IRTF, researchers
working in the field do not come to us.
What we need is to make the effort to go out there and reach out for those
researchers.
Work to create a communication channel that allows us to attract
researchers to be willing to expose their research to us.
Making a proactive work to look for interesting stuff.
Also, in a post pandemic life the IETF will again have physical meeting in
various parts of the world. It would be nice to look in the local academic
world to invite researchers to present their work.
I have quite few ideas long these lines…  ;-)

I would add MAPRG. They have a nice format. There are very interesting
talks.

Ciao

L.

Cheers
   Toerless

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 25 Feb 2022 15:07:20 +0100

Hi,

> On 25 Feb 2022, at 13:15, Marie-Jose Montpetit <[email-masked]> wrote:
> 
> We also have discussed how to attract more people to the IETF and IRTF. I would say there is no “global answer” but I think the answer is that WE have to be proactive.
For my understanding: who is “WE”? The COINRG chairs or the community?
In the latter case I am willing to help (see below)

> Having a new WG or RG is not going to get anyone in.
Indeed my question was about how can we improve the outreach. 

> We can take that discussion off thread.
I think is something to discuss in COINRG.
Being proactive is OK, but we should converge on concrete steps forward so that we all can help.

Ciao

L.

> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> From: Luigi Iannone <[email-masked]> <mailto:[email-masked]>
> Reply: Luigi Iannone <[email-masked]> <mailto:[email-masked]>
> To: Colin Perkins <[email-masked]> <mailto:[email-masked]>
> Cc: Toerless Eckert <[email-masked]> <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>, Dirk Trossen <dirk.trossen=[email-masked]> <mailto:dirk.trossen=[email-masked]>, [email-masked] <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>>> On 25 Feb 2022, at 12:14, Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Adrian, all,
>>>

---

From: Andrew Campling <[email-masked]>
Date: Fri, 25 Feb 2022 15:32:31 +0000

Expanding the diversity of the IETF community is part of the Emodir (Education, Mentoring & Outreach Directorate) charter – see https://datatracker.ietf.org/group/emodir/about/.  We’re currently finalising the workplan for the year and it would be great to have the additional insights (and involvement!) of members of this list that are not currently engaged with the Emodir wg.

Andrew

From: Luigi Iannone <[email-masked]>
Sent: 25 February 2022 14:07
To: Marie-Jose Montpetit <[email-masked]>
Cc: Colin Perkins <[email-masked]>; Dirk Trossen <dirk.trossen=[email-masked]>; [email-masked]; Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [arch-d] Routing research group (was: Re: [icnrg] recasting address semantics)

Hi,

On 25 Feb 2022, at 13:15, Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>> wrote:

Ciao

L.

mjm

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

From: Luigi Iannone <[email-masked]><mailto:[email-masked]>
Reply: Luigi Iannone <[email-masked]><mailto:[email-masked]>
Date: February 25, 2022 at 7:10:36 AM
To: Colin Perkins <[email-masked]><mailto:[email-masked]>
Cc: Toerless Eckert <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Dirk Trossen <dirk.trossen=[email-masked]><mailto:dirk.trossen=[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject:  Re: [arch-d] Routing research group (was: Re: [icnrg] recasting address semantics)

Hi Colin

On 25 Feb 2022, at 12:14, Colin Perkins <[email-masked]<mailto:[email-masked]>> wrote:

Adrian, all,

Ciao

L.

Colin

On 25 Feb 2022, at 11:00, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Adrian

From: Architecture-discuss <[email-masked]<mailto:[email-masked]>> On Behalf Of Luigi Iannone
Sent: 25 February 2022 10:27
To: Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Dirk Trossen <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [arch-d] Routing research group (was: Re: [icnrg] recasting address semantics)

Hi Toerless, All,

On 25 Feb 2022, at 10:31, Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:

Ciao

L.

Cheers
   Toerless

_______________________________________________
Architecture-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Feb 2022 10:42:29 -0500

But almost all of that spending of yours is for the local (access)
component, i.e., where "fancy" routing matters little.

Also, you pay for OTT, just differently: The average revenue per user for
Facebook alone, in the US, is $46/quarter or $15 per month, paid for your
product purchases via advertising. Digital ad spending in the US is $183B
(2021), i.e., about $1,400 per household per year (there are about 130
million households in the US). That's probably more than you spend on home
broadband. You are just spending it when you buy a car or toothpaste.

On Fri, Feb 25, 2022 at 3:15 AM Dirk Trossen <dirk.trossen=
[email-masked]> wrote:

> ...my household bill for access is certainly much higher than my internet
> service bill (OTT video, streaming audio, ...) but maybe I'm just not en
> vogue enough.
>
> Dirk
>
> paying good money to get their phone connected to a wireless network, and
> wireless companies would not try overbid each other to buy frequencies if
> the business was not profitable.
>
> -- Christian Huitema
>

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 25 Feb 2022 16:06:28 +0000

But almost all of that spending of yours is for the local (access) component, i.e., where "fancy" routing matters little.
[DOT] I disagree. I pay for Internet access, where “fancy” routing matters precisely in order to get to what I decide to get to. I do not pay for local access to a PoP only, sorry. For that reason, my ISP needs to collaborate within the multi-stakeholder environment that ensures that my packet makes it where I want it to go; it needs to realize “fancy routing” or at least collaborate with those ensuring such “fancy routing”. Maybe some people may see the meaning of “Internet access” as being limited to merely getting to the local PoP; but that is apparently only true for 70 to 90% of customer traffic. So again, I spend my money on having Internet access, all else would greatly change what my contract says.

[DOT] Let me put it that way, paraphrasing Geoff “death of transit”: let’s switch off transit and wait for customers to complain that their ‘local access’ is not doing what they expect it to do, namely ensuring the enjoyment of internet services beyond the local access (and its PoPs).

Also, you pay for OTT, just differently: The average revenue per user for Facebook alone, in the US, is $46/quarter or $15 per month, paid for your product purchases via advertising. Digital ad spending in the US is $183B (2021), i.e., about $1,400 per household per year (there are about 130 million households in the US). That's probably more than you spend on home broadband. You are just spending it when you buy a car or toothpaste.
[DOT] I do understand that somebody is attaching value to my presence in and usage of the Internet; that is the same as visiting a physical store; like in all examples of me participating in more complex value chains. I would argue, however, that most people have no idea of this ‘spending’ interpretation of yours since, well, they are not spending this money. Instead, the expectation of the end user is primarily to get what they directly pay for, and that’s Internet access. Together with RFC8890, I believe that this should be reflected in the solutions we build.

On Fri, Feb 25, 2022 at 3:15 AM Dirk Trossen <dirk.trossen=[email-masked]<mailto:[email-masked]>> wrote:
...my household bill for access is certainly much higher than my internet service bill (OTT video, streaming audio, ...) but maybe I'm just not en vogue enough.

Dirk

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 25 February 2022 01:53
To: Geoff Huston <[email-masked]<mailto:[email-masked]>>; David R. Oran <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Dirk Trossen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [arch-d] [icnrg] recasting address semantics

-- Christian Huitema

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 25 Feb 2022 11:41:09 -0500

On 25 Feb 2022, at 11:06, Dirk Trossen wrote:

> [DOT] I disagree. I pay for Internet access, where “fancy” routing 
> matters precisely in order to get to what I decide to get to. I do not 
> pay for local access to a PoP only, sorry. For that reason, my ISP 
> needs to collaborate within the multi-stakeholder environment that 
> ensures that my packet makes it where I want it to go; it needs to 
> realize “fancy routing” or at least collaborate with those 
> ensuring such “fancy routing”. Maybe some people may see the 
> meaning of “Internet access” as being limited to merely getting to 
> the local PoP; but that is apparently only true for 70 to 90% of 
> customer traffic. So again, I spend my money on having Internet 
> access, all else would greatly change what my contract says.
This is a very good point at least in principle.

However, I can’t think of a single successful instance of an access 
ISP offering anything remotely resembling fancy routing, despite 
attempts by both consumers and the ISPs themselves to offer such:
- they universally stomp on DSCP bits, not just ignore them so somebody 
upstream can make use of them for fancy routing. The one exception I 
know of is EF setting for a cable operator’s captive VoIP service, but 
even in this case it’s not common; rather the cable operator puts 
their VoIP on a separate L2 SID rather than doing fancy routing/handling 
of general internet traffic.
- the cableco’s spent considerable time and energy to define 
“Packetcable Multimedia” which allowed various services to define 
policy routing and queuing, using signaling protocols like COPs to 
distribute the policy state to the routers, which could then use various 
routing & queueing techniques to meet the policy as a PEP. Was deployed 
a tiny bit in the early 2000’s but pulled out as too complicated and 
expensive compared to just offering more bandwidth.
- business internet services by some ISPs like AT&T do provide somewhat 
fancy routing, but I’m pretty sure this is done with MPLS traffic 
engineering, not IP routing. Recent attempts to push this up to L3 have 
not (so far) gotten much if any deployment traction (e.g. segment 
routing).
- other business internet services, such as those provided by cable 
companies, provide SLAs but in fact don’t actually affect the deployed 
L3 (or L2 other than sometimes separate SIDs). These SLAs seem to be 
strictly a contractual vehicle where it appears universally cheaper to 
give penalty payments than to actually deploy technology to meet the 
SLAs when the network is overloaded or otherwise degraded.

> [DOT] Let me put it that way, paraphrasing Geoff “death of 
> transit”: let’s switch off transit and wait for customers to 
> complain that their ‘local access’ is not doing what they expect 
> it to do, namely ensuring the enjoyment of internet services beyond 
> the local access (and its PoPs).
>
Ten, or even five years ago lots of things would have broken.
Today I’m not so sure.
Other than some rural or under-served areas, the access ISP can through 
their native facilities get traffic to a metro POP or quite likely a 
metro IXP where the vast majority of Internet services (web proxies, 
streaming, email, VoIP, notifications, etc. etc.) have an off-ramp to 
the providers of the service (Akamai, Google, Microsoft, Netflix, etc. 
etc.). I’d be surprised if much (or any!) user-initiated traffic 
actually traverses a transit. Transit providers are still in the mix, 
but their big business i suspect is by leasing lambdas on their 
in-ground fiber to the big guys. Transit Internet traffic through 
peering seems to not be growing, and might even be declining (though I 
only have anecdotes, not data, on this - Geoff might know more).

One major exception might be international/intercontinental traffic on 
routes that are not economical for the big guys to install or lease 
fiber. On the other hand this does not seem to be a likely success 
target for fancy  routing, as it’s hard enough to just keep BGP 
running.

> Also, you pay for OTT, just differently: The average revenue per user 
> for Facebook alone, in the US, is $46/quarter or $15 per month, paid 
> for your product purchases via advertising. Digital ad spending in the 
> US is $183B (2021), i.e., about $1,400 per household per year (there 
> are about 130 million households in the US). That's probably more than 
> you spend on home broadband. You are just spending it when you buy a 
> car or toothpaste.
> [DOT] I do understand that somebody is attaching value to my presence 
> in and usage of the Internet; that is the same as visiting a physical 
> store; like in all examples of me participating in more complex value 
> chains. I would argue, however, that most people have no idea of this 
> ‘spending’ interpretation of yours since, well, they are not 
> spending this money. Instead, the expectation of the end user is 
> primarily to get what they directly pay for, and that’s Internet 
> access. Together with RFC8890, I believe that this should be reflected 
> in the solutions we build.
>
> On Fri, Feb 25, 2022 at 3:15 AM Dirk Trossen 
> <dirk.trossen=[email-masked]<mailto:[email-masked]>> 
> wrote:
> ...my household bill for access is certainly much higher than my 
> internet service bill (OTT video, streaming audio, ...) but maybe I'm 
> just not en vogue enough.
>
> Dirk
>
> From: Christian Huitema 
> [mailto:[email-masked]<mailto:[email-masked]> ]
> To: Geoff Huston <[email-masked]<mailto:[email-masked]>> ; David R. Oran 
> <[email-masked]<mailto:[email-masked]>>
> Cc: 
> [email-masked]<mailto:[email-masked]> ; 
> Dirk Trossen <[email-masked]<mailto:[email-masked]>>

DaveO

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 25 Feb 2022 16:56:16 +0000

Please see inline.

From: David R. Oran [mailto:[email-masked]]
Sent: 25 February 2022 17:41
To: Dirk Trossen <[email-masked]>
Cc: Henning Schulzrinne <[email-masked]>; Christian Huitema <[email-masked]>; Geoff Huston <[email-masked]>; [email-masked]
Subject: Re: [arch-d] [icnrg] recasting address semantics

However, I can’t think of a single successful instance of an access ISP offering anything remotely resembling fancy routing, despite attempts by both consumers and the ISPs themselves to offer such:

  *   they universally stomp on DSCP bits, not just ignore them so somebody upstream can make use of them for fancy routing. The one exception I know of is EF setting for a cable operator’s captive VoIP service, but even in this case it’s not common; rather the cable operator puts their VoIP on a separate L2 SID rather than doing fancy routing/handling of general internet traffic.
  *   the cableco’s spent considerable time and energy to define “Packetcable Multimedia” which allowed various services to define policy routing and queuing, using signaling protocols like COPs to distribute the policy state to the routers, which could then use various routing & queueing techniques to meet the policy as a PEP. Was deployed a tiny bit in the early 2000’s but pulled out as too complicated and expensive compared to just offering more bandwidth.
  *   business internet services by some ISPs like AT&T do provide somewhat fancy routing, but I’m pretty sure this is done with MPLS traffic engineering, not IP routing. Recent attempts to push this up to L3 have not (so far) gotten much if any deployment traction (e.g. segment routing).
  *   other business internet services, such as those provided by cable companies, provide SLAs but in fact don’t actually affect the deployed L3 (or L2 other than sometimes separate SIDs). These SLAs seem to be strictly a contractual vehicle where it appears universally cheaper to give penalty payments than to actually deploy technology to meet the SLAs when the network is overloaded or otherwise degraded.
[DOT] The choice of wording (not mine, BTW) was placed in quotation marks since the degree of ‘fancy’ is indeed often wishful.

Ten, or even five years ago lots of things would have broken.
Today I’m not so sure.
Other than some rural or under-served areas, the access ISP can through their native facilities get traffic to a metro POP or quite likely a metro IXP where the vast majority of Internet services (web proxies, streaming, email, VoIP, notifications, etc. etc.) have an off-ramp to the providers of the service (Akamai, Google, Microsoft, Netflix, etc. etc.). I’d be surprised if much (or any!) user-initiated traffic actually traverses a transit. Transit providers are still in the mix, but their big business i suspect is by leasing lambdas on their in-ground fiber to the big guys. Transit Internet traffic through peering seems to not be growing, and might even be declining (though I only have anecdotes, not data, on this - Geoff might know more).

[DOT] Hmm, so those 10 to 30% of non-local traffic are closer to zero; is that your point? Or in other words, close to 95 or even 99% is purely local traffic? I have not seen those statistics but would love to?

One major exception might be international/intercontinental traffic on routes that are not economical for the big guys to install or lease fiber. On the other hand this does not seem to be a likely success target for fancy routing, as it’s hard enough to just keep BGP running.

[DOT] Good, then let’s do the experiment. Cap the lines, apart from the ‘big guys’ shuffling data into and among PoPs and let’s see and wait (for the complaints). Of course, the success (or failure) of that experiment very much depends on the serendipity of the service you may want and whether or not the access ISP is indeed able to get “through their native facilities […] traffic to a metro POP or quite likely a metro IXP where the vast majority of Internet services (web proxies, streaming, email, VoIP, notifications, etc. etc.) have an off-ramp to the providers of the service (Akamai, Google, Microsoft, Netflix, etc. etc.).” Of course, if it IS some Google, MS, Netflix, similar etc service, I have no doubt for this to work. But what if not? Do we want to start telling people what URL they should put into the browser bar, just NOT to need transit?

Dirk

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]<mailto:[email-masked]> ]
Sent: 25 February 2022 01:53
To: Geoff Huston <[email-masked]<mailto:[email-masked]>> ; David R. Oran <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> ; Dirk Trossen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [arch-d] [icnrg] recasting address semantics

-- Christian Huitema

DaveO

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Feb 2022 08:34:51 +1300

Here's a slightly more general question. There's *another* research community in our space, i.e. the SIGCOMM community. Some people on this thread 
flirt with all of the IETF, the IRTF and SIGCOMM.

Is there a gap between SIGCOMM and the IRTF/IETF? Is there an overlap? Should there be an explicit discussion of that topic to see if the gap/overlap needs active attention or joint action?

Clearly routing is not the only area of mutual interest, but it's one of the important ones.

Regards
    Brian Carpenter

On 26-Feb-22 01:15, Marie-Jose Montpetit wrote:
> We also have discussed how to attract more people to the IETF and IRTF. 
I would say there is no “global answer” but I think the answer is that WE have to be proactive. Having a new WG or RG is not going 
to get anyone in. We can take that discussion off thread.
>>> The feedback I gave, and the feedback I have given to the other people proposing similar work, was that to the extent there was research being 
proposed, rather than engineering, it overlapped substantially in scope with COINRG. 
>>>> I “coordinated” three side meetings (IETF-111, interim between 111 and 112, IETF-112) loosely under the umbrella of “Semantic Routing” but what we were actually doing was highlighting some important/interesting recent research that we came across while researching Semantic Routing. We felt that the IETF routing community would 
be interested in and benefit from a chance to hear the researchers speak and to discuss their work.
>>>> But it’s hard, isn’t it? Where do we talk about routing research? Semantic Routing has been directed to the COIN RG as it has 
“considerable overlap”. RTGWG has always been welcoming, but (of course) it also has engineering work to do. The Routing Area meeting and the Routing-Discussion mailing list have some space, but they are 
mainly concerned with coordinating the work of the Routing Area.
>>>> *From:*Architecture-discuss <[email-masked] <mailto:[email-masked]>>*On Behalf Of*Luigi Iannone
>>>> *Sent:*25 February 2022 10:27
>>>> *To:*Toerless Eckert <[email-masked] <mailto:[email-masked]>>
>>>> *Cc:[email-masked] <mailto:[email-masked]>; Dirk Trossen <dirk.trossen=[email-masked] <mailto:dirk.trossen=[email-masked]>>;[email-masked] <mailto:[email-masked]>
>>>> *Subject:*Re: [arch-d] Routing research group (was: Re: [icnrg] recasting address semantics)
>>>> Hi Toerless, All,
>>>>
>>>>>>> The more I read about the “semantic routing” work 
the more pessimistic I am that it will lead anywhere useful. Perhaps you will prove me wrong in the end.
>>>> This has been captured in the addressing manifesto document:https://datatracker.ietf.org/doc/draft-iannone-routing-and-addressing-manifesto/ <https://datatracker.ietf.org/doc/draft-iannone-routing-and-addressing-manifesto/>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Feb 2022 09:04:55 +1300

On 26-Feb-22 05:41, David R. Oran wrote:
...
  
>   * they universally stomp on DSCP bits, not just ignore them so somebody upstream can make use of them for fancy routing.

In the earliest days of diffserv (e.g. at the interim WG meeting in May 1998 in Cambridge, MA) the major ISPs involved insisted very strongly that 
DSCP behaviours had to be domain-specific by construction and of local significance only. So what you describe is not an accident; it was completely intended to work that way and has always been part of ISP thinking. This was a big surprise to host vendors, who had assumed that diffserv would be end-to-end across the Internet.

Moral of the story: sometimes it pays to listen to what people say.

    Brian

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 25 Feb 2022 15:59:16 -0500

___________________________
iDevice - please excuse typos.

> On Feb 25, 2022, at 3:05 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> In the earliest days of diffserv (e.g. at the interim WG meeting in May 1998 in Cambridge, MA) the major ISPs involved insisted very strongly that DSCP behaviours had to be domain-specific by construction and of local significance only. So what you describe is not an accident; it was completely intended to work that way and has always been part of ISP thinking. This was a big surprise to host vendors, who had assumed that diffserv would be end-to-end across the Internet.
> 
Fair enough. I’d forgotten that. To the general point, the access ISPs didn’t/don’t use DSCPs for routing on their networks. I doubt any metro or transit ISPs do either.

> Moral of the story: sometimes it pays to listen to what people say.
Yes, though the old saw about Henry Ford also applies at times.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 25 Feb 2022 15:24:31 -0800

> [DOT] Time will tell although, related to this discussion, this wasn’t about semantic routing. As you know, I’ve been active in L3 innovation for some time, including ICN, and its lack of traction…

ICN is a good idea. But if a new technology runs best when every node in the network has to implement it, then its going to take decades to deploy, and will fail because of this reason. It says nothing about the quality of the idea, design, or architecture.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 25 Feb 2022 15:27:34 -0800

> [DOT] we are coming to the crux here, namely should activities on routing innovation happen or not and, also, how should the IETF support such activities. It is one aspect that ANY innovation is ju…

How about the companies with deep pockets build a "Routing Alliance" like similar things for IoT and WiFi Alliance, etc (remember the ATM Forum). 

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 26 Feb 2022 08:00:08 +0100

Dave, *

Great discussion - inline.

On Fri, Feb 25, 2022 at 11:41:09AM -0500, David R. Oran wrote:
> > pay for local access to a PoP only, sorry. For that reason, my ISP needs
> > to collaborate within the multi-stakeholder environment that ensures
> > that my packet makes it where I want it to go; it needs to realize
> > “fancy routing” or at least collaborate with those ensuring such “fancy
> > routing”. Maybe some people may see the meaning of “Internet access” as
> > being limited to merely getting to the local PoP; but that is apparently
> > only true for 70 to 90% of customer traffic. So again, I spend my money
> > on having Internet access, all else would greatly change what my
> > contract says.
> However, I can’t think of a single successful instance of an access ISP
> offering anything remotely resembling fancy routing, despite attempts by
> both consumers and the ISPs themselves to offer such:

Is IP Multicast fancy routing ? Quite common in access SPs.
Is hybrid DSL+LTE fancy routing ?
Is dual-path routing to cable converters fancy routing ?
Is DiffServ for the SPs own services, VoIP, unicast/multicast
streaming fancy routing ? DiffServ in the SPs own L3VPN services ?

> upstream can make use of them for fancy routing. The one exception I know of
> is EF setting for a cable operator’s captive VoIP service, but even in this
> case it’s not common; rather the cable operator puts their VoIP on a
> separate L2 SID rather than doing fancy routing/handling of general internet
> traffic.

And in at least 12++ years in which L2/IEEE/Broadband-Forum technologies have
started to eat more and more of our L3 lunch in access networks, we (IETF)
have never really asked ourselves if/what our technologies may be doing wrong
to not be the preferred approach anymore that they where before. And
whenever folks lilke us here try to improve our IETF technologies,
we get answers like yours "see, our past IETF solutions sucked, customers
have been using alternatives"

I mean what's your point ? "We sucked in the past, let's not improve" ?

I have btw also seen counterpoints. SPs will also tell you that dealing
with all these L2 instances and then merging them into a single subnet
in the homes is quite a pain.

> - the cableco’s spent considerable time and energy to define “Packetcable
> Multimedia” which allowed various services to define policy routing and
> queuing, using signaling protocols like COPs to distribute the policy state
> to the routers, which could then use various routing & queueing techniques
> to meet the policy as a PEP. Was deployed a tiny bit in the early 2000’s but
> pulled out as too complicated and expensive compared to just offering more
> bandwidth.

But why did it fail and what does it tell us for the future ?
"The Apple Newton failed, this iPhone idea will never fly"

The main reason why it failed IMHO, like similar advanced services in
3G/4G networks (multimedia services), or DSL providers, is that marketing
in the SPs thought and continues to think that they can best maximize
revenue when they keep advanced network service delivery as an exclusive
to the SPs own application offerings. So the MSO included this better
QoS into the MSOs own Telephony offering, but did at best only do lip-service
in trying to figure out how to make money from allowing third party apps
to use it. And in 3G/4G multimedia services it was even technically (almost)
infeasible for third-party apps to leverage those services. Which is
why radio-level multicast TV in 3G was limited to just the mobile
operators own (doomed) TV services.

> engineering, not IP routing.

Loose path source routing for core network capacity optimization.
Not limited to MPLS. Its an SR feature, applies to SR-MPLS and SRv6. Heck,
if IETF wouldn't have wanted to kill IPv4, we could have done it
equally for that by reviving IPv4 source routing headers after we
ad killed it ;-)

> Recent attempts to push this up to L3 have not
> (so far) gotten much if any deployment traction (e.g. segment routing).

I don't think this is true for Segment Routing. But of course SPs
technology life-cycles are slowing down. And we are missing out on
bringing technologies that would allow for more agile lifecycles.

> companies, provide SLAs but in fact don’t actually affect the deployed L3
> (or L2 other than sometimes separate SIDs). These SLAs seem to be strictly a
> contractual vehicle where it appears universally cheaper to give penalty
> payments than to actually deploy technology to meet the SLAs when the
> network is overloaded or otherwise degraded.

Yes. Same business thinking everwhere.  Does not work well for 911
services and FCC penalties though. I have a reference to such an intance
in RFC8994, but that's missing management level resilience (which could
be fixed by RFC8994) and NN Million USD penalties. I've seen similar
issues for routing (IP Multicast in 911 services) though. And
all those google and facebook outages have similar storylines and
operational behaviors. But of course their services are totall unregulated,
so no penalties.

Again: I am much more a believer to focus on private network requirements
for staging innovation. That is where the application owner has a
direct pull-through into the way the underlying services are provisionined/
operated. Even in SPs, as we know from the SPs own Voice/Video services.

As soon as an SP starts selling network services you have a whole other
set of challenges. Which we should work on, but which aren't necessary
to be solved for a first round of new technology instances (in private
deployments).

> > [DOT] Let me put it that way, paraphrasing Geoff “death of transit”:
> > let’s switch off transit and wait for customers to complain that their
> > ‘local access’ is not doing what they expect it to do, namely ensuring
> > the enjoyment of internet services beyond the local access (and its
> > PoPs).
> > 
> their native facilities get traffic to a metro POP or quite likely a metro
> IXP where the vast majority of Internet services (web proxies, streaming,
> email, VoIP, notifications, etc. etc.) have an off-ramp to the providers of
> the service (Akamai, Google, Microsoft, Netflix, etc. etc.). I’d be
> surprised if much (or any!) user-initiated traffic actually traverses a
> transit. Transit providers are still in the mix, but their big business i
> suspect is by leasing lambdas on their in-ground fiber to the big guys.
> Transit Internet traffic through peering seems to not be growing, and might
> even be declining (though I only have anecdotes, not data, on this - Geoff
> might know more).

And i see this as an opportunity to improve network services, because
now we really primarily have to look into what improvements could and
should happen primarily inside of metro areas and without transit SPs
involved. And with more and more critical infrastructures wanting to be
merged onto common network infrastructures, we would necessarily see
similar operational requirements raised against them as they where all
along against 911.

Cheers
    Toerless

> > for Facebook alone, in the US, is $46/quarter or $15 per month, paid for
> > your product purchases via advertising. Digital ad spending in the US is
> > $183B (2021), i.e., about $1,400 per household per year (there are about
> > 130 million households in the US). That's probably more than you spend
> > on home broadband. You are just spending it when you buy a car or
> > toothpaste.
> > [DOT] I do understand that somebody is attaching value to my presence in
> > and usage of the Internet; that is the same as visiting a physical
> > ‘spending’ interpretation of yours since, well, they are not spending
> > this money. Instead, the expectation of the end user is primarily to get
> > what they directly pay for, and that’s Internet access. Together with
> > RFC8890, I believe that this should be reflected in the solutions we
> > build.
> > 
> > Cc: [email-masked]<mailto:[email-masked]>
> > ; Dirk Trossen <[email-masked]<mailto:[email-masked]>>

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 26 Feb 2022 08:09:50 +0100

I think we are really more at an earlier stage where novel ideas and
experimentation would first need to happen. The model of how we had innovations
in the 1990th between vendors, universities and IETF looks like a fitting
model. The vendors only jumped onto the bandwaggon years after it
started (1989 vs. 1994 if i remember correctly ;-)

Industry alliances typically are for much more baked stuff i think. Not ?

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 26 Feb 2022 13:06:34 -0800

You can define the alliance anyway you see fit and if you wanted to have a research arm and a separate engineering arm they could work on different time scales for a design and implementation. 

I think DARPAnet is one example of this (maybe not the best - but they have a deployed network), where it is government funded versus industry funded. 

Dino

> On Feb 25, 2022, at 11:09 PM, Toerless Eckert <[email-masked]> wrote:
>

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 26 Feb 2022 15:27:50 -0800

Toerless.

At Microsoft Azure we have been using IETF technologies at a huge scale, from routing to encapsulations, from VPNs to SR. Obviously, some things need to be tweaked, centralized and/or distributed to work at such scale but at the base - they are what we have developed here.

Does routing have to be fancy?
It has to be functional, available and reliable (and hopefully operationable  ;-))
In order to deal with complexity - we pushed it to the edges (nothing new - 101 distributed systems ar scale).
Innovation doesn’t necessarily come from a new protocol or encapsulation or god forbid a merge of these ;-) unless the goal is to (up)sell new HW.
There’s so much we can do to make operational characteristics and semantics of existing protocols/encapsulations/services better. 
Most people aren’t looking for a revolution (I know, not cool) but for a steady evolution, ability to evolve while still making money and keeping their customers happy.

Cheers,
Jeff

> On Feb 25, 2022, at 23:10, Toerless Eckert <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 27 Feb 2022 10:27:50 +0100

Thanks, Jeff

A few years back, i listened to a nice Azure presentation (you where there
as well, not at Azure yet though ;-) about tracing path behavior in Azure DCs
by use of a stack of IP-in-IP headers to steer the packet hop-by-hop without
explicit steering support in the packet protocol itself. I really admire
such "abuses" of existing technology and there has been so much creativity
to do this over the decades. Likewise, i think it is clear that it would
be better to design better solutions against requirements and use them instead,
assuming their benefits can be proven. And for such monitoring, IETF makes slow
progress (to finish tht example). Fundamentally i think a lot more innovation
would happen if the programmability of network equipment was as easy as
programmability in DC servers.

One persons revolution is another persons small evolution. How do we
even measure evolution vs. revolution ? I for once think that backward
compatibility/interoperability and evolution paths are a key aspect.

The reason why i think research organizations have an important role to play
is because in my experience, most novel technology whether evolutionary
or revolutionary was a lot easier to grow from small deployments. Changing
large deployments is always the most cost problematic and therefore often
the slowest.

 On the other hand, smaller deployments can only afford to
deal with new technology, when they have a lot of perceived growth opportunity
in the eyes of stakeholders. People building routing within satellite networks
are an example of this. They don't need to care what SDOs want/would say.

On the other hand so many indistrial networks that arguably are not best
served by existing networks do not have this growth outlook. They really
just need opex/capex reduction and agility/security improvements.
 This is where research IMHO comes in to prove those benefits first so
the cost of migration and proof of benefit does not have to be taken on
solely by such highly fragmented industries.

Cheers
    toerless

-- 
---
[email-masked]

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sun, 27 Feb 2022 07:04:24 -0500

"Fundamentally i think a lot more innovation would happen if the
programmability of network equipment was as easy as programmability in DC
servers.”

And we have a research “organisation” to look into this - COINRG. And we
welcome research that will bring network node programmability “easy” but
also useful both in the core and edge. Of course it’s not only routing that
will achieve that but it is part of it.

mjm

From: Toerless Eckert <[email-masked]> <[email-masked]>
Reply: Toerless Eckert <[email-masked]> <[email-masked]>
Date: February 27, 2022 at 4:28:17 AM
To: Jeff Tantsura <[email-masked]> <[email-masked]>
Cc: Dirk Trossen <dirk.trossen=[email-masked]>
<dirk.trossen=[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>
Subject:  Re: [arch-d] [icnrg] recasting address semantics

Fundamentally i think a lot more innovation would happen if the
programmability of network equipment was as easy as programmability in DC
servers.

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Sun, 27 Feb 2022 22:26:06 +0700

Dear Toerless, David &
Architecture-discuss,

Of Toerless's statement:

"

I don't think this is true for Segment Routing. But of course SPs
technology life-cycles are slowing down. And we are missing out on
bringing technologies that would allow for more agile lifecycles".

"Internet technology life-cycles" reminds me on "recycling"*1.

Networks, including Internet technologies, supposedly make routing deals
with such tactical and strategic navigations: destinations, paths (and
vehicles) to go destinations, and destinations contingent/vulnarable to
change. What are thus about addresses...?

Networks recycling, networks deconstruction*2, is for a systemic
configuration of orders. "Order" is about a system of elements*3. Networks
orders and its elements are of self-recyclings, of self-deconstructions.

Engineering itself deals with such orders. Yet Foucault worked on his
discourse-based archaeology of human sciences by such a theoretical frame
on "cultural deconstruction" when he dealth with the notion "order" where
there is an energetic/creative space between order/cultural codes and
intellectual reflections on the order/cultural codes*4.

NOTES:

*1 "Self-recycling" is the term closely related with ecology, yet also in
such an anticipation for "Internet ecology". "Recycling" means
"reprocessing of recovered materials at the end of product life, returning
them into the supply chain ("Handbook of Recycling..." p.9).

https://www.pdfdrive.com/handbook-of-recycling-state-of-the-
art-for-practitioners-analysts-and-scientists-e165930045.html

*2 mailarchives for Architecture-discuss
FYI: Future Directions for Internet Researchers Panel
7-8 January 2021

Derrida mentioned "deconstruction" as one analogeous to "desedimentation":

"The “rationality”—but perhaps that word should be
abandoned for reasons that will appear at the end of this sentence—which
governs a writing thus enlarged and radicalized, no longer issues from a
logos
and it inaugurates the destruction, not the demolition but the de-
sedimentation, the deconstruction, of all the significations that have their
source in that of the logos".
(Ch 1.
"The End of the Book and the Beginning of
Writing Socrates, he who does not write", in the "Of Grammatology")

https://www.pdfdrive.com/of-grammatology-fortieth-anniversar
y-edition-e195303347.html

*3"The Order of Things"

"A ‘system
of elements’ – a definition of the segments by which the resemblances
and differences can be shown, the types of variation by which those
segments can be affected, and, lastly, the threshold above which there
is a difference and below which there is a similitude – is indispensable
for the establishment of even the simplest form of order. Order is, at
one and the same time, that which is given in things as their inner law,
the hidden network that determines the way they confront one
another, and also that which has no existence except in the grid created
by a glance, an examination, a language; and it is only in the blank
spaces of this grid that order manifests itself in depth as though already
there, waiting in silence for the moment of its expression.

The fundamental codes of a culture – those governing its language,
its schemas of perception, its exchanges, its techniques, its values, the
hierarchy of its practices – establish for every man, from the very first,
the empirical orders with which he will be dealing and within which
he will be at home. At the other extremity of thought, there are the
scientific theories or the philosophical interpretations which explain
why order exists in general, what universal law it obeys, what principle
can account for it, and why this particular order has been established
and not some other. But between these two regions, so distant from
one another, lies a domain which, even though its role is mainly an
intermediary one, is nonetheless fundamental: it is more confused,
more obscure, and probably less easy to analyse. It is here that a culture,
imperceptibly deviating from the empirical orders prescribed for it by
its primary codes, instituting an initial separation from them, causes
them to lose their original transparency, relinquishes its immediate
and invisible powers, frees itself sufficiently to discover that these
orders are perhaps not the only possible ones or the best ones; this
culture then finds itself faced with the stark fact that there exists, below
the level of its spontaneous orders, things that are in themselves capable
of being ordered, that belong to a certain unspoken order; the fact, in
short, that order exists. ... Thus, in every culture, between the use of
what one might call the ordering codes and reflections upon order
itself, there is the pure experience of order and of its modes of being".
p. xxi-xxiii
https://www.pdfdrive.com/the-order-of-things-routledge-class
ics-e184283457.html

*3 Ibid

Regard,
Guntur Wiseno Putra

Pada Sabtu, 26 Februari 2022, Toerless Eckert <[email-masked]> menulis:

> needs
> know of
> metro
> for
> in
> [email-masked]<mailto:[email-masked]>>
> > > wrote:
> > > Cc: [email-masked]<mailto:[email-masked]
> >
> > > ; Dirk Trossen <[email-masked]<mailto:[email-masked]
> >>

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 27 Feb 2022 13:38:58 -0800

I’d think - we need to differentiate between run time and repurposing, run time  programmability comes at cost, lower speed, higher power consumption, one need to clearly understand trade-offs and what to optimize towards, if an IP packet needs to be moved from port A to port B without any significant changes to its processing (checksum/TTL/etc), I’d argue - run time programmability (really anything that can’t be done within a single pass with a minimum number of actions )would do more harm than good. As a good use case - the market data you could look at - Barefoot economics (price to build programmability vs price market was willing to pay for it) and TH4 (the opposite of programmable silicon) numbers. I’d however love to be able to reprogram networking silicon rather than waiting for a respin (hello, VXLAN routing), I’m fine doing it off-path and in a highly controlled manner.

Wrt server vs networking equipment - proliferation of smart NICs and amount of investments clearly shows where the money is, from overall complexity prospective - further distribution to the edges is the only sustainable way to manage it.
What’s missing?
A set of well defined API’s and behaviors between the network and its edges, this is less obvious in plain IP networking, a pain in RDMA and ML clusters. This goes back to operability and end2end behavior (really service definition + set of SLA/SLO/KPIs associated). New overlay encapsulations allow for such innovations (Geneve, INT header, etc) and new silicon is capable (some more some less) of processing this data in near real time. If the edge that is service aware can get this data fast enough and the data itself is high fidelity and rich enough (within limits) to allow the edge to change its behavior - we would have solved many problems we are working on now.
I’m not discounting more advanced use cases, in network compute, reduce functions, etc, however these are niche use cases and require very different economics to be successful.

/*weekend rant  

Cheers,
Jeff

> On Feb 27, 2022, at 04:04, Marie-Jose Montpetit <[email-masked]> wrote:
> 
> 
> "Fundamentally i think a lot more innovation would happen if the programmability of network equipment was as easy as programmability in DC servers.”
> 
> And we have a research “organisation” to look into this - COINRG. And we welcome research that will bring network node programmability “easy” but also useful both in the core and edge. Of course it’s not only routing that will achieve that but it is part of it.
> 
> mjm
> 
> From: Toerless Eckert <[email-masked]>
> Reply: Toerless Eckert <[email-masked]>
> To: Jeff Tantsura <[email-masked]>
> Cc: Dirk Trossen <dirk.trossen=[email-masked]>, [email-masked] <[email-masked]>
>> Fundamentally i think a lot more innovation would happen if the programmability of network equipment was as easy as programmability in DC servers.

---

From: Dirk Trossen <[email-masked]>
Date: Mon, 28 Feb 2022 08:11:34 +0000

I’m not discounting more advanced use cases, in network compute, reduce functions, etc, however these are niche use cases and require very different economics to be successful.
[DOT] FWIW, the COIN RG is spending efforts on a use case draft to gather those scenarios in which programmability may be beneficial. Whether they’re ‘niche’ or not is not the focus of the draft though but distilling research opportunities, challenges and possible requirements. Capturing economics is done only indirectly by inviting stakeholders to contribute to the efforts, i.e., having folks to bring in their (possible economically worthwhile) examples.

Best,

Dirk

/*weekend rant

Cheers,
Jeff

On Feb 27, 2022, at 04:04, Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>> wrote:

mjm

From: Toerless Eckert <[email-masked]><mailto:[email-masked]>
Reply: Toerless Eckert <[email-masked]><mailto:[email-masked]>
Date: February 27, 2022 at 4:28:17 AM
To: Jeff Tantsura <[email-masked]><mailto:[email-masked]>
Cc: Dirk Trossen <dirk.trossen=[email-masked]><mailto:dirk.trossen=[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject:  Re: [arch-d] [icnrg] recasting address semantics

---

From: Dirk Trossen <[email-masked]>
Date: Mon, 28 Feb 2022 08:20:44 +0000

Maybe but doesn't the IETF/IRTF combination sound like the right  place for this? Given your Wifi Alliance example, this sounds more like something at the end of as process of agreeing on solutions, not the beginning. Of course, it could have a research 'arm' but then, again, what's wrong with the IETF/IRTF providing this?

I think the key is that a place is needed IMO that provides a place for researchers to bring in their idea, results, early solutions to better understand how this may align with what is currently being developed elsewhere but also to increase their own knowledge on what may drive adoption of their idea (if they do have an interest in that question, which admittedly not all researchers have).

Dirk
-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: 26 February 2022 00:28
To: Dirk Trossen <[email-masked]>
Cc: Geoff Huston <[email-masked]>; David R. Oran <[email-masked]>; [email-masked]
Subject: Re: [arch-d] [icnrg] recasting address semantics

Dino

---

From: Dirk Trossen <[email-masked]>
Date: Mon, 28 Feb 2022 08:33:51 +0000

Brian,

Thanks for this interjection. Please see inline.

Best,

Dirk

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: 25 February 2022 20:35
To: Marie-Jose Montpetit <[email-masked]>; Colin Perkins <[email-masked]>; Luigi Iannone <[email-masked]>
Cc: Toerless Eckert <[email-masked]>; [email-masked]; Dirk Trossen <[email-masked]>; [email-masked]
Subject: Re: [arch-d] Routing research group (was: Re: [icnrg] recasting address semantics)

Here's a slightly more general question. There's *another* research community in our space, i.e. the SIGCOMM community. Some people on this thread flirt with all of the IETF, the IRTF and SIGCOMM.
[DOT] SIGCOMM is not the only one but yes, we have members of the wider research community that 'flirt' in all or some of those communities. 

Is there a gap between SIGCOMM and the IRTF/IETF? Is there an overlap? Should there be an explicit discussion of that topic to see if the gap/overlap needs active attention or joint action?
[DOT] I'm not sure about a gap but I see it more as a pathway, connecting the research community and its discussion (on routing) with the IETF, possibly through the IRTF (or maybe a dedicated IETF WG, as being asked in a recent RTG WG draft of mine). Now you are right, that there is overlap already between those communities but there may also be a need to improve on that pathway through a dedicated forum rather a general "bring your work to us, picking the right WG/RG to do so". In previous side meetings, organized by Adrian Farrel and Dan King, we attempted doing so with insights from approaches on multi-optimality routing, Internet architecture evolution, web service to single IP address mapping etc. to the wider IETF/IRTF audience.  

Clearly routing is not the only area of mutual interest, but it's one of the important ones.
[DOT] Clearly but we indeed need to start somewhere.

Regards
    Brian Carpenter

> We also have discussed how to attract more people to the IETF and IRTF. 
I would say there is no “global answer” but I think the answer is that WE have to be proactive. Having a new WG or RG is not going to get anyone in. We can take that discussion off thread.
> Cc: Toerless Eckert <[email-masked]> <mailto:[email-masked]>, 
> [email-masked] <mailto:[email-masked]> <[email-masked]> 
> <mailto:[email-masked]>, Dirk Trossen 
> <mailto:dirk.trossen=[email-masked]>, 
> [email-masked] <mailto:[email-masked]> 
> <[email-masked]> <mailto:[email-masked]>
>>> The feedback I gave, and the feedback I have given to the other 
>>> people proposing similar work, was that to the extent there was 
>>> research being
>>>> I “coordinated” three side meetings (IETF-111, interim between 111 
>>>> and 112, IETF-112) loosely under the umbrella of “Semantic Routing” 
>>>> but what we were actually doing was highlighting some 
>>>> important/interesting recent research that we came across while 
>>>> researching Semantic Routing. We felt that the IETF routing 
>>>> community would
>>>> But it’s hard, isn’t it? Where do we talk about routing research? 
>>>> Semantic Routing has been directed to the COIN RG as it has
“considerable overlap”. RTGWG has always been welcoming, but (of course) it also has engineering work to do. The Routing Area meeting and the Routing-Discussion mailing list have some space, but they are mainly concerned with coordinating the work of the Routing Area.
>>>> *From:*Architecture-discuss <[email-masked] 
>>>> <mailto:[email-masked]>>*On Behalf Of*Luigi 
>>>> Iannone
>>>> *Cc:[email-masked] <mailto:[email-masked]>; Dirk Trossen 
>>>> <dirk.trossen=[email-masked] 
>>>> <mailto:dirk.trossen=[email-masked]>>;architecture-dis
>>>> [email-masked] <mailto:[email-masked]>
>>>> *Subject:*Re: [arch-d] Routing research group (was: Re: [icnrg] 
>>>> recasting address semantics) Hi Toerless, All,
>>>>
>>>>> Lets not forget that the term "semantic routing" is primarily an 
>>>>> attempt to overcome useless procedural hurdles put up against the 
>>>>> desire to
bring back
>>>>> routing research into the IETF. And that is putting what i think 
>>>>> we have experienced over the past years very mildly. And i think 
>>>>> the IETF should be ashamed of itself.
>>>>>
>>>>> I think we have shown ample of evidence that there is a lot of 
>>>>> good routing research out there through various side meetings, but 
>>>>> obviously such series of one-off meetings without any IETF 
>>>>> endorsement or communications forum like an IRTF mailing list is 
>>>>> no basis from which the IETF can attract a better ongoing basis of 
>>>>> collaboration about routing research with the research community.
>>>>
>>>> This has been captured in the addressing manifesto 
>>>> document:https://datatracker.ietf.org/doc/draft-iannone-routing-and
>>>> -addressing-manifesto/ 
>>>> <https://datatracker.ietf.org/doc/draft-iannone-routing-and-address
>>>> ing-manifesto/> The document also point to a etherpad where people 
>>>> can support explicitly the idea contained in the document:
>>>> <https://etherpad.wikimedia.org/p/routing.addressing.manifesto>
>>>>> An actual routing research group could and would do that. But it 
>>>>> would take time to have more researchers learn how their work 
>>>>> could profit from such a research group. Such as using it as a 
>>>>> basis for discussing, exploring, collecting information from the 
>>>>> technology experts in the IETF, getting ideas about what routing 
>>>>> research ideas would have real interest from the industry and so 
>>>>> on. And it takes time to build such a community, because evenin 
>>>>> research it is widely scattered and it will take time to go out to 
>>>>> research conferences and educate reserchers about thesenew opportunities with the IETF.
>>>> What we need is to make the effort to go out there and reach out 
>>>> for
those researchers.
>>>>> And NMRG is similarily open ended in its scope as we IMHO need an 
>>>>> open ended routing research group. So why can we have it in 
>>>>> network management, but not in routing ? I never get answers to 
>>>>> those fundamental questions from IETF leadership.
>>>>> communities that have escaped us, with efforts such as iotops or 
>>>>> mops. But in both cases we had IETF leadership actively pushing 
>>>>> for these rather untypical groups. In the case of the IRTF we have the opposite push.
>>>>>
>>>>> Maybe we should simply do some doodle poll asking the IETF 
>>>>> community if it wants / would support an routing research group.
>>>>>
>>>>> Oh, and i think "routing semantics" is a great new field for 
>>>>> taxonomy and construction and analysis of common mechanisms to 
>>>>> serve a broader set of use-cases (semantics). Heck, we have never 
>>>>> even managed to find a common framework around unicast and anycast 
>>>>> and variations thereof, and we repeatedly get someone trying to 
>>>>> open that can of worms with badly informed protocol proposals.
>>>>>
>>>>> This would be an example similarily good research work as the 
>>>>> ongoing taxonomy/methodology work on "intent" going on in NMRG. 
>>>>> Which also was a work item that could only evolve because NMRG 
>>>>> wasn't given IRTF process hazing.
>>>>>
>>>>> Cheers
>>>>>    Toerless
>>>>>
>>>>> <mailto:[email-masked]>
>>>>> <https://www.ietf.org/mailman/listinfo/architecture-discuss>
>>>> <mailto:[email-masked]>
>>>> <https://www.ietf.org/mailman/listinfo/architecture-discuss>
>>>
>>
>> <https://www.ietf.org/mailman/listinfo/architecture-discuss>
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 28 Feb 2022 12:59:38 +0100

Jeff, *:

It would be lovely to capture these aspects so we do not need to restart
the discussion from 0 every time. Not sure, how feasible it is to get
actual market data though. Of course, not every forwarding feature needs
to go onto every hop as well. Cc'ing [email-masked] because maybe there
are more folks interested in co-writing such an informational document.

I am not sure if barefoot was/is necessarily more expensive at the chip
level than other data center switch chips, or whether it is even a lot
more programmable. Comparing a challenger with a new sales model of
"programmability" with big incumbants that primarily operate on "best price"
is quite difficult. And obviously, the very big customers may be happy
about programmable platforms for experimentation/development, but once they
have figured out exactly what they want, they will go for cost optimiation.

As i think i said: Selling the differential for a programmable forwarding
plane requires new services such as programmable slices. Or dedicated R&D
/ repurposavbe network equipment.  There is a reason why we do not have it
for existing business/services.

Vendor-internal reprogrammability has btw. been tried a few times in my
experience. FPGA for example for PTP, deterministic ethernet, video monitoring
just to name a few. But unless its user-programmable its a very difficult
decision to put such programmability into equipment at all. 

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 28 Feb 2022 08:16:47 -0800

> 
> On Feb 28, 2022, at 12:33 AM, Dirk Trossen <dirk.trossen=[email-masked]> wrote:
> 

The gap was addressed years ago:
https://irtf.org/anrp/ <https://irtf.org/anrp/>

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 28 Feb 2022 17:46:32 +0100

Joe,

Maybe you can explain how you think ANRP closes a gap instead of just
throwing in a URL.

IMHO, ANRP is "just" a price. It _may_ help to get more researchers towards
ANRW, but given how ANRW is "just" a workshop, i can not even find it in
ranking systems for researchers such as http://portal.core.edu.au/conf-ranks/,
and i bet that ranking itself would be a prime deciding factor for publishing.

I would not be surprised if ANRW was a good excuse for researchers who
are already aware of IETF/IRTF to get fudning to go if they get a paper
into ANRW, but what is then missing is IMHO an actual
 ongoing engagement/collaboration platform. Which is what WG/RGs are.

ANRW does not even have an IRTF mailing list except for its organizers.
(why not... *sigh*).

Aka: I don't think we're making it particularily easy to engage for researchers
with our community unless there already is an obvious landing place via an RG/WG.

Cheers
    Toerless

P.S.: Research conferences themselves are obviously worse wrt. engagement,
but thats not their purpose. IEEE/ACM have communities for that. Conferences
are just publishing vehicles. Workshops are only more than publishing if
you go in person (the virtual experience with workshops in the past two
years has been dismal IMHO). A lot to be learned. grizzly tools. Even
with IAB workshops. IMHO, i still haven't seen anything that beats mailing
lists for ongoing engagement.

Not really IMHO. The price is just a nice tool to support participation.
The tool itself is ANRW: https://irtf.org/anrp/

But ANRW itself is just like any other isolated research conference in that
its really only good to present results a a form of publication, and in
that respect it is proba

-- 
---
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 28 Feb 2022 11:06:51 -0800

> Maybe but doesn't the IETF/IRTF combination sound like the right  place for this? Given your Wifi Alliance example, 

IRTF/IETF should be the right place, but it depends on your goals and time-to-market.

> this sounds more like something at the end of as process of agreeing on solutions, not the beginning. Of course, it could have a research 'arm' but then, again, what's wrong with the IETF/IRTF providing this?

I am not saying you use the existing alliances the same way you would here. But you are unsatsified with the support that the IRTF/IETF is giving you, then use a forum. Maybe a better example is ONUG. It's a user group, but they do build documents and have open discussions.

But you don't have to copy these examples. I have a feeling I am being misleading. Just create an organization that is funded by private industry and let the discussions and brainstorming begin.

> I think the key is that a place is needed IMO that provides a place for researchers to bring in their idea, results, early solutions to better understand how this may align with what is currently b…

You can also check on the university communities.

Dino

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 28 Feb 2022 15:45:51 -0800

Hi, Toerless,

> On Feb 28, 2022, at 8:46 AM, Toerless Eckert <[email-masked]> wrote:
> 
> Joe,
> 

It’s directly explained on the front page, in the first two paragraphs, notably in the middle of the second one (which I have highlighted in bold):
About the ANRP
The Applied Networking Research Prize (ANRP) is awarded to recognise the best recent results in applied networking, interesting new research ideas of potential relevance to the Internet standards community, and upcoming people that are likely to have an impact on Internet standards and technologies, with a particular focus on cases where these people or ideas would not otherwise get much exposure or be able to participate in the discussion.

We encourage nominations of researchers with relevant research results, interesting ideas, and new perspectives. The award will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers, and scientists that participate in the Internet Engineering Task Force (IETF <https://ietf.org/>) and its research arm, the Internet Research Task Force (IRTF). Both self- and third-party nominations for this prize are encouraged.

> IMHO, ANRP is "just" a price.

The bold sentence explains why it’s *exactly* to bridge the gap between research communities and the IETF - by FUNDING them to attend present their work to the IETF.

> It _may_ help to get more researchers towards
> ANRW, but given how ANRW is "just" a workshop,

I think you’re “crossing the streams”, to quote Ghostbusters.

ANRP is a prize for work published elsewhere (see the nominations page), to encourage participation in the authors of that work in the IETF/IRTF.

ANRW is a workshop with a similar name, but is not related (except both are managed by the IRTF chair).

Skipping ahead...

> with our community unless there already is an obvious landing place via an RG/WG.

How is ANRP not *EXACTLY* what you want?

(Granted ANRW isn’t, but that shouldn’t matter as they’re not directly related)

Joe

---

From: Colin Perkins <[email-masked]>
Date: Tue, 1 Mar 2022 00:42:32 +0000

> On 28 Feb 2022, at 23:45, [email-masked] wrote:
...
> ANRW is a workshop with a similar name, but is not related (except both are managed by the IRTF chair).

This is correct.

The Applied Networking Research Prize (ANRP) is a joint activity of the Internet Society and IRTF. As Joe mentions, it’s explicitly intended "to recognise the best recent results in applied networking, interesting new research ideas of potential relevance to the Internet standards community, and upcoming people that are likely to have an impact on Internet standards and technologies, with a particular focus on cases where these people or ideas would not otherwise get much exposure or be able to participate in the discussion” and "offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers, and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF)” (quoting from https://irtf.org/anrp/ <https://irtf.org/anrp/>).

The ACM/IRTF Applied Networking Research Workshop (ANRW) is jointly organised by ACM SIGCOMM and the IRTF (with 50% ownership from each). It is intended to "provide a forum for researchers, vendors, network operators and the Internet standards community to present and discuss emerging results in applied networking research”. "In order to foster this cross-community collaboration, the workshops will be co-located with IETF standards meetings once a year (typically in the summer), and will be organized in a way that allows ample time for discussion and interaction, and not just paper presentations.” (quoting from https://irtf.org/anrw/ <https://irtf.org/anrw/>).

I’ll also highlight that IRTF awards travel grants for researchers to attend ANRW and, more generally, to support early career academics and PhD students from under-represented groups to attend IRTF meetings – again, to encourage broad participation from the wider research community in IRTF events and research groups. 

The explicit goal of these activities is to bridge the gap between SIGCOMM, the broader networking research community, the IRTF, and the IETF, and to encourage collaboration, discussion, and interaction between the different communities.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Mar 2022 14:20:23 +1300

Colin,

Thanks for the explanation, and this is all goodness. Is there any way to 
measure its success in cross-fertilising ideas?

I remain concerned that the majority of IETF participants don't know what's going on in SIGCOMM and what is published in CCR. I don't think the opposite is true, because CCR & SIGCOMM articles are often stuffed with references to RFCs and even I-Ds.

Regards
    Brian Carpenter

On 01-Mar-22 13:42, Colin Perkins wrote:
>> On 28 Feb 2022, at 23:45, [email-masked] <mailto:[email-masked]> wrote:
> ...
> The Applied Networking Research Prize (ANRP) is a joint activity of the 
Internet Society and IRTF. As Joe mentions, it’s explicitly intended "to recognise the best recent results in applied networking, interesting new research ideas of potential relevance to the Internet standards community, and upcoming people that are likely to have an impact on Internet standards and technologies, with a particular focus on cases where these people or ideas would not otherwise get much exposure or be able to participate in the discussion” and "offer them the opportunity to present and discuss their work with the 
engineers, network operators, policy makers, and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF)” (quoting from https://irtf.org/anrp/ <https://irtf.org/anrp/>).
> I’ll also highlight that IRTF awards travel grants for researchers to attend ANRW and, more generally, to support early career academics 
and PhD students from under-represented groups to attend IRTF meetings – again, to encourage broad participation from the wider research community in IRTF events and research groups.
> 
> The *explicit* *goal* of these activities is to bridge the gap between SIGCOMM, the broader networking research community, the IRTF, and the IETF, and to encourage collaboration, discussion, and interaction between the different communities.
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/ <https://csperkins.org/>
> 
> 
> 
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 1 Mar 2022 01:49:20 +0000

> On 1 Mar 2022, at 01:20, Brian E Carpenter <[email-masked]> wrote:
> 
> Colin,
> 
> Thanks for the explanation, and this is all goodness. Is there any way to measure its success in cross-fertilising ideas?

It wasn’t the main focus of the work, but our recent IMC paper showed that the fraction of RFC authors with academic affiliation is slowly increasing. That might suggest at least some success bringing research results into the IETF community.

ANRW and ANRP talks seem quite well attended, and the feedback I receive is generally pretty positive. Speakers often get invited to reprise their talks in related WG meetings – more so in pre-pandemic times, perhaps – suggesting some interest in the work. 

> I remain concerned that the majority of IETF participants don't know what's going on in SIGCOMM and what is published in CCR. I don't think the opposite is true, because CCR & SIGCOMM articles are…

It would be interesting to see whether the number of references to research papers in RFCs is increasing or decreasing over time, to perhaps get an idea whether that’s true.

(SIGCOMM tries to ensure papers are open access, so the work is accessible to people that are interested)

Colin

> Internet Society and IRTF. As Joe mentions, it’s explicitly intended "to recognise the best recent results in applied networking, interesting new research ideas of potential relevance to the Internet standards community, and upcoming people that are likely to have an impact on Internet standards and technologies, with a particular focus on cases where these people or ideas would not otherwise get much exposure or be able to participate in the discussion” and "offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers, and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF)” (quoting from https://irtf.org/anrp/ <https://irtf.org/anrp/>).

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Mar 2022 14:56:40 +1300

[Resending because of a bizarre address invented by Reply-all]

Colin,

Regards
     Brian Carpenter

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Feb 2022 18:56:36 -0800

> On Feb 28, 2022, at 5:56 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> I remain concerned that the majority of IETF participants don't know what's going on in SIGCOMM and what is published in CCR. 

You say that like it’s a bad thing.  A lot of work published in those (imo) echo chambers is not necessarily of practical impact.  That includes work there that’s been taken into the iETF of IRTF. 

ANRP strikes a reasonable balance at targeting work that might be. 

Joe