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

From: Jiayihao <[email-masked]>
Date: Fri, 3 Dec 2021 07:49:29 +0000

Hi Dino, all,

I think the discussion is about to talk which layer should the features be added to. (network? Host? Or the abstracted waist?)

It is true that users expect more features from the NETWORK as a lot of you proposed, but users are definitely know nothing about TCP/IP or OSI or ATM architecture.
For this, users do not ask that features must be added to a certain layers, and ALL layers seems to be a bundle named NETWORK to them.

So can I shape the discussion into "What feature may users expect from the NETWORK? " (Here the NETWORK is regarded as a bundle from a user perspective).

Once we confirmed these expected features form users/outsiders, it only goes to insiders' discussion and choices that which layers the features should be put to.

Thanks,
Yihao

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Dec 2021 11:22:28 -0800

> It is true that users expect more features from the NETWORK as a lot of you proposed, but users are definitely know nothing about TCP/IP or OSI or ATM architecture.

I certainly agree and hence why multi-homing and mobility needs to be hidden from both the apps and the users that use such apps.

> For this, users do not ask that features must be added to a certain layers, and ALL layers seems to be a bundle named NETWORK to them.

Right. Agree. 

> So can I shape the discussion into “What feature may users expect from the NETWORK? ” (Here the NETWORK is regarded as a bundle from a user perspective).

So here is my request again acting as a dumb user:

"I want to move around and stay connected ALL THE TIME". "I want more bandwidth out of my phone". "Why do I have to refresh all the time when an app says 'not connected'."

> Once we confirmed these expected features form users/outsiders, it only goes to insiders’ discussion and choices that which layers the features should be put to.

Agree. So lets agree on the features before discussing any types of solutions. In my replies I have talked about solutions because other have asked. I want this thread to set user requirements.

Dino

---

From: Jiayihao <[email-masked]>
Date: Tue, 7 Dec 2021 10:19:29 +0000

Hi Dino,

Thanks for clarification. 
Then expectations of users intuitively from my side can be:

(1) I want to be agnostic to the network protocols (I do not want to know Bluetooth, ZigBee, thread, Airdrop, or any others). I just hope that if I buy an IoT device, I can take control of it by my phone (better locally).
(2) I want to have strict privacy/security. No traces can be linked to me according to the networking actions I took once I choose to remain anonymous.
(3) I can access my devices/data anytime, anywhere, all under my control. Any data that I have/bought cannot be confiscated or taken away from me.
(4) Similar to your first point: I want to be always attached to the Internet by any personal devices. (then I can better enjoy the features above)

Here I have another question: application developer/programmer should have a different angle for new features. Of course application developer/programmer should to be agnostic (or learn as less as possible) to network stuffs during developing, but definitely they have more insights and more details shall be learned by them.

Thanks,
Yihao

-----Original Message-----
From: Dino Farinacci <[email-masked]> 
Sent: 2021.12.4 3:22
To: Jiayihao <[email-masked]>
Cc: [email-masked]
Subject: Re: Side meeting follow-up: What exact features do we want from the Internet?

Right. Agree. 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 7 Dec 2021 09:44:05 -0600

> (1) I want to be agnostic to the network protocols (I do not want to know Bluetooth, ZigBee, thread, Airdrop, or any others). I just hope that if I buy an IoT device, I can take control of it by my…

That is correct. That is how IP was born in the days of Ethernet, Token Ring, FDDI, X.25, DDN-X.25, Frame Relay, SMDS, and ATM. Not to mention all the HDLC variant serial links. Bridging across these data links (at layer 2) was always problematic.

> (2) I want to have strict privacy/security. No traces can be linked to me according to the networking actions I took once I choose to remain anonymous.

Meaning the IP layer encrypts ALL packets and source addresses are obfuscated and possibly randomized. The ideas and points Tom (and Luigi) has made in the past.

> (3) I can access my devices/data anytime, anywhere, all under my control. Any data that I have/bought cannot be confiscated or taken away from me.

I think the lay Internet user already assumes this. And expects the same service as when they plug into an electrical outlet. If it doesn't work, they scream.

> (4) Similar to your first point: I want to be always attached to the Internet by any personal devices. (then I can better enjoy the features above)

Yes.

> Here I have another question: application developer/programmer should have a different angle for new features. Of course application developer/programmer should to be agnostic (or learn as less as…

App developers control user behavior by making their services/functionality available with good UI. Make it easy for the user to get do things with the fewest number of steps. A counter example is the Facebook iOS app.

Dino

---

From: Jiayihao <[email-masked]>
Date: Wed, 8 Dec 2021 06:47:15 +0000

Hi Dino,

Please see inline.

BR,
Yihao

-----Original Message-----
From: Dino Farinacci <[email-masked]> 
Sent: 2021年12月7日 23:44
To: Jiayihao <[email-masked]>
Cc: [email-masked]
Subject: Re: Side meeting follow-up: What exact features do we want from the Internet?

 
[jiayihao] Here I mean our data is controlled by our service provider not user themselves. For example, if I bought a movie X from an online streaming provider A, I still do not own this movie X and have to pay again if I want to watch movie X from online streaming provider B. However, I am not that sure if it can be categorized to a network requirement.

Yes.

[jiayihao] Agree that App developers should not care about network stuff like the session continuity during device movement. However, App developers do learn things like URL, domain names, DNS, Quic, CDN, proxies.....,and make them transparent behind the good UI. So there do have some network stuffs that are agnostic to users but are not agnostic to App developers. 

[jiayihao] My observation is: If we consider network features/requirements from App developers, it will finally result in discussion about the network architecture.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 8 Dec 2021 07:35:36 -0600

> [jiayihao] Here I mean our data is controlled by our service provider not user themselves. For example, if I bought a movie X from an online streaming provider A, I still do not own this movie X an…

This is certainly an application specific issue. Not network layer.

But if you are watching a movie and move from your house to your car and switch from wifi to LTE/5G, the movie should continue playing. That is where the network layer provides seamless connectivity and the app doesn't know that anything has changed (and hence why the apps use sockets that bind to non-topological addresses (i.e. EIDs)).

> [jiayihao] Agree that App developers should not care about network stuff like the session continuity during device movement. However, App developers do learn things like URL, domain names, DNS, Qui…

Right, and they should bind/map to EIDs. Meaning, when application handles or directories map to IP addresses, they are not topological addresses.

> [jiayihao] My observation is: If we consider network features/requirements from App developers, it will finally result in discussion about the network architecture.

No, my experience is that apps bind to names. The app developers have enough fish to fry, they don't want to deal with network specific issues. They just want to out sockets to send and receive. Just have a look at all the new Dapps being written.

Dino

---

From: Jiayihao <[email-masked]>
Date: Fri, 10 Dec 2021 09:56:57 +0000

Hi Dino, all,

Based on a user point of view, I try to go through the thread and summarize the features gathered. 
Please correct me if anything missing or I get anything wrong. 
(Points like 6M mentioned by Fred are shaped to better reflect the points from users.)

(1) Always-On: be connected to the Internet, Anywhere, by Any links (either cabled or radio),  ALL THE TIME, and All automatically (without any switch turning).
(2) Transparency: be agnostic to the network protocols (IP, Bluetooth, ZigBee, Thread, Airdrop, Airplay, or any others), want an easy and straightforward to contact a people/device without any knowledge of network issues like IP address, and 
(3) Multi-homing: seamlessly multi-homing capability for the host.
(4) Mobility: seamless and lossless communications for moving nodes (vehicle, satellites).
(5) Security and Privacy: security and privacy, omnidirectionally, incessantly
(6) Performance: satisfied (if not impeccable) reliability, availability, speed(shorter paths/direct communications), enough bandwidth(10petabit/s for a link), Efficient(less overlays/encapsulations), highly effective (avoid address waste).
(7) Kernel: make sure the Internet does no harm.
(8) Others: no worry about MTU

Thanks,
Yihao Jia

-----Original Message-----
From: Dino Farinacci <[email-masked]> 
Sent: 2021年12月8日 21:36
To: Jiayihao <[email-masked]>
Cc: [email-masked]
Subject: Re: Side meeting follow-up: What exact features do we want from the Internet?

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Dec 2021 14:00:34 +0100

Le 10/12/2021 à 10:56, Jiayihao a écrit :
> Hi Dino, all,
> 
> Based on a user point of view, I try to go through the thread and
> summarize the features gathered. Please correct me if anything
> missing or I get anything wrong. (Points like 6M mentioned by Fred
> are shaped to better reflect the points from users.)
> 
> (1) Always-On: be connected to the Internet, Anywhere, by Any links
> (either cabled or radio),  ALL THE TIME, and All automatically
> (without any switch turning). (2) Transparency: be agnostic to the
> network protocols (IP, Bluetooth, ZigBee, Thread, Airdrop, Airplay,
> or any others), want an easy and straightforward to contact a
> people/device without any knowledge of network issues like IP
> address, and (3) Multi-homing: seamlessly multi-homing capability for
> the host. (4) Mobility: seamless and lossless communications for
> moving nodes (vehicle, satellites). (5) Security and Privacy:
> security and privacy, omnidirectionally, incessantly (6) Performance:
> satisfied (if not impeccable) reliability, availability,
> speed(shorter paths/direct communications), enough
> bandwidth(10petabit/s for a link), Efficient(less
> overlays/encapsulations), highly effective (avoid address waste). (7)
> Kernel: make sure the Internet does no harm. (8) Others: no worry
> about MTU

Thanks for listing the "Internet - no harm" point.

But I did not see why is it called 'kernel'?

I was thinking to make sure Internet does no harm in the linux kernel
sense, yes, but among more other aspects.

"Internet - no harm" point in the linux kernel would mean probably
something to reduce the size of the Internet (IP) stack in the kernel,
reduce its energy consumption, reduce the 'software bloat' of it.  Is
this the kernel you refer to?

"Internet - no harm" point on a broader scale would mean to try to make
sure aspects such as datacenter energy consumption (there were no such
big datacenters prior to Internet; it can safely be assumed that these
datacenters are created and needed by the Internet), human factors
related to over-use of the Internet like professional emails during
weekends and burnout, societal impacts digital divide like
all-Internet-for-young and nothing-for-the-elderly or like the divide
between countries with differing revenues per capita, social system
divides like Internet ability in certain countries to be 'cut', various
legislation's crime facilitated by the Internet, and more - are fed back
into the design of the new Internet and make sure it does no harm.

It is a little bit like in Health and medicine: first, make sure do no
harm.  When a surgeon opens someone's body, the first thing s/he must
make sure is to do no harm (do not break some artery or vein, and just
have a look to see what's wrong in the ill), even though the cut in the
skin is already a little bit of harm.

Alex

> 
> Thanks, Yihao Jia
> 
> -----Original Message----- From: Dino Farinacci
> <[email-masked]> Sent: 2021年12月8日 21:36 To: Jiayihao
> <[email-masked]> Cc: [email-masked] Subject: Re: Side meeting
> follow-up: What exact features do we want from the Internet?
> 
>> [jiayihao] Here I mean our data is controlled by our service
>> provider not user themselves. For example, if I bought a movie X
>> from an online streaming provider A, I still do not own this movie
>> X and have to pay again if I want to watch movie X from online
>> streaming provider B. However, I am not that sure if it can be
>> categorized to a network requirement.
> 
> But if you are watching a movie and move from your house to your car
> and switch from wifi to LTE/5G, the movie should continue playing.
> That is where the network layer provides seamless connectivity and
> the app doesn't know that anything has changed (and hence why the
> apps use sockets that bind to non-topological addresses (i.e.
> EIDs)).
> 
>> (4) Similar to your first point: I want to be always attached to
>> the Internet by any personal devices. (then I can better enjoy the
>> features above)
>> 
>> Yes.
>> 
>>> Here I have another question: application developer/programmer
>>> should have a different angle for new features. Of course
>>> application developer/programmer should to be agnostic (or learn
>>> as less as possible) to network stuffs during developing, but
>>> definitely they have more insights and more details shall be
>>> learned by them.
>> 
>> App developers control user behavior by making their
>> services/functionality available with good UI. Make it easy for the
>> user to get do things with the fewest number of steps. A counter
>> example is the Facebook iOS app.
>> 
>> [jiayihao] Agree that App developers should not care about network
>> stuff like the session continuity during device movement. However,
>> App developers do learn things like URL, domain names, DNS, Quic,
>> CDN, proxies.....,and make them transparent behind the good UI. So
>> there do have some network stuffs that are agnostic to users but
>> are not agnostic to App developers.
> 
> Right, and they should bind/map to EIDs. Meaning, when application
> handles or directories map to IP addresses, they are not topological
> addresses.
> 
>> [jiayihao] My observation is: If we consider network
>> features/requirements from App developers, it will finally result
>> in discussion about the network architecture.
> 
> No, my experience is that apps bind to names. The app developers have
> enough fish to fry, they don't want to deal with network specific
> issues. They just want to out sockets to send and receive. Just have
> a look at all the new Dapps being written.
> 
> Dino
> 
> _______________________________________________ Int-area mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/int-area