Consider a society that has left Earth. If light takes minutes to travel between locations, is a chatty protocol what you want?
Or do you need a whole host of different application-level solutions to this problem?
There's a different lens to look at it. There's an old tech talk that got me out of the IP-shaped box a lot of us are trapped in: https://www.youtube.com/watch?v=gqGEMQveoqg
I got Gemini 1.5 Pro to summarize the transcript, which I butchered a bit to fit in a text box:
The Problem:
The Internet is treated as a binary concept: You're either connected or not, leading to issues with mobile devices and seamless connectivity.
The focus on connections (TCP/IP conversations) hinders security: Security is tied to the pipe, not the data, making it difficult to address issues like spam and content integrity.
Inefficient use of resources: Broadcasting and multi-point communication are inefficient as the network is unaware of content, leading to redundant data transmission.
The Proposed Solution:
Data-centric architecture: Data is identified by name, not location. This enables:
Trust and integrity based on data itself, not the source.
Efficient multi-point communication and broadcasting.
Seamless mobility and intermittent connectivity.
Improved security against spam, phishing, and content manipulation.
Key principles:
Data integrity and trust are derived from the data itself through cryptographic signatures and verification.
Immutable content with versioning and updates through supersession.
Data segmentation for efficient transmission and user control.
Challenges:
Designing robust incentive structures for content sharing.
Mitigating risks of malicious content and freeloaders.
This all is correct, but it's not a reason to abandon IP. It's a reason to understand its place.
Currently IP does a good job of isolating the application layer from specifics of the medium (fiber, Ethernet, WiFi, LoRa, carrier pigeons) and provides a way of addressing one or multiple recipients. It works best for links of low latency and high availability.
To my mind, other concerns belong to higher levels. Congestion control belongs to TCP (or SCTP, or some other protocol); same for store-and-forward. Encryption belongs to Wireguard, TLS, etc. Authentication and authorization belongs to levels above.
Equally, higher-level protocols could use other transport than IP. HTTP can run over plain TCP, TLS, SPDY, QUIC or whatnot. Email can use SMTP or, say, UUCP. Git can use TCP or email.
Equally, your interplanetary communication will not speak in IP packets at application level, no more that it would speak in Ethernet frames. Say, a well-made IM / email protocol would be able to seamlessly work with ultrafast immediate-delivery networks and slow store-and-forward links. It would have message-routing mechanism that allows to deliver a message next desk with an IP packet, or another planet with a comm satellite rising above your horizon to pick and store message, then flying over the other side of the planet to deliver it.
The point about data being identified by name and not location is quite strong I think. It pushes concerns that lots of applications would have under conditions of high latency and intermittent connectivity to the network itself, rather than having to be solved repeatedly with minor differences for every application. Encryption and authentication wouldn't belong to higher levels and I think that's right.
I absolutely agree it's not a replacement for IP and that IP has its place. The point rather is to shift one's perspective on what IP is, the implicit constraints it has, and how under different constraints a very different model would be useful and IP would be a lot less useful there. Applications would not be dealing with symbolic aliases for numeric network locations because that wouldn't work.
Names need namespaces, else they cannot be unique enough. IPv6 is one such namespace, DNS (on top of IP), another, email addresses (on top of DNS) is yet another. They are hierarchical; the namespace of torrent magnet links is flat, and still works fine on top of an ever-changing sea of IP addresses. We already have mechanisms of mapping namespaces like that, and should reuse it.
I don't think IP is going to be outright replaced by other transport-level protocols right at the Internet's "waist", but it can be complemented with other protocols there, still keeping the waist narrow.
Or do you need a whole host of different application-level solutions to this problem?
There's a different lens to look at it. There's an old tech talk that got me out of the IP-shaped box a lot of us are trapped in: https://www.youtube.com/watch?v=gqGEMQveoqg
I got Gemini 1.5 Pro to summarize the transcript, which I butchered a bit to fit in a text box:
The Problem:
The Internet is treated as a binary concept: You're either connected or not, leading to issues with mobile devices and seamless connectivity.
The focus on connections (TCP/IP conversations) hinders security: Security is tied to the pipe, not the data, making it difficult to address issues like spam and content integrity.
Inefficient use of resources: Broadcasting and multi-point communication are inefficient as the network is unaware of content, leading to redundant data transmission.
The Proposed Solution:
Data-centric architecture: Data is identified by name, not location. This enables:
Trust and integrity based on data itself, not the source.
Efficient multi-point communication and broadcasting.
Seamless mobility and intermittent connectivity.
Improved security against spam, phishing, and content manipulation.
Key principles:
Data integrity and trust are derived from the data itself through cryptographic signatures and verification.
Immutable content with versioning and updates through supersession.
Data segmentation for efficient transmission and user control.
Challenges:
Designing robust incentive structures for content sharing.
Mitigating risks of malicious content and freeloaders.
Addressing legal and liability concerns.