Subject: [Int-area] Where/How is the features innovation happening?

From: Luigi Iannone <[email-masked]>
Date: Thu, 16 Dec 2021 10:09:05 +0100

Dear all,
 
We have had a very nice discussion in the previous thread about what kind of features we would want from the Internet. 
 
We wanted to come back on another interesting point that has been raised during the side meeting held during IETF 112, namely is where the innovation happening? 
During the discussion in the side meeting, there was a short exchange between Dino, arguing about “decentralization”, and Michael stating that we are “rebuilding the edges”; the importance of the role of overlays was also briefly mentioned.
 
This is not a simple question, and may lead to an architectural argument, in line with Dirk K.’s viewpoint that only such architecture discussion may lead to possible changes to addressing, but also something that emerged in the previous thread. However, let’s at least start from the addressing perspective.
Rebuilding the edges and utilizing decentralization may point to some approach to addressing that is not governed by a common addressing scheme.
For instance, could we instead see a diversity of limited domain specific addressing schemes with most effort in ‘addressing’ being placed into the context translation that will need to inevitably happen? Or shall we instead follow the current path that forces the same context (IP semantics) to all participating edges (which goes counter the ‘rebuilding the edges’ comment)?
 
Hence the question we would like to discuss with you on: how/where innovation, realizing the features discussed in the previous thread, should happen?
 
This can help in strengthening the conclusion of the Problem Statement document (https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/ <https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/>), in order to provide input on which way to tackle the problem. 
 
Luigi
 
(on behalf of the co-authors)

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Dec 2021 10:59:42 +0100

Le 16/12/2021 à 10:09, Luigi Iannone a écrit :
> Dear all,
> We have had a very nice discussion in the previous thread about what 
> kind of features we would want from the Internet.
> We wanted to come back on another interesting point that has been raised 
> during the side meeting held during IETF 112, namely is where the 
> innovation happening?

Do you mean on what layer in the stack is innovation happening?

Do you mean on which part of the network: the end node, the core?

Do you mean where on Earth is it happening?

Alex

> During the discussion in the side meeting, there was a short exchange 
> between Dino, arguing about “decentralization”, and Michael stating that 
> we are “rebuilding the edges”; the importance of the role of overlays 
> was also briefly mentioned.
> This is not a simple question, and may lead to an architectural 
> argument, in line with Dirk K.’s viewpoint that only such architecture 
> discussion may lead to possible changes to addressing, but also 
> something that emerged in the previous thread. However, let’s at least 
> start from the addressing perspective.
> Rebuilding the edges and utilizing decentralization may point to some 
> approach to addressing that is not governed by a common addressing scheme.
> For instance, could we instead see a diversity of limited domain 
> specific addressing schemes with most effort in ‘addressing’ being 
> placed into the context translation that will need to inevitably happen? 
> Or shall we instead follow the current path that forces the same context 
> (IP semantics) to all participating edges (which goes counter the 
> ‘rebuilding the edges’ comment)?
> Hence the question we would like to discuss with you on: how/where 
> innovation, realizing the features discussed in the previous thread, 
> should happen?
> This can help in strengthening the conclusion of the Problem Statement 
> document 
> (https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/ 
> <https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/>), 
> in order to provide input on which way to tackle the problem.
> Luigi
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 16 Dec 2021 12:29:56 +0100

Hi Alex,

Thanks, I might have been unclear.

By “where” I meant to make a difference between the core infrastructure and “edges“, where the latter can be considered limited domains that need to interconnect to the Internet (the core) but as well among them not necessarily going through a centralized service.

Is it clearer?

Ciao

L. 
 
> On 16 Dec 2021, at 11:00, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Dec 2021 12:48:16 +0100

Le 16/12/2021 à 12:29, Luigi Iannone a écrit :
> By “where” I meant to make a difference between the core 
> infrastructure and “edges“, where the latter can be considered 
> limited domains that need to interconnect to the Internet (the core) 
> but as well among them not necessarily going through a centralized 
> service.
> 
> Is it clearer?

YEs, it is clearer: a core-edge balance of localisation of innovation in
the Internet, in addition to the addressing aspect.

With respect to where is Internet innovation situated - in the edge or
in the core: I think most patents are developped at the edges, in the
limited domains.  There is where it is easier to innovate.  A patent for
a technology in the core network would have a hard time to be agreed.  I
dont know whether there are patents on BGP in the DFZ, or on DNS at
root, but I think not.

With respect to addressing: the ULA addressing is an exemplary facet of
how limited domains might use a different addressing than the Internet
at large.  However, ULA is still IP addressing - the 128bit addresses.

Should one innovate in the edges, rebuild the edges rather than touching
on the core, and concentrate all 'addressing' work in in designing of
translation mechanisms?  Yes, but would that significantly slow down the
Internet?  If at every packet forward one has to look up a translation
table then it might be expensive.  More energy-consuming big boxes to
translate and to offer new opportunities of controlling that translation?

Alex

>>> Le 16/12/2021 à 10:09, Luigi Iannone a écrit : Dear all, We have 
>>> had a very nice discussion in the previous thread about what
>>> kind of features we would want from the Internet. We wanted to
>>> come back on another interesting point that has been raised
>>> During the discussion in the side meeting, there was a short 
>>> exchange between Dino, arguing about “decentralization”, and 
>>> Michael stating that we are “rebuilding the edges”; the 
>>> importance of the role of overlays was also briefly mentioned. 
>>> argument, in line with Dirk K.’s viewpoint that only such 
>>> architecture discussion may lead to possible changes to 
>>> addressing, but also something that emerged in the previous 
>>> thread. However, let’s at least start from the addressing 
>>> perspective. Rebuilding the edges and utilizing decentralization 
>>> may point to some approach to addressing that is not governed by 
>>> a common addressing scheme. For instance, could we instead see a 
>>> diversity of limited domain specific addressing schemes with
>>> most effort in ‘addressing’ being placed into the context
>>> translation that will need to inevitably happen? Or shall we
>>> instead follow the current path that forces the same context (IP
>>> semantics) to all participating edges (which goes counter the
>>> ‘rebuilding the edges’ comment)? Hence the question we would like
>>> to discuss with you on: how/where innovation, realizing the
>>> features discussed in the previous thread, should happen? This
>>> can help in strengthening the conclusion of the Problem Statement
>>> document 
>>> Luigi (on behalf of the co-authors) 
>>> _______________________________________________ Int-area mailing 
>>> list [email-masked] 
>> _______________________________________________ Int-area mailing 
>> list [email-masked]

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 16 Dec 2021 17:29:56 +0100

Hi Alex,

A few comments inline

L.

Sent from my iPad

> On 16 Dec 2021, at 12:48, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
I would say as part of the addressing aspect. 
The degree of addressing innovation that can be done changes with respect to where you are (aka core vs edge)

> at large.  However, ULA is still IP addressing - the 128bit addresses.

Another simple example are IoT limited domains, where addresses are usually much shorter then 128 bits.

> translate and to offer new opportunities of controlling that translation?

These are interesting questions. You do not need necessarily to translate, you can use overlays (but may still need a lookup in some table). Progress in hardware and software can help to cope with the additional operations. As for the energy consumption, it really depends where you can save it. Translating IPv6 addresses to shorter ones is worthwhile in IoT, because then you can save energy by transmitting less bits.
Where to find the balance between communication and computation energy consumption depends on the specific use case IMO.

Some additional question may relate about privacy and leakages.
If privacy is desired how to protect the identity of communication end-point inside limited domains?  From a more general perspective how to avoid information leakage outside limited domains?

Ciao

L.

>>>> Le 16/12/2021 à 10:09, Luigi Iannone a écrit : Dear all, We have had a very nice discussion in the previous thread about what
>>>> During the discussion in the side meeting, there was a short exchange between Dino, arguing about “decentralization”, and Michael stating that we are “rebuilding the edges”; the importance of the role of overlays was also briefly mentioned. This is not a simple question, and may lead to an architectural argument, in line with Dirk K.’s viewpoint that only such architecture discussion may lead to possible changes to addressing, but also something that emerged in the previous thread. However, let’s at least start from the addressing perspective. Rebuilding the edges and utilizing decentralization may point to some approach to addressing that is not governed by a common addressing scheme. For instance, could we instead see a diversity of limited domain specific addressing schemes with
>>>> document (https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/
>>>> 
>>>> in order to provide input on which way to tackle the problem. Luigi (on behalf of the co-authors) _______________________________________________ Int-area mailing list [email-masked] https://www.ietf.org/mailman/listinfo/int-area
>>> _______________________________________________ Int-area mailing list [email-masked] https://www.ietf.org/mailman/listinfo/int-area

---

From: Geoff Huston <[email-masked]>
Date: Thu, 16 Dec 2021 19:27:40 +0000

> On 16 Dec 2021, at 8:09 pm, Luigi Iannone <[email-masked]> wrote:
> 
> Dear all,
>  

This seems to me to be the central question of the current time. The formation of address markets is creating a whole new set of pressures on the IPv4 space which in turn is creating pressures for change in the IP architecture. 

Informally, I’d characterise these pressures as follows:

We've been looking at the evolution of addressing architectures through a lens of IPv4 plus NATs versus IPv6. It is useful to question this assumption and see if there are other responses that are available for the Internet. IPv4 plus NATs and IPv6 are both used in packet switched networks as a means of sharing a common underlying network. But sharing is not a popular word anymore, particularly in terms of IP transit services. These days we are seeing the major content providers build and operate their own dedicated transmission infrastructure to interconnect their data centres. This cloud we are all using is not a shared cloud, but a collection of dedicated cloudlets that are not constructed on a sharing model at the packet level. If we don't want to share a common transmission resource, then why do we need globally unique addresses to use in IP packet headers? Locally unique addresses would do just as well.

This question could be posed in the context of the evolution of NAT deployments in today's Internet. NATs were originally seen as a way for edge networks to share a single provider IP address across multiple devices own the home network. This is still the case, but address scarcity has also pushed the access ISP to deploy NATs at the external edge of the access network, using private addresses comprehensively within the internal network infrastructure. This provides greater address utilisation efficiencies, allowing the access network to stretch the public IPv4 addresses across a greater number of end clients. But if the bulk of all data delivered to customers is now sourced from a local data centre that houses the local points of presence from the content distribution networks, then what would happen to the pressure on the access network's IP address pool if the NAT was pushed inside the local data centre? Or to phrase it in the other direction, what would happen if every content network had a point presence on the "inside" of each access ISP's network? From the perspective of the content provider nothing changes. The client IP address is relative to the local point of presence, so the same local IP addresses can be used in multiple points of presence with no impact on this model. But from the perspective of the demand for globally unique IP addresses a lot has just happened. There is no residual need for them!

This line of thought takes the edge innovation observation and just pushes it a but further!

regards,

  Geoff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Dec 2021 15:33:36 -0500

I sure hope you are wrong about where things are going.  Because the 
logical consequence of the placement and addressing picture you paint is 
that all innovation in applications and uses of the Internet comes from 
incumbent players who have the leverage and resources to be present at 
almost all "insides".  That would seem very unfortunate.

Yours,
Joel

On 12/16/2021 2:27 PM, Geoff Huston wrote:
> ders build and operate their own dedicated transmission infrastructure to interconnect their data centres. This cloud we are all using is not a shared cloud, but a collection of dedicated cloudlets that are not constructed on a sharing model at the packet level. If we don't want to share a common transmission resource, then why do we need globally unique addresses to use in IP packet headers? Locally unique addresses would do just as well.
> 
> This question could be posed in the context of the evolution of NAT deployments in today's Internet. NATs were originally seen as a way for edge networks to share a single provider IP address across multiple devices own the home network. This is still the case, but address scarcity has also pushed the access ISP to deploy NATs at the external edge of the access network, us

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 16 Dec 2021 16:35:02 -0600

> If we don't want to share a common transmission resource, then why do we need globally unique addresses to use in IP packet headers? Locally unique addresses would do just as well.

Just to answer this question specifically. We may not need globally unique addresses. But I need a unique address for anyone I want to talk to and I don't care what transmission networks my packets traverse.

Therefore, we need unique addresses. However, lets say an address is 24 bits long and we use a random number to generate the address. It is unlikely that there will be an address collision for all the things I want to talk to. So to me I get my unique address. Is it globally unique, well no, but maybe it doesn't have to be. 

But there will be hosts that want to talk to everyone in the world or at least beyond an address collision domain, so we default for the desire to want/need globally unique addresses. So simply using a random number generator for an IPv6 address may get us there and work sufficiently. 

Comments?

> This question could be posed in the context of the evolution of NAT deployments in today's Internet. NATs were originally seen as a way for edge networks to share a single provider IP address across multiple devices own the home 

Or said another way, NATs gave us 48-bit addresses that were guaranteed globally unique.

> network. This is still the case, but address scarcity has also pushed the access ISP to deploy NATs at the external edge of the access network, using private addresses comprehensively within the internal network infrastructure. This 

Also Geoff, people talk and desire address privacy. Well when there are 3 NATs between you and me, my source address for packets addressed to you are pretty well obfuscated (the second NAT just destroyed the identity of my access network provider, and the third NAT destroyed the identity the transit network provider). 

So we got this feature by stumbling into it!

> provides greater address utilisation efficiencies, allowing the access network to stretch the public IPv4 addresses across a greater number of end clients. But if the bulk of all data delivered to customers is now sourced from a local data centre that houses the local points of presence from the content distribution networks, then what would happen to 

Yes, but the TCP acks going back to them are obfuscated/NAT-traversed source addresses.

> the pressure on the access network's IP address pool if the NAT was pushed inside the local data centre? Or to phrase it in the other direction, what would happen if every content network had a point presence on the "inside" of each access ISP's network? From the perspective of the content provider nothing changes. The client IP address is relative to the local point of presence, so the same local IP addresses can be used in multiple points of presence with no impact on this model. But from the perspective of the demand for globally unique IP addresses a lot has just happened. There is no residual need for them!

But the high-order 32-bits of that 48-bit address must be unique. And we know the allocation of those bits comes from outside of that host sending packets (non local matter). Where the low-order 16-bits can be a local matter and hence do not have to concern itself when TCP/UDP ports number could collide among 2 hosts talking to each other.

> This line of thought takes the edge innovation observation and just pushes it a but further!

Joel interpreted this as bad news and was hoping Geoff would be wrong. But what if Google wanted packets to come into my host with an obfuscated source address. They might want that. The solution is ugly and maybe costly but its not like we would be trying a brand new technology since NATs have been around forever. 

To be clear, I am not encouraging this.

Dino

---

From: Geoff Huston <[email-masked]>
Date: Fri, 17 Dec 2021 01:49:26 +0000

> On 17 Dec 2021, at 7:33 am, Joel M. Halpern <[email-masked]> wrote:
> 
> I sure hope you are wrong about where things are going.

so do I.

> Because the logical consequence of the placement and addressing picture you paint is that all innovation in applications and uses of the Internet comes from incumbent players who have the leverage and resources to be present at almost all "insides".  That would seem very unfortunate.
> 

It's destructive and manipulative in so many ways Joel, but while it would be comforting to prognosticate about preferred futures, I suspect that the content distribution world is not going to listen to my preferences, and is heading down its own path.

Geoff

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 17 Dec 2021 10:32:48 +0100

> On 16 Dec 2021, at 23:35, Dino Farinacci <[email-masked]> wrote:
> 

You touched an important point IMO. We default using globally unique addresses and as long as I have one (even temporarily) I use it for all my communications. 

May be this is one limitation we should explore how to overcome.

I may want to use a locally unique address to communicate with my local devices, where I do not have strong privacy issues because I trust my own devices.
I may want to use an address that allows me to access the local CDN cache to watch a movie and may be I do not care that much if the CDN identifies me with my IP address they already have my credit card number…
I may want a globally unique address so that people can call me to wish me merry Xmass ;-) and at the same time I want my privacy so that ISPs do not know each and every call I receive …

.. and I want all of the above at the same time..

I guess that my point is that we may want to use multiple different addresses, with different properties,  at the same time.
A similar point was made in: https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-addressing-considerations-01.txt <https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-addressing-considerations-01.txt>

Ciao

L. (I know I want a lot of things….:-) )

---

From: Geoff Huston <[email-masked]>
Date: Fri, 17 Dec 2021 18:48:13 +0000

> On 17 Dec 2021, at 9:35 am, Dino Farinacci <[email-masked]> wrote:
> 

I have no idea when I last sent a packet from my client host to any other client host. Somewehere is the massive stream of packets that come from the data centres nearby is a lonesome packet that made its way through. maybe. or maybe not. Such packets are statistically insignificant in volume, and, more importantly, economically insignificant.

This latter observation is the critical one. QoS lost its way in the public Internet because it was obvious that it was costing far more than the marginal revenue it was raising. (It survived in enterprise environment largely because in enterprise environments then network is not treated as an isolated cost centre.)

If all my packets come from highly replicated data centres then all that matters is my endpoint identity (i.e. address) relative to that data centre. A unique global identity is a pointless (and expensive) luxury.

So, to repurpose some graffiti from the 1970’s, we need globally unique addresses like fish need bicycles! :-)

regards,

   Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Dec 2021 08:46:42 +1300

On 18-Dec-21 07:48, Geoff Huston wrote:
...
> So, to repurpose some graffiti from the 1970’s, we need globally unique addresses like fish need bicycles! :-)

They have residual value for surveillance and possibly other forensic uses, which may of course be actively harmful to the user.

But on the other hand, while what you say about economics is undoubtedly true, don't we want to keep the peer-to-peer option open *as a matter of principle*? After all, we still have that option for phone calls, even though it's now a minority usage pattern for mobile devices.

     Brian

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 17 Dec 2021 12:07:04 -0800

Globally unique != static.

They can be randomized and varied over time, e.g., as are Ethernet MAC addresses, exactly for the reasons you note.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Dec 17, 2021, at 11:46 AM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 17 Dec 2021 13:58:19 -0800

> They can be randomized and varied over time, e.g., as are Ethernet MAC addresses, exactly for the reasons you note.

I would agree with that if the time to randomize is basically so small
that a client can use a unique and un-correlatable address for each
connection. Given the data collection abilities and compute resources
available to those that want to engage in surveillance, any time for
randomizing addresses, be it a day, an hour, or a few minutes, that is
greater than this minimum only provides a false sense of security with
respect to trying to prevent third parties from making correlations
about the sender's identity between different flows on the Internet.
Interestingly, CGNAT with enough users behind it can provide these
properties (attested by the fact the law enforcement has complained
about it).

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Dec 2021 11:22:18 +1300

On 18-Dec-21 10:58, Tom Herbert wrote:
>> They can be randomized and varied over time, e.g., as are Ethernet MAC 
addresses, exactly for the reasons you note.
> properties (attested by the fact the law enforcement has complained

If we care about the peer-to-peer property, varying addresses require a rendezvous process based on a non-varying identifier. It's then the latter 
that becomes the handle for surveillance and forensics. The real impact of CGNAT is to push that factoid into surveillance models; it gives IPv4 the same privacy assist that temporary addresses give IPv6.

So perhaps what we need is a surveillance-proof rendezvous mechanism.

    Brian

>> But on the other hand, while what you say about economics is undoubtedly true, don't we want to keep the peer-to-peer option open *as a matter of principle*? After all, we still have that option for phone calls, even 
though it's now a minority usage pattern for mobile devices.

---

From: Geoff Huston <[email-masked]>
Date: Fri, 17 Dec 2021 23:55:12 +0000

> But on the other hand, while what you say about economics is undoubtedly true, don't we want to keep the peer-to-peer option open *as a matter of principle*? After all, we still have that option fo…

How much money are consumers willing to fork out as a premium for a matter of principle? The answer is uncomfortable, I suspect.

I find this world we’ve backed into about as crappy and unpleasant as anyone else on this int-area list, and like many others I wish it were otherwise. But as many folk have said in the past, when assessing where we are and what to do about it, the trick is not in seeing what's around us - everyone sees that. The trick is to believe what we see. The phone companies saw their destruction but simply could not believe it. There are many such examples.

The commercial marketplace, in striving for bigger, faster, and cheaper has simply cut out the network from the picture and is trying to take replicated content as close as it can to the user. The economic imperatives that have driven us to this place are, in retrospect, inescapable. Yes, a lot has been discarded along the way, including every protocol except HTTPS, but the harsh rule is that if not enough consumers are prepared to pay for it, directly or indirectly, then it just doesn't happen any more.

There is innovation happening to return to the subject line of this thread, but the innovation is happening in those places where there is money and a certain impatience to shift things around, and in the last decade or so that is heading up into the world of content and applications. The lower layers, including platform and network are not only commoditised, but steadily ossifying. There is just no money and no desire to shake up these lower layers right now, nor in the immediate to medium term future.

As a network layer person I personally find this a pretty sad situation, and I would like it to be otherwise. But the capital markets don't listen to me. They are busy talking up the content and cloud folk who are busy pushing out replicated content ever closer to the consumer, and they neither care nor value anything else.

Geoff

---

From: Tom Herbert <[email-masked]>
Date: Fri, 17 Dec 2021 16:39:29 -0800

> that becomes the handle for surveillance and forensics. The real impact of CGNAT is to push that factoid into surveillance models; it gives IPv4 the same privacy assist that temporary addresses giv…

Brian,

I believe CGNAT is better than IPv6 in terms of privacy in addressing.
In fact one might argue that IPv4 provides better privacy and security
than IPv6 in this regard. Temporary addresses are not single use which
means the attacker can correlate addresses from a user between
unrelated flows during the quantum the temporary address is used. When
a user changes their address, the attacker can continue monitoring if
it is signaled that the address changed. Here is a fairly simple
exploit I derived to do that (from
draft-herbert-ipv6-prefix-address-privacy-00).

The exploit is:
      o An attacker creates an "always connected" app that provides some
        seemingly benign service and users download the app.
      o The app includes some sort of persistent identity. For instance,
        this could be an account login.
      o The backend server for the app logs the identity and IP address
        of a user each time they connect
      o When an address change happens, existing connections on the user
        device are disconnected. The app will receive a notification and
        immediately attempt to reconnect using the new source address.
      o The backend server will see the new connection and log the new
        IP address as being associated with the specific user. Thus,
the server has
        a real-time record of users and the IP address they are using.
      o The attacker intercepts packets at some point in the Internet.
        The addresses in the captured packets can be time correlated
        with the server database to deduce identities of parties in
        communications that are unrelated to the app.

The only way I see to mitigate this sort of surveillance is single use
addresses. That is effectively what  CGNAT can provide.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 17 Dec 2021 22:16:55 -0500

> If we care about the peer-to-peer property, varying addresses require a rendezvous process based on a non-varying identifier. It's then the latter that becomes the handle for surveillance and forensics. The real impact of CGNAT is to push that factoid into surveillance models; it gives IPv4 the same privacy assist that temporary addresses give IPv6.

Hosts talk to hosts, I don't care if they are in a data center or two clients. You don't have to distinguish and certainly shouldn't design an address algorithm to distinguish.

As for surveliience and privacy, you can't have both. So pick one.

And Luigi, you shouldn't trust the devices that are close to you. Even if you manage them you can't trust the vendors that make them.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 17 Dec 2021 22:19:05 -0500

> As a network layer person I personally find this a pretty sad situation, and I would like it to be otherwise. But the capital markets don't listen to me. They are busy talking up the content and cl…

I feel the same way and have for almost 2 decades. That is the reason I focus new designs and use-cases using overlays because it is easier to control the application edge and just assume the underlay can never and will never change for the new use-cases.

Dino

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 18 Dec 2021 10:00:51 +0000

> I have no idea when I last sent a packet from my client host to any other client host. 

I can give two examples from the world of amateur (ham) radio:

I used echolink (VoIP) to a local repeater.

I received DX Cluster spots (reported observations of interesting stations) from a service provided by a local amateur.

However I completely accept that there is no economic foundation for these services and the design of these services is legacy.

Try as hard as I might I cannot think of any non-local service that I use that is fully peer-to-peer outside the sphere of amateur radio, which is itself a communications interest.

I can see compelling economic reasons for the development of the Internet in the direction that Geoff describes. The services I described above do not fundamentally require the 40 year peer to peer internet architecture and can/would migrate to another design if economics required it. Indeed in the latter case web hosted alternative services emerged some years ago.

What is important is that we play the cards we are dealt not the ones we were dealt in the last game. In other words we need to design for the Internet as it will be, not the Internet we designed before and not the Internet that we would wish for but which is not economically viable.

- Stewart

---

From: Hesham ElBakoury <[email-masked]>
Date: Sat, 18 Dec 2021 02:50:26 -0800

Is the final conclusion from the discussion in this thread that features
innovation in the future is in the application not the network ?

Thanks
Hesham

On Sat, Dec 18, 2021, 2:01 AM Stewart Bryant <[email-masked]>
wrote:

> I received DX Cluster spots (reported observations of interesting
> stations) from a service provided by a local amateur.
>
> However I completely accept that there is no economic foundation for these
> services and the design of these services is legacy.
>
> Try as hard as I might I cannot think of any non-local service that I use
> that is fully peer-to-peer outside the sphere of amateur radio, which is
> itself a communications interest.
>
> I can see compelling economic reasons for the development of the Internet
> in the direction that Geoff describes. The services I described above do
> not fundamentally require the 40 year peer to peer internet architecture
> and can/would migrate to another design if economics required it. Indeed in
> the latter case web hosted alternative services emerged some years ago.
>
> What is important is that we play the cards we are dealt not the ones we
> were dealt in the last game. In other words we need to design for the
> Internet as it will be, not the Internet we designed before and not the
> Internet that we would wish for but which is not economically viable.
>
> - Stewart
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 18 Dec 2021 09:04:15 -0500

I don’t know. I haven’t read the details. And is what he is proposing spec’ed with protocol details? The devil (and reality) is in the details (and then there are years of deployment details to contend with). 

Dino

> On Dec 18, 2021, at 5:50 AM, Hesham ElBakoury <[email-masked]> wrote:
> 
> 
> Is the final conclusion from the discussion in this thread that features innovation in the future is in the application not the network ?
> 
> Thanks
> Hesham
> 
>> On Sat, Dec 18, 2021, 2:01 AM Stewart Bryant <[email-masked]> wrote:
>>

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 18 Dec 2021 09:05:54 -0500

> Is the final conclusion from the discussion in this thread that features innovation in the future is in the application not the network ?

I don’t think there is a binary answer (or question). Innovation comes in many forms but I can conclude it’s happening faster at the app layer. 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 18 Dec 2021 09:49:04 -0500

Let’s just see if the Gen-Z, web3.0, blockchain, and metaverse generation can make pure decentralized peer-to-peer come to reality. 

Dino

> On Dec 18, 2021, at 5:00 AM, Stewart Bryant <[email-masked]> wrote:
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Dec 2021 08:50:56 +1300

On 18-Dec-21 23:00, Stewart Bryant wrote:
...  
> What is important is that we play the cards we are dealt not the ones we were dealt in the last game. In other words we need to design for the Internet as it will be, not the Internet we designed b…

I don't think that helps. We don't have an accurate crystal ball, any more than our predecessors did in the late 1970s. They designed a network that was peer-to-peer at the network layer *and* that was cheaper to implement and operate than various alternatives (such as X.25, ISDN, and ATM). Capitalism took that and ran with it, producing an Internet with increasingly concentrated services at the application layer but still peer-to-peer at the packet level; it's just that application services are peer-to-service-to-peer. I have no idea whether anybody predicted that in the 1970s, but most people didn't.

Unless crystal ball technology has improved since the 1970s, I don't see how we will predict "the Internet as it will be".

If we think that services will continue to predominate, we could focus on that, but it might be a completely wrong guess.
https://datatracker.ietf.org/doc/draft-jiang-service-oriented-ip/
https://doi.org/10.1109/INFOCOMWKSHPS50562.2020.9162749

Regards
      Brian

---

From: Tom Herbert <[email-masked]>
Date: Sat, 18 Dec 2021 14:13:05 -0800

> As for surveliience and privacy, you can't have both. So pick one.

Dino,

>From a user perspective, the choice is clear: privacy and security are
top requirements. We know that payload encryption goes a long way, and
hopefully encryption of the transport layer headers will become
dominant so that intermediate nodes will stop meddling and ossifying
the transport layer. But not everything can be encrypted, the IP
addresses for instance, so providing real security and privacy at the
plaintext network layer should be on the list of features to support
user requirements.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 18 Dec 2021 17:34:49 -0500

> plaintext network layer should be on the list of features to support

Definitely agree Tom. 

But what if we sent a packet where the source address was encrypted? Then you could have global unique addresses (if you wanted them). Of course key exchange and rekeying parameters would have to be setup prior to sending a single packet.

Maybe its just simpler to randomize addresses.

Dino

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Dec 2021 11:47:24 +1300

> But what if we sent a packet where the source address was encrypted? Then you could have global unique addresses (if you wanted them). Of course key exchange and rekeying parameters would have to b…

It's called SNA (Sourceless Network Architecture):
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf

    Brian

---

From: Hesham ElBakoury <[email-masked]>
Date: Sat, 18 Dec 2021 15:04:46 -0800

There is also this thesis: A better  Internet without IP addresses
https://web.cs.wpi.edu/~cshue/research/dissertation_web.pdf

Hesham

On Sat, Dec 18, 2021, 2:47 PM Brian E Carpenter <[email-masked]>
wrote:

> > But what if we sent a packet where the source address was encrypted?
> Then you could have global unique addresses (if you wanted them). Of course
> key exchange and rekeying parameters would have to be setup prior to
> sending a single packet.
>

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 18 Dec 2021 19:17:25 -0500

That’s different Brian. That is a packet header without a source address. Which “could” change the format (or if one decides at the same time to have the destination address 256 bits long). 

I was roughly suggesting using the IPv6 header, as is, and just scramble the source address bits.

Dino

> On Dec 18, 2021, at 6:05 PM, Hesham ElBakoury <[email-masked]> wrote:
> 
> 
>> On Sat, Dec 18, 2021, 2:47 PM Brian E Carpenter <[email-masked]> wrote:

---

From: Dirk Trossen <[email-masked]>
Date: Mon, 20 Dec 2021 09:35:06 +0000

Jumping into this late (due to a few days off), see inline.

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: 18 December 2021 20:51
To: Stewart Bryant <[email-masked]>; Geoff Huston <[email-masked]>
Cc: [email-masked]
Subject: Re: [Int-area] Where/How is the features innovation happening?

I don't think that helps. We don't have an accurate crystal ball, any more than our predecessors did in the late 1970s. They designed a network that was peer-to-peer at the network layer *and* that was cheaper to implement and operate than various alternatives (such as X.25, ISDN, and ATM). Capitalism took that and ran with it, producing an Internet with increasingly concentrated services at the application layer but still peer-to-peer at the packet level; it's just that application services are peer-to-service-to-peer. I have no idea whether anybody predicted that in the 1970s, but most people didn't.
[DOT] We may not have a crystal ball, indeed, but there are aspects that outline a desired path forward, termed 'principles'. To what end those principles will be used may be a different matter but they do provide a stake in the ground when moving ahead from them. 

Unless crystal ball technology has improved since the 1970s, I don't see how we will predict "the Internet as it will be".
[DOT] So if we conclude (somehow) the discussions in previous contributions, the P2P nature of communication between hosts seemed to have been a crucial principle that was considered in the addressing (and routing) work?! Whether it is host->host or host->service->host (as we may see predominantly in today's communication) is somewhat irrelevant from that principle's perspective, is it not? 

[DOT] If we now observe an increase in host->service->host communication, we may wonder how to possibly better support this pattern, not just in the light of the economically driven centralization of that model but also keeping the more P2P-driven principle alive in realizing host->service->host communication? There is work providing answers to this question albeit more aligned with the predominant centralized service provisioning model (see https://dl.acm.org/doi/pdf/10.1145/3452296.3472922 for one such answer).

[DOT] Key question here may be what 'service' is of importance, particularly to the end user? The draft below provides some answers BUT...

[DOT] from reading through the draft, the realization of the SAT seem (to me) to imply a rather significant semantic knowledge at the 'SOIP dispatcher' role - or am I missing something? Also referencing back to my question on what 'service' constitutes, the draft seems to span from 'network service' to higher layer services, which links back into the 'dispatcher complexity' question before. Can we have something simpler? Also, can there be a stronger combination of (existing) IPv6 routing and service routing (also for efficiency purposes), e.g., for supporting affinity of longer-running transactions?

Regards
      Brian

---

From: Dirk Trossen <[email-masked]>
Date: Mon, 20 Dec 2021 09:43:52 +0000

Just as a thought: how much is this discussion led by the use of Internet technologies for the public Internet vs use of Internet technologies for non-public use or limited domains (or even something we may consider future versions of the 'public internet')? In other words, is this trend to centralization similar in other emerging areas for use of Internet technologies? If not, we may just be in danger of pushing the underlying technologies into a direction where they may become less relevant for realizing those new use cases. 

Take autonomous driving: my understanding here is that while today's car OEMs still rely on centralized cloud provisioning, this model is increasingly questioned when moving to L5 autonomous driving, possibly requiring a much more P2P view on service interactions (i.e., it may either be host->host, here to car-to-car, or host->service->service but with severely localized service instances). 

So should our current view of the economic realities (in the largely consumer-facing content market) really drive the foresight for where to go in terms of network technologies?  

Dirk

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Geoff Huston
Sent: 18 December 2021 00:55
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]
Subject: Re: [Int-area] Where/How is the features innovation happening?

Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Dec 2021 09:03:21 +1300

> [DOT] from reading through the draft, the realization of the SAT seem (to me) to imply a rather significant semantic knowledge at the 'SOIP dispatcher' role - or am I missing something?

No, that's correct, and the idea would need a lot more work to turn it into reality. It could be that the dispatcher would really be a policy engine ("User wants search, policy => DuckDuckGo"). The main point is: what happens if we no longer think of the destination address being the primary invariant for routing a packet?

> Also referencing back to my question on what 'service' constitutes, the draft seems to span from 'network service' to higher layer services, which links back into the 'dispatcher complexity' question before. Can we have something simpler? 

When you look at the raw HTML of a typical web page today, you quickly realise where the real complexity is today. So I think the real question is where to set the boundary between reasonably simple (like an IP address) and too complex for line speed processing. It's clearly a moving boundary, e.g. RFC8986.

> Also, can there be a stronger combination of (existing) IPv6 routing and service routing (also for efficiency purposes), e.g., for supporting affinity of longer-running transactions?

I don't know. Carrying a transaction identifier at layer 3 sounds like an attractive idea, but our experience with the IPv6 flow label isn't encouraging.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Dec 2021 21:28:12 +0100

Le 18/12/2021 à 23:47, Brian E Carpenter a écrit :
>> Then you could have global unique addresses (if you wanted them). Of 
>> course key exchange and rekeying parameters would have to be setup 
>> prior to sending a single packet.
> 

Wasnt SNA an IBM acronym for an architecture?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Dec 2021 21:42:01 +0100

Le 18/12/2021 à 15:49, Dino Farinacci a écrit :
> Let’s just see if the Gen-Z, web3.0, blockchain, and metaverse 
> generation can make pure decentralized peer-to-peer come to reality.

I would say too to look at these ^ directions.

It might be that we head towards a world where most things are 'siloed'
and the universal one-to-one connections from anybody to anybody
anywhere will be the advantage of a willing few.  Each one of these few
might need to tresspass a local rule in order to be able to reach to
anyone else out there.  That might be too much effort.

It is harder and harder to do a telnet to any site out there, or to ftp
any file from anywhere these days, without first accepting some cookie,
then overthinking whether the contents are appropriate without hurting
someone's feeling, whether the content corresponds to reality, and then
not worry whether or not a password was stolen, or traffic analyzed,
whether a legislation allows or not that key length, and whether that
other country might break these other lengths at their will.

blockchain-based money is favoured in certain places and disfavoured in
others.  So despite its pretension of being an 'escape', it is actually
a silo.  It is used by certain countries to escape monetary systems they
believe wrong, but as such they become 'silo'ed.

metaverses are places where people can meet, but only _some_ people:
those who can afford enough bandwidth and compute power.  So they are
metaverse siloes.  There are no metaverses for those with little such
power.

The generations themselves that are mentioned are the generations of
young, who form another 'silo'.  The less younger dont use or need these
things.

In that sense, these directions are just other siloes.

To makepure decentralized peer-to-peer come to reality there is a need
to do some things, but I dont know which ones.

If it happens, then there will be signs.

For example, a sign would be: the Internet would be simple and safe to
use in confidence, again.  Maybe that will happen again some day, at the
next round of leisure time.

Alex

>> However I completely accept that there is no economic foundation 
>> for these services and the design of these services is legacy.
>> 
>> Try as hard as I might I cannot think of any non-local service that
>> I use that is fully peer-to-peer outside the sphere of amateur
>> radio, which is itself a communications interest.
>> 
>> I can see compelling economic reasons for the development of the 
>> Internet in the direction that Geoff describes. The services I 
>> described above do not fundamentally require the 40 year peer to 
>> peer internet architecture and can/would migrate to another design
>>  if economics required it. Indeed in the latter case web hosted 
>> alternative services emerged some years ago.
>> 
>> What is important is that we play the cards we are dealt not the 
>> ones we were dealt in the last game. In other words we need to 
>> design for the Internet as it will be, not the Internet we designed
>> before and not the Internet that we would wish for but which is not
>> economically viable.
>> 
>> - Stewart
>> 
>> 
>> 
>

---

From: Dirk Trossen <[email-masked]>
Date: Tue, 21 Dec 2021 09:46:57 +0000

Brian,. 

See inline.

Dirk

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: 20 December 2021 21:03
To: Dirk Trossen <[email-masked]>; Stewart Bryant <[email-masked]>; Geoff Huston <[email-masked]>
Cc: [email-masked]
Subject: Re: [Int-area] Where/How is the features innovation happening?

No, that's correct, and the idea would need a lot more work to turn it into reality. It could be that the dispatcher would really be a policy engine ("User wants search, policy => DuckDuckGo"). The main point is: what happens if we no longer think of the destination address being the primary invariant for routing a packet?
[DOT] I do like your last question as a starting point! The question may then become one on how to formulate the policies (for the SATs). Also, could SATs be rather explicit service identifiers? If one wants to position a dispatching over a group of services, it is merely a service itself, identified through its service identifier but then directing to a more specific service as a result of the (service) chaining process. This would generalize the SATs, also removing the need to agree on them (I read SATs as something that would need IANA assignment but maybe I got this wrong). 

When you look at the raw HTML of a typical web page today, you quickly realise where the real complexity is today. So I think the real question is where to set the boundary between reasonably simple (like an IP address) and too complex for line speed processing. It's clearly a moving boundary, e.g. RFC8986.
[DOT] Indeed, see also my point above on what is being identified.

I don't know. Carrying a transaction identifier at layer 3 sounds like an attractive idea, but our experience with the IPv6 flow label isn't encouraging.
[DOT] I'm thinking along the lines of using service identification for the initial routing to a computational instance realizing the desired service, using but using IP routing for sustaining the affinity throughout. This would move the service initiation onto the IP routing path once the original decision which instance to be used has been made. 

    Brian

---

From: tom petch <[email-masked]>
Date: Tue, 21 Dec 2021 09:52:55 +0000

From: Int-area <[email-masked]> on behalf of Alexandre Petrescu <[email-masked]>
Sent: 20 December 2021 20:28

<tp>

Silly Names and Acronyms
as I recall; YMMV

Tom Petch

Alex

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 22 Dec 2021 23:10:29 +0100

> And Luigi, you shouldn't trust the devices that are close to you. Even if you manage them you can't trust the vendors that make them.

Fair enough. And if we push this further I cannot trust the very device I am using to write this mail. ;-)

Revising the trust model was/is discussed in the model-t program lead by Jari. I am not familiar with that work, but is certainly worth looking at it.

Ciao

L.

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 22 Dec 2021 23:22:53 +0100

> On 18 Dec 2021, at 04:19, Dino Farinacci <[email-masked]> wrote:
> 
> 
>> 

This is certainly true. However, one of the points we are trying to make in the gap analysis document is that in a lot of use-cases (with or without overlays) extensions have been designed to overcome some limitations of the underlay. 
The document focuses only on addressing but the same can be said for other parts/aspects of the Internet architecture. Anyway, these extensions are there to fill gaps, which in turn means that some form of evolution is desirable.
Hence the drafts and these threads, to well formulate the problem and what is desirable, so that at some point we can start to tackle the problem.

Ciao

L.