Subject: Re: [arch-d] [Int-area] Continuing the addressing discussion: what is an address anyway?

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Jan 2022 07:24:31 +0100

[copy architecture-discuss]

Geoff,

This is a pretty good characterization.  In fact, it's exactly where we 
went in the NSRG nearly 20 years ago, just after MO first kicked out 
8+8.  For people's reference, we looked at naming at different levels, 
including at L3, in DNS, URNs (which were relatively new things then), 
HIP, etc.  There were then several efforts in both the IRTF and IETF to 
deal with portability of connectivity in transport.  I think QUIC gets a 
lot of that right.  QUIC – at least at the moment – as some limitations 
for local use (either you have certs or some sort of prearranged 
bidirectional authentication).  I think it's a fair engineering 
assumption that those will be kinked out.

With all of that having been said, I go back to Dirk's note: what 
properties do we need at L3?

  * If QoS is still a thing, then admission control has to be part of
    the story.
  * There is a tussle between endpoint privacy and the endpoint itself
    being a threat.  In the latter case, the endpoint has to be
    identified.  But to whom?

As you describe, a lot of routing has moved up a layer.  Sort of.  But 
not all.  CDNs need to be well aware of topology, and that comes from 
L3, perhaps with additional OOB info.

So... what's missing from L3 at this point that we need, and is it even 
a good question to ask?  I ask that because I have seen recently a 
retrenching AWAY from IPv6.  If that is happening, what makes us think 
that any new L3 beyond IPv6 would ever get adopted?  OR... what is 
missing from IPv6 that would cause people to move?

Eliot

On 25.01.22 12:38, Geoff Huston wrote:
>
>> On 25 Jan 2022, at 6:19 pm, Dirk Trossen<dirk.trossen=[email-masked]>  wrote:
>>
>> All,
>>   
>> Thanks for the great discussion, following our side meeting at IETF 112, so far.
>>   
>> I wanted to turn the discussion to a key question which not only arose in the side meeting already but also in the discussions since, namely “what is an address anyway?”.
>>   
> In this world of NATs it seems that we treat addresses as no more than temporary ephemeral session tokens and we've passed all the heavy lifting of service identification over to the name system. These days you and I could be accessing the same service yet we could b e using entirely different addresses to do so. Or I could be accessing the same service at different times, and again be using different addresses each time. I find it somewhat ironic that we see increasing moves to pull in IP addresses as part of the set of personal information in some regulatory regimes, yet what the larger network sees of end clients is a temporary NAT binding to a public address that may be shared by hundreds if not thousands of others.
>
> And IPv6’s use of privacy addressing achieves a similar outcome in a different way. And QUIC’s use of the session token inside the encrypted envelope even makes the binding of an address to a single session fluid, as the same QUIC session can be address agile on the client side.
>
> So perhaps an address these days is just an ephemeral transport token and really has little more in the way of semantic intent.
>
> Geoff
>
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 26 Jan 2022 10:36:00 -0500

I wade in here with more than a little trepidation, especially with my “ICN taint” where there are no classic “flows” and in fact no source addresses to apply semantics to, and only weak notions of destination addresses in the sense that content names at layer 3 may have a binding only to a single location in the network because that’s what you wanted when you constructed the name.

After reading the semantic routing docs, I am still befuddled about why one would want this capability in an underlay when it is already very common to employ a level of indirection by recursing at layer 3 to construct flexible overlays. One might want semantics other than an attachment point in an overlay, but we already have that, and can similarly recurse existing routing protocols to construct the desired topologies. So, I’m in the uncomfortable position of not seeing the need for any of this either as a native IP capability, nor going forward as an alternative to architectures like ICN which natively provide flexible semantics through the use of hierarchical or attribute-based names at L3.

If the goal is to try to decouple the IPv6 packet format from conventional notions of forwarding and routing, given the movement toward user-programmable switches and routers, we can do that without introducing the notion of semantic routing. As a extreme endpoint of this argument, consider the following:

- Programmable switches can do match operations on any set of contiguous bit fields in a packet if they are in the first 256 bytes of the incoming buffer.
- The extracted and matched bit fields can be used as input to a lookup table, or a cascaded sequence of lookup tables, or even something with FSM computation as long as the cycle count and memory accesses are highly limited.

Given this, there is no need, other than for standards compatibility, to assign any fixed semantics to ANY of the fields in an IPv6 packet, be they the “addresses”, the hop limit, ports, or anything else. In fact it may be that the **only** thing about the overall packet structure that demands precise standardization is how you demultiplex incoming frames/packets to the program that is assigned to handle them. Then if you don’t want to have source addresses and want to treat the concatenation of SA/DA (in any order or even segmented in pieces) as one single key to the forwarding operation, that’s just fine.

In this “endgame”, both routing and forwarding is simply defined by the program (or programs) you load in the devices. There’s no need to have conventional “protocol standards” beyond agreement among packet generators and packet parsers as to what the format of the packet is. IPv6 is just fine for this - there are enough bits to do a lot of stuff, even ICNish stuff as we’ve seen with the hICN effort (https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/)

I don’t intend this as a flame; I’m seriously skeptical of the utility of using protocol standards as a way to achieve different routing functionality given where the technology is today and where it’s moving.

DaveO.

On 26 Jan 2022, at 1:24, Eliot Lear wrote:

> This is a pretty good characterization.  In fact, it's exactly where we went in the NSRG nearly 20 years ago, just after MO first kicked out 8+8.  For people's reference, we looked at naming at different levels, including at L3, in DNS, URNs (which were relatively new things then), HIP, etc.  There were then several efforts in both the IRTF and IETF to deal with portability of connectivity in transport.  I think QUIC gets a lot of that right.  QUIC – at least at the moment – as some limitations for local use (either you have certs or some sort of prearranged bidirectional authentication).  I think it's a fair engineering assumption that those will be kinked out.
>
> With all of that having been said, I go back to Dirk's note: what properties do we need at L3?
>
> As you describe, a lot of routing has moved up a layer.  Sort of.  But not all.  CDNs need to be well aware of topology, and that comes from L3, perhaps with additional OOB info.
>
> So... what's missing from L3 at this point that we need, and is it even a good question to ask?  I ask that because I have seen recently a retrenching AWAY from IPv6.  If that is happening, what makes us think that any new L3 beyond IPv6 would ever get adopted?  OR... what is missing from IPv6 that would cause people to move?
>
> Eliot
>

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

---

From: Geoff Huston <[email-masked]>
Date: Wed, 26 Jan 2022 19:34:50 +0000

> On 26 Jan 2022, at 5:24 pm, Eliot Lear <[email-masked]> wrote:
> 
> 	• If QoS is still a thing, then admission control has to be part of the story.
> 	• There is a tussle between endpoint privacy and the endpoint itself being a threat.  In the latter case, the endpoint has to be identified.  But to whom?

Hi Eliot,

Thanks for your thoughtful response.

In my mind “What is the role of IP addresses in today’s Internet?” and “What properties / semantic role do we need from, or implicitly assume, from IP addresses” are quite distinct questions.

Some brief background (which I am sure you are aware of, but to help me organise my thoughts, and possibly for the benefit of others on this list):…

Its pretty clear that we commenced down the road of re-casting the role of IP addresses at about the same time as we started down the track of consumer deployment via dial-up ISPs. We introduced the notion of time-shared addresses, where the IP address you got was temporal for the life of the connection, and we subsequently introduced the notion of port-based address sharing via NATs. I don't think issues of impending scarcity wewre the predominate driving factors here - I think it was a more mundane issue of cost transfer to the consumer. i.e. from the ISP’s perspective we headed donw the shared address road becuase it was cheaper for the industry at the time to do so.

At around the same time (late 80’s early 90’s) we heading down the “running out of addresses” path which ultimately lead to the design of IPv6.

It is useful here to contrast the differences in these two approaches - the latter was an IETF-led command-and-control effort that attempted to anticipate future industry needs and produce a technology that would meet these needs. On the other hand the industry was being driven by two imperatives, one unchecked demand that completely swamped any efforts to satiate it (we were building as fast as we could, not as fast as consumers wanted), and the imperative to strip cost. 

The recasting of the role of addresses was not a particularly deliberative process then, or now. It was an industry response to the prevailing conditions, and in a deregulated market-based activity that’s the only driving factor out there. 

If we are going to repeat the IPv6 exercise and attempt to second-guess the future market for the means of delivery of digital artifacts to consumers, then I guess we need to understand what is driving this industry today and in the near future. It appears to be true that CDNs feature big time right now. If you include video streaming data then I have heard figures of between 70% to as high as 90% of all delivered data being video streaming (No, I have not seen good public data to confirm these mutterings - I wish I did!). It also appears that enterprise network demand is morphing into the same CDNs as cloud services. The shared public network and its infrastructure is being marginalised (and privatised).

You raise the ghost of QoS in your message. I am reminded of Andrew Odlzyko’s (http://www.dtc.umn.edu/~odlyzko/) arguments at the time: the cheapest way to provision QoS for your customers is to buy more transmission capacity. True then. True today. CDNs exploit today’s environment of abundance of computing and storage to eliminate distance in communications. By bringing content and service under the noses of consumers we eliminate the cost and performance issues of accessing remote services. The service outcomes are faster, cheaper and generally more resilient in the CDN world. The “public” world is now in the throes of the death of transit and the public network has shrunk to the last mile access network. Why? Ultimately the answer is "It's cheaper this way!”. The industry is not going to head back to the rationing world of QoS anytime soon, if ever, in my opinion.

So why do we even need unique addressing any more? Surely all I need to do is to distinguish myself from the other clients in the service cone of my local CDN. Why do I need to use an addresses that distinguishes me form the other billions of client endpoints? Is it for the few residual applications that have not yet been sucked into the CDN world? The issue here is that uniqueness costs. And why should I spend a disproportionate amount of resources to support a function used by a residual trace amount of traffic? Sooner or later I will cut out that cost and not do it any more. As the CDN’s continue to exploit the abundance of computing and storage the current shift of more points of presence positioned ever closer to the end clients will continue.

There is also a second factor, that of sunk cost. Nobody wants to pay to upgrade existing infrastructure. Nobody. So those who want to change things build around, over and tunnel through existing infrastructure. In a deregulated world where piecemeal uncoordinated actions predominate, the level of coordination and orchestration required to uplift common shared infrastructure is simply impossible. We say to ourselves that we outgrew flag days on the Internet many decades ago, and thats true, but at times we appear not to understand precisely what that implies about today. We have built an application-based superstructure of encapsulated tunnels in the network (QUIC) that neatly circumvents the entire question of infrastructure renewal. Whereas IPv6 has been head-butting against the sunk cost of existing infrastructure for more than two decades then dramatic rise of QUIC, BBR, SVCB and HTTPS, and similar application-level technologies attests to the application world’s extreme distaste to engage with the existing infrastructure.

For me the question is not about IPv6 any more - that is largely a question whose answer really has little of industry relevance to offer. The question is more about the CDN world and the way applications create their own environment in a manner that is as disengaged and isolated from the underlying infrastructure as possible. (and if you think about it that is a pretty exact replay of the way IP’s stateless packet-based hop-by-hop forwarding treated the circuit-switched telephone infrastructure a few decades ago! What goes around, comes around!).

Then, as now, the issue was NOT “What’s the answer?” but “Whats the right question to ask?” - at least for me.

regards,

   Geoff

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 27 Jan 2022 07:51:32 +0000

Hi Geoff,

Thanks for the thoughts below, which is much aligned with previous interactions on the development of the current Internet. Please see inline.

Best,

Dirk

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Geoff Huston
Sent: 26 January 2022 20:35
To: Eliot Lear <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

Hi Eliot,

[DOT] I agree that understanding the 'now' is important but I wonder if this was the dominant thinking that led the development of the Internet? I think we can dig out similar 'status quo' type of observations around the same time when the stake of IP-based communication was put in the ground (I wonder what the service with similar traffic numbers was back then). Was the point of IP(v4 or v6 alike) to "second-guess the future market", as you put it, or to specifically avoid locking oneself into one way of 'doing communication' (if the latter had been the basis in the 70s, how come that IP came around instead of continuing to optimize the then status-quo?)? 

[DOT] But more importantly, should the 'doing communication' aspect (the technology behind it) be skewed towards a particular economic model and technological realization? Key here is, to me, that the Internet specifically wants (and has been wanting) to avoid such lock-in as an aspect of permissionless innovation that is not built on a technological foundation that is skewed to the dominant economic model of the time. I would argue that the model you observe today is an outcome of that idea, not an accident in the light of what may be read as a futile 'second guessing' exercise. 

So why do we even need unique addressing any more? Surely all I need to do is to distinguish myself from the other clients in the service cone of my local CDN. Why do I need to use an addresses that distinguishes me form the other billions of client endpoints? Is it for the few residual applications that have not yet been sucked into the CDN world?

[DOT] Wasn't the Internet one of the 'few residual applications' that wasn't adequately served by the model at the time? So yes, *I* do want it for the few residual applications NOT being hosted in a CDN. Why? Because the most dominant application (for some, for me, maybe even for most) in a few years may be JUST that residual application. Do I know? Well, would I have guessed that people spent tons of time uploading selfies of themselves in front of landmarks I can see properly due to their large faces in the way?

 The issue here is that uniqueness costs. And why should I spend a disproportionate amount of resources to support a function used by a residual trace amount of traffic? Sooner or later I will cut out that cost and not do it any more. As the CDN’s continue to exploit the abundance of computing and storage the current shift of more points of presence positioned ever closer to the end clients will continue.

[DOT] Much of your statement do remind me of 'nobody wants to change' arguments heard elsewhere, not just in the communication industry. I fear that the Internet's in danger of experiencing the innovator's dilemma that has befallen so many other industries and their players before. Repeating arguments that may well have been formulated the last time around is one aspect of it. The question comes down to what the IETF feels should be its role in facilitating innovation beyond what we can see today. Maintain and improve (engineering towards) the status quo? More importantly, should this role also guide its thinking towards the future?

[DOT] You may notice that this question was asked as the third in a series of questions on the INTArea list, starting with 'what do we want from the network', which may be closer to what you consider the 'right' question?

regards,

   Geoff

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 27 Jan 2022 12:02:01 +0100

Hi Geoff, Dirk, 

I  wanted to add a couple of comments on your excellent points, see inline.
 (trimmed a little bit of the text)

Ciao

L.

> On 27 Jan 2022, at 08:51, Dirk Trossen <dirk.trossen=[email-masked]> wrote:
> 

[snip]
> There is also a second factor, that of sunk cost. Nobody wants to pay to upgrade existing infrastructure. Nobody. So those who want to change things build around, over and tunnel through existing i…

This last point is tackled in the current set of documents and also touched in the previous thread (but can certainly be improved upon this thread).
I think that we are at the stage that _no_ there is no strong reason yet to upgrade the existing infrastructure (we do not even know to what to upgrade). However, the innovation is there and is happening, raising the question:

- Up to what point we can “build on top” without risking to jeopardize the whole?  

In the long run, up to what point we can continue the way we are solving problems today? Seeing this as a possible risk, I would prefer to discuss now about what can be done (including the “is it worthwhile?” question). Up to us to answer this tough question and engineer an improved architecture that provide sufficient  benefits to be adopted in less time that IPv6 adoption.

[snip]
> Then, as now, the issue was NOT “What’s the answer?” but “Whats the right question to ask?” - at least for me.

Isn’t what we are trying to do here? ;-)

I think that the discussions happening in the INTArea mailing list are very fruitful. We just need to capture the current understanding in the documents, trying to formalize the problem we face.

As other already mentioned there is an architectural discussion to be made (and happy that the architecture discuss mailing list is in this thread), but we need to start somewhere and addressing is a good starting point.

What we need is to gather the experience each and everyone of us can provide in order to shape something meaningful to move forward…..  starting from the addresses ;-)

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 27 Jan 2022 14:12:07 +0100

Dave,*:

On Wed, Jan 26, 2022 at 10:36:00AM -0500, David R. Oran wrote:
> After reading the semantic routing docs, I am still befuddled about why one would want this capability in an underlay when it is already very common to employ a level of indirection by recursing at layer 3 to construct flexible overlays.

"why one would want this capability"  sounds like equally applicable to ICN then,
aka: why have any other semantic than "unicast/anycast" ? Given how i assume you
continue to believe in ICN, i think the very same answer could be given for
other semantics. 

I for once never thought that the "one semantic fits all" approach was very useful.
When ICN initially was pitched for content, it made a lot of sense to me. When
it was pitched to become the one-semantic-fits-all to replace unicast packet
forwarding (IP), i felt this was again one of those theoretical attempts to replace
something quite well suited to the task (IP unicsat) with something more complex
as opposed to figure out what a beneficial and necessary set of semantics in the
network are that you want to build concurrently.

When we started to have DoS attacks over the Internet in the 90th/2000th because of
address spoofing or other undesired traffic, i always joked that one could
easily get rid of IP unicast in the Internet and just use IP Multicast/SSM,
just with a single receiver. Given how that is join based from the receiver,
there would never be these IP unicast attack vectors. So obviously much better ;-).
But of course, joking because of the much higher underlying forwarding/state
complexity.  ICN on the other hand didn't seem to be just joking.

> One might want semantics other than an attachment point in an overlay, but we already have that, and can similarly recurse existing routing protocols to construct the desired topologies. So, I’m in the uncomfortable position of not seeing the need for any of this either as a native IP capability, nor going forward as an alternative to architectures like ICN which natively provide flexible semantics through the use of hierarchical or attribute-based names at L3.

If you go to IEEE 802.1, then IP is an overlay. So it just depends
on where you're coming from. Of course, application developers will
build multi-hop forwarding logic nowadays most likely on URLs, as
we also see in IoT (MQTT andd any othrer type of buses / forwarding
meshes). 

Designing semantics at "L3" i think is a great compromise between
eliminating link-player specifics and avoiding creating dependencies
against application specific. Aka: best / broadest reuseability
(including software...high-speed hardware implementations) and 
applicability.

Of course, you can build one new L3 semantic as an overlay on a
different semantic L3, and that should by now be a day 1 consideration
for any new semantic - as opposed to ICN where AFAIK it came way to
late in the game, even though we already learned the native vs.
overlay lesson from IP multicast in the 90th - and started to
re-build overlay components (AMT) as early as 2001.

Building L3 solutions that with as little as possible effort
allow themselves to be deployed hybrid overlay vs native is still
IHMO a broadly unresolved issue. Everybody faced with on instance
to build out comes up with their own cut between automation and
nerd-knobs.

But in the end, the overlay vs. native issues is IMHO orthogonal
to the definition of appropriate/useful semantics.
> - The extracted and matched bit fields can be used as input to a lookup table, or a cascaded sequence of lookup tables, or even something with FSM computation as long as the cycle count and memory…

It would be great if we could drive these considerations into some type
of guideline RFCs that defines what is and what is beyond reasonable
expectations of what todays forwarding planes are supposed to be able to
do. For example i think we still do have differences of opinions between
vendors whether or not a particular sized chain of TLV is or is not
feasible (assuming they are in the first 256 bye). Applicable to the
question of IPv6 extension header chains or actual parameter TLV inside
an extension header.

I for once would love if we had something like an IETF forwarding plane
reference pseudocode machinery embodying the capabilities and limitations,
such that one would simply need to write the desired forwarding code
in that machine spec to avoid the ongoing bickering we otherwise have
about what type of forwarding plane extension is or is not apropriate.

> Given this, there is no need, other than for standards compatibility, to assign any fixed semantics to ANY of the fields in an IPv6 packet, be they the “addresses”, the hop limit, ports, or anythin…

It certainly would help if every "user" who wants a new/improved
semantic could easily get that as a programmable slice hop-by-hop
onto a programmable switch network such as a metropolitan size
SP network. I think there are a couple of more issues than what
you describe though:

1. the actual actions you can drive from the parsed packet header,
  e.g.: QoS via programmable PIFO, EIFO or the like

2. The problem of high-speed forwarding cost effectiveness.
  For this one, i think as much as possible standardization
  of packet headers help (similar to evolving from VM to containers).
  Aka: someones new semantic header would clone&extend/modify a common
  header, so each slice program only needs deltas, and over time
  more broadly used deltas would be merged.

> In this “endgame”, both routing and forwarding is simply defined by the program (or programs) you load in the devices. There’s no need to have conventional “protocol standards” beyond agreement amo…

Well, the IPv6 base header with 2 * 128 bit addresses and 8 bit QoS
is a kind of painful red herring. I just remember 2? painfull
years when we (then Cisco) tried to figure out how to make use
of those bits for BIER so as to not see them go to waste. 

> I don’t intend this as a flame; I’m seriously skeptical of the utility of using protocol standards as a way to achieve different routing functionality given where the technology is today and where…

I just think your thinking is more programming bottoms up, as
has been mine. The semantic view is a bit more top down. Both
are required IMHO, and the interesting place is where those meet.

Cheers
    Toerless

-- 
---
[email-masked]