7 ms·

Is that really a problem with IP? IP doesn't require connection state. If you want resilience in the face of loss you need to add more, like holding the data u

Is that really a problem with IP? IP doesn't require connection state. If you want resilience in the face of loss you need to add more, like holding the data until a transmission has been acknowledged as received. TCP does that fine for modest packet loss and short outages. For longer timescales, I don't think you want some sort of store-and-forward baked into the normal network protocols, because meaning decays with time. Imagine I want to watch a movie, but the service is down for a week, so I request it every night. The network stores those 7 requests and delivers them when the movie service comes up again. Do I really want to get 7 copies of a movie I may have given up on? Or even one? That question isn't resolvable at the network layer; it requires application level knowledge. Better to let application logic handle it. I agree with your concern about government control, but I don't think the IP layer is a place to address it. I think the work around ad-hoc and mesh networks is much more interesting there. That would also drive more resilient applications, but I think that can be built on top of IP just fine.

barrkel 2y ago
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 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.
- nine_k 2y ago
  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.
  - barrkel 2y ago
    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.
    - nine_k 2y ago
      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.
__MatrixMan__ 2y ago
Consider the case where you've got a computer aboard a delivery truck and it's hopping on and off home wifi networks as it moves through the neighborhood. From prior experience it knows which topics it is likely to encounter publishers for, and which it is likely to encounter subscribers for. There's a place for some logic--it's not precisely routing, but it's analogous to routing--which governs when it should forget certain items once storage is saturated for that topic. IP is pretty much useless here because both the truck (as a carrier) and the people (as sources/sinks), end up with different addresses when they're in different places. You'd want something that addresses content and people such that the data ends up nearest the people interested in it. It's an example of a protocol which would be in the waist, were it not so thin.
- MichaelZuo 2y ago
  The computer aboard the delivery truck can just broadcast every time it hops on to a new access point? It might not have the authority to broadcast via every access point, so it will likely be very circumscribed, but that’s just a question of the relative rank and authority between the truck operators and access point operators, routing layers, etc… not a question of the technology. Since even several round trips of handshaking across the Earth takes only a few hundred milliseconds, and the truck presumably spends at least a few seconds in range.
  - __MatrixMan__ 2y ago
    If you're in a situation where: > even several round trips of handshaking across the Earth takes only a few hundred milliseconds then I'm not sure why you'd bother using the delivery truck as data transport anyhow. I'm more interested in the case where such infrastructure is either damaged, untrustworthy, or was never there in the first place. If there was a fallback which worked, even if it wasn't shiny, there'd be something to use if the original went bad for some reason.
    - MichaelZuo 2y ago
      What do you mean ‘If’? Everyone on planet earth is in that ‘situation’ called reality where signals take time to propagate. And in any case how does this relate to the previous comments?

barrkel 2y ago

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 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.

nine_k 2y ago
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.
- barrkel 2y ago
  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.
  - nine_k 2y ago
    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.

__MatrixMan__ 2y ago

Consider the case where you've got a computer aboard a delivery truck and it's hopping on and off home wifi networks as it moves through the neighborhood. From prior experience it knows which topics it is likely to encounter publishers for, and which it is likely to encounter subscribers for. There's a place for some logic--it's not precisely routing, but it's analogous to routing--which governs when it should forget certain items once storage is saturated for that topic. IP is pretty much useless here because both the truck (as a carrier) and the people (as sources/sinks), end up with different addresses when they're in different places. You'd want something that addresses content and people such that the data ends up nearest the people interested in it. It's an example of a protocol which would be in the waist, were it not so thin.

MichaelZuo 2y ago
The computer aboard the delivery truck can just broadcast every time it hops on to a new access point? It might not have the authority to broadcast via every access point, so it will likely be very circumscribed, but that’s just a question of the relative rank and authority between the truck operators and access point operators, routing layers, etc… not a question of the technology. Since even several round trips of handshaking across the Earth takes only a few hundred milliseconds, and the truck presumably spends at least a few seconds in range.
- __MatrixMan__ 2y ago
  If you're in a situation where: > even several round trips of handshaking across the Earth takes only a few hundred milliseconds then I'm not sure why you'd bother using the delivery truck as data transport anyhow. I'm more interested in the case where such infrastructure is either damaged, untrustworthy, or was never there in the first place. If there was a fallback which worked, even if it wasn't shiny, there'd be something to use if the original went bad for some reason.
  - MichaelZuo 2y ago
    What do you mean ‘If’? Everyone on planet earth is in that ‘situation’ called reality where signals take time to propagate. And in any case how does this relate to the previous comments?