Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 2 Dec 2021 22:08:20 +0000

Your diagram is missing a critical layer – the adaptation layer.

From: Int-area [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Thursday, December 02, 2021 1:05 PM
To: Stewart Bryant <[email-masked]>
Cc: [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]>
Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

The key question that I would ask Dino is whether these need to be addressed at the network layer?

Yes, because of this architectural principle:

On 1 Dec 2021, at 22:18, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

Here's my single feature request the network layer should provide:

(1) I want to be connected ALL THE TIME, I want my computer to use all its links, either cabled or radio, ALL THE TIME.

It can do this by treating these as independent links with different addresses and bind them in the application or through some OS service.

Its too much complexity for the app. The app is talking to one place and shouldn't know where it is. Hence the network layer should do this.

(2) I do not want to turn on and off wifi to get my device/computer to connect when it is currently not connected. The network layer should do all this for me.

Is that a network layer problem or an OS problem?

Yes, its a network layer problem. The OS is just an implmentation of a network stack.

(3) I want it easy for people to find me (my IP address), so I don't want multiple addresses from the user level. I want one device ID, EID, host address, whatever you want to call it. I want you to "ping <dino's-computer>".

It is important that people can find you/your device, but I am not convinced they need to find you by historic IP address.

I used this example (at the network layer) due to the audience of the list. What I really want to know is Stewart's crypto wallet address because I want to send you a donation. That is addressing at a specific app level.

“Pinging” Dino’s computer does not have to happen directly at the network layer to find out that it is alive. To test

Right but if I want to debug where my crypto transaction is going (I want it to go from my computer to your computer) then I have to go down a level (to the network layer), that is as an engineer (not high-level user) to determine an issue or understand performance.

*a* path to Dino’s computer sure you need the address that that path responds to, but I am not convinced that it is simpler if the address on that network is the same as the address on all of the other networks to which it is attached.

There is one network. You are one human being with 2 names. I can call you Stewart or Mr Bryant. It doesn't matter you will respond but wouldn't it be better if I called you "my-friend" and packets can go to either Steward or Mr Bryant?

I can tell you could react that this is a stretch, but you get what I'm trying to get across. The physical connection should not matter to the app. And don't forget the physical connection goes up and down, it gets fast and slow, it gets address (i.e. locator) changes. That should be damped out from the app.

Yes, I want host multi-homing and mobility. And I want it to work seamlessly.

Yes, I agree but I am not convinced we need to solve this by adding the complexity in L3 and hence through out the whole of the Internet rather than further up the protocol stack.

You always have to add something to get something. And what you add can be simple. Just have to make choices very very carefully.

Dino

Stewart

Speaking as a user,
Dino

On Dec 1, 2021, at 12:52 AM, Dirk Trossen <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>> wrote:

Dear all,

Many thanks for those participating in the side meeting on Internet addressing during the IETF 112 week. As suggested during the meeting, we want to take various points of discussion during the meeting onto the mailing list to continue discussion here on possible ways forward.

Specifically, we wanted to come back on the issue that a larger architectural discussion may be needed, a point that we make towards the end of the GA draft (https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/), but which was also core to Dirk K’s main point that only such architecture discussion may lead to possibly needed changes to addressing. We will be looking into such possibly larger discussion along different possible avenues.

For our discussion here on the INT area list, we found Dino’s related suggestion particularly useful in that we may need a discussion on what we (as users) may want from a network. We feel that our current GA draft may contribute to this question by observing that the many extensions to Internet addressing that we have gathered so far may be seen as an expression of a desired feature that those proposing the extension may want to see from the network. Hence, in addition to positioning those extensions as identified gaps to Internet addressing, we may want to formulate those extensions as desired features towards an extended Internet system, not just addressing; this can be done through suitably extending the GA draft with another section.

Why is this useful? We think that such view provides an observational input into the question that Dino suggests to answer, which in turn links to the larger architectural discussion that Dirk K suggests to have. While the overall architectural discussion may (and likely will) touch on more than ‘just’ addressing, we as a community may contribute to the discussion by rationalizing the work that has been done in this space.

We would like to solicit thoughts on this proposed way forward as concrete steps for the community here on the list. Also, anybody wanting to provide concrete input and contribution to this proposed revision of the draft is more than welcome.

Best,

Dirk
(on behalf of the co-authors)

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Dec 2021 14:17:31 -0800

You missed the point maybe. Common functions should be performed at the waist so applications don’t have to duplicate functionality. 

Dino

> On Dec 2, 2021, at 2:08 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
> 
> On 1 Dec 2021, at 22:18, Dino Farinacci <[email-masked]> wrote:
> 
> On Dec 1, 2021, at 12:52 AM, Dirk Trossen <dirk.trossen=[email-masked]> wrote:
> 
> Dear all,
> 
> [email-masked]
> [email-masked]

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 2 Dec 2021 22:22:01 +0000

Depends on what you consider to be the “waist”; the adaptation layer is below the
IP “waist” and (again) is missing from your diagram.

From: Dino Farinacci [mailto:[email-masked]]
Sent: Thursday, December 02, 2021 2:18 PM
To: Templin (US), Fred L <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]>
Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Dino

On Dec 2, 2021, at 2:08 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

From: Int-area [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Thursday, December 02, 2021 1:05 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Dirk Trossen <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>>
Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Dino

Stewart

Speaking as a user,
Dino

Dear all,

Best,

Dirk

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Dec 2021 13:38:09 +1300

On 03-Dec-21 11:17, Dino Farinacci wrote:
> You missed the point maybe. Common functions should be performed at the 
waist so applications don’t have to duplicate functionality.

Hmm. Logic compels me to offer an alternative:

Common functions should be performed by a shared library so applications don’t have to duplicate functionality.

I think both statements are true, and need to be read in conjunction with:
"The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)"
[Saltzer et al, doi.org/10.1145/357401.357402]

The user doesn't care whether the common functions are provided in the network or in the end hosts. We don't need to artificially force common functions into the network.

Restoration of connectivity is a common function, often provided by host software.

    Brian

>> *From:*Int-area [mailto:[email-masked]] *On Behalf Of *Dino 
Farinacci
>> *Sent:* Thursday, December 02, 2021 1:05 PM
>> *To:* Stewart Bryant <[email-masked]>
>> *Cc:* [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]>
>> *Subject:* Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?
>>
>>         On 1 Dec 2021, at 22:18, Dino Farinacci <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         (1) I want to be connected ALL THE TIME, I want my computer to 
use all its links, either cabled or radio, ALL THE TIME.
>>         (3) I want it easy for people to find me (my IP address), so I 
don't want multiple addresses from the user level. I want one device 
ID, EID, host address, whatever you want to call it. I want you to "ping <dino's-computer>".
>>
>>
>>     It is important that people can find you/your device, but I am not 
convinced they need to find you by historic IP address.
>>     “Pinging” Dino’s computer does not have to 
happen directly at the network layer to find out that it is alive. To test
>>     *a* path to Dino’s computer sure you need the address that 
that path responds to, but I am not convinced that it is simpler if the address on that network is the same as the address on all of the other networks to which it is attached.
>>
>> There is one network. You are one human being with 2 names. I can call 
you Stewart or Mr Bryant. It doesn't matter you will respond but wouldn't 
it be better if I called you "my-friend" and packets can go to either Steward or Mr Bryant?
>>             On Dec 1, 2021, at 12:52 AM, Dirk Trossen <dirk.trossen=[email-masked] <mailto:dirk.trossen=[email-masked]>> wrote:
>>
>>             Dear all,
>>
>>             Many thanks for those participating in the side meeting on 
Internet addressing during the IETF 112 week. As suggested during the meeting, we want to take various points of discussion during the meeting onto the mailing list to continue discussion here on possible ways 
forward.
>>
>>             Specifically, we wanted to come back on the issue that a larger architectural discussion may be needed, a point that we make towards the end of the GA draft (https://datatracker.ietf.org/doc/draft-jia-intarea-internet- <https://datatracker.ietf.org/doc/draft-jia-intarea-internet->addressing-gap-analysis/), but which was also core to Dirk K’s main point that only such architecture discussion may lead to possibly needed changes to addressing. We will be looking into such possibly larger discussion along different possible avenues.
>>
>>             For our discussion here on the INT area list, we found Dino’s related suggestion particularly useful in that we may need a discussion on what we (as users) may want from a network. We feel that our current GA draft may contribute to this question by observing 
that the many extensions to Internet addressing that we have gathered so far may be seen as an expression of a desired feature that those proposing the extension may want to see from the network. Hence, in addition to positioning those extensions as identified gaps to Internet addressing, we may want to formulate those extensions as desired features towards an extended Internet system, not just addressing; this can be done through suitably extending the GA draft with another section.
>>             [email-masked] <mailto:[email-masked]>
>>             https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>
>>
>>
>>         [email-masked] <mailto:[email-masked]>
>>         https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>
>>
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Dec 2021 17:14:13 -0800

Agree with your assessment with what users don’t care about. 

Regarding a shared library you will then duplicate data structures per app for multi-homing and mobility. 

In either case what needs to be published is the communication model. And all I’m asserting at this point is that there is typically a single ID used for apps to talk to each other. You can have multiple IDs but they are abstracted out of the topology connectivity. 

Multiple IDs could implement www.abc.com and ftp.abc.com which are two IDs for the same server. But later can be separated to different servers. And of course, those IDs are moving around all the time, topologically. 

Dino

> On Dec 2, 2021, at 4:38 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> don't want multiple addresses from the user level. I want one device ID, EID, host address, whatever you want to call it. I want you to "ping <dino's-computer>".
>>> 
>>> 
> you Stewart or Mr Bryant. It doesn't matter you will respond but wouldn't it be better if I called you "my-friend" and packets can go to either Steward or Mr Bryant?
>>> 
> Internet addressing during the IETF 112 week. As suggested during the meeting, we want to take various points of discussion during the meeting onto the mailing list to continue discussion here on possible ways forward.
>>>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 2 Dec 2021 17:20:39 -0800

All waists, like all layers except those that touch the physical (e.g., MAC protocols) are relative.

It’s a lot like the ‘end’ in E2E. It was thought to imply “that which can be kicked”, but it’s really “that which *I* can kick”.

Once you accept this relativity, everything else just works - including the reason why OSI got it completely wrong - layers are not uniquely defined by functions/capabilities. That’s the reason why MTU is so hard - everyone wants it to be ‘fixed’ at a single layer, but it can’t be.

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Dec 2, 2021, at 2:22 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
> From: Dino Farinacci [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Templin (US), Fred L <[email-masked] <mailto:[email-masked]>>
> Cc: Stewart Bryant <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Dirk Trossen <dirk.trossen=[email-masked] <mailto:dirk.trossen=[email-masked]>>
> On Dec 2, 2021, at 2:08 PM, Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> From: Int-area [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Dino Farinacci
> To: Stewart Bryant <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Dirk Trossen <dirk.trossen=[email-masked] <mailto:dirk.trossen=[email-masked]>>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 3 Dec 2021 14:37:14 +0000

Joe, yes MTU was hard – very hard – but it is now solved.

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 02, 2021 5:21 PM
To: Templin (US), Fred L <[email-masked]>
Cc: Dino Farinacci <[email-masked]>; [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]>
Subject: Re: Side meeting follow-up: What exact features do we want from the Internet?

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>

On Dec 2, 2021, at 2:22 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

From: Dino Farinacci [mailto:[email-masked]]
Sent: Thursday, December 02, 2021 2:18 PM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Dirk Trossen <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>>
Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Dino

Dino

Stewart

Speaking as a user,
Dino

Dear all,

Best,

Dirk

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 3 Dec 2021 07:32:55 -0800

Fred,

Having a mechanism that *can* be used at any layer to address fragmentation isn’t the same as solving the MTU issue.

Issues that complicate this are:
- not all layers employ that mechanism or any other
- too many ‘layers’ peek into payload contents for message dispatch (of one sort or another)
	- which means that if the fragmentation doesn’t copy enough of the payload, that dispatch breaks
	(lack of transport port numbers for IP frags, lack of HTTP headers for web message frags, etc.)

So whether it’s because solution are incomplete or not widely adopted, or both, it’s not solved.

Joe

—

> On Dec 3, 2021, at 6:37 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Dino Farinacci <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Dirk Trossen <dirk.trossen=[email-masked] <mailto:dirk.trossen=[email-masked]>>
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> On Dec 2, 2021, at 2:22 PM, Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 3 Dec 2021 18:06:49 +0000

Joe, I was going to let this slide but this is the most words you have spoken to
me in a single message in many years. What AERO/OMNI enable is lossless and
adaptive packet sizing to determine the best-performing size for a given flow
*even if that size exceeds the path MTU*. I think this honors the past works that
you seem to hold as sacred – both from yourself and from others.

What more do you want?

Fred

Sent: Friday, December 03, 2021 7:33 AM

Fred,

Joe

—

On Dec 3, 2021, at 6:37 AM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, December 02, 2021 5:21 PM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: Dino Farinacci <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Dirk Trossen <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>>
Subject: Re: Side meeting follow-up: What exact features do we want from the Internet?

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com/>

Dino

Dino

Stewart

Speaking as a user,
Dino

Dear all,

Best,

Dirk

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 3 Dec 2021 11:36:48 -0800

—

> On Dec 3, 2021, at 10:06 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> me in a single message in many years.

Sorry - my day job keeps me quite busy….

> What AERO/OMNI enable is lossless and

As a mechanism, nothing. But that mechanism has to be widely deployed and arguably available at multiple layers. I wish we had an approach that didn’t have the same kind of notion of MTU as IP, but rather more like Ethernet, as I noted before - which would obviate the need for frag/reassembly except at the uppermost app layer.

Joe

> On Dec 3, 2021, at 6:37 AM, Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
>