4 ms·

>I'm also aware that there are other projections here; I recently interviewed a prominent Internet greybeard figure who theorized that Internet infrastructure g

by tjoff 2y ago

>I'm also aware that there are other projections here; I recently interviewed a prominent Internet greybeard figure who theorized that Internet infrastructure growth as a whole has slowed so much that IPv4 demand may be satisfied in the future out of gradual conversion of residential ISPs to using primarily carrier-grade NAT for IPv4, and then selling off their number resources. That is one projection, but it is also a very bleak view of the future. One that we should actively fight at any opportunity and at almost any cost. It will centralize the internet further and squash many attempts for alternative communications.

derefr 2y ago
> It will centralize the internet further and squash many attempts for alternative communications. Would it? It seems to me that a future where 1. every home land-line Internet connection is CGNATed; but 2. every cellular Internet connection is a public IPv6 prefix (as is already mostly the case today!); is actually a promising one. Provided, that is, that residential ISPs also get off their collective asses and provide the promised "hosted edge compute" capabilities they've been tinkering with for the last 10 years. Since the Internet's inception, people on residential connections have been stuck in a broken mindset of "your home PC can act as a monolithic Internet peer — but only an unreliable one, that can't receive messages when it's shut off and is prone to being DDoSed — so you probably shouldn't actually use it as a server/p2p node, for anything other than, say, VoIP, or hosting an ephemeral multiplayer FPS game session. And you can tinker with a development web-server on your home network — but if you want to actually host anything, you should go pay a cloud provider." Whereas, in a world with no well-Internet-connected home PCs providing the illusion of the possibility of hosting a home server, only instead: 1. home PCs — which can compute well, but can't be a network-ingress, and also might go down (often for laptops, less often for desktops, but both far more often than a real server would); 2. smartphones — which can network-ingress, but can't spend long periods computing (without burning all your battery life), and which will go down / out of wireless range extremely often; and 3. both commercial, and more importantly ISP-residential, edge-compute clusters — which would give tiny compute slices per workload, but ones with full network-ingress, and would never go down; ...then it'd be clear to all the people who had been thinking until that point that they could get away with p2p on home PCs using STUN/TURN-based protocols, that they would have to do something else; that operating systems (esp. mobile ones) and their client-server/p2p applications would have to evolve to become inherently edge-hybrid; that applications would need to evolve frameworks to embed persistent network-ingress "edge components" that could be shipped automatically and implicitly to the active network's associated edge deploy environment as part of the application's runtime; etc. If you can't picture that: think about a web server backend that automatically deploys/updates an associated Cloudflare Worker whenever it boots up; and which then expects to be talked to through that Cloudflare Worker proxying requests to it; and where that Worker can also buffer requests, store data into its edge key-value store, etc. But instead of a web server backend, it's the Minecraft app on your phone; and instead of Cloudflare, it's your residential ISP; and instead of the edge worker making a forward connection to your phone, your phone holds open an ngrok-like reverse connection to the edge worker to receive requests. (Oh, and one other point of necessary evolution: that the "server component" of any p2p app would also be a mobile workload — not shiftable to the edge itself, but rather through the persistent edge workload to any [similarly reverse-connected, not always online] "compute host nodes" owned by the same user/organization. Such that you could buy a little NUC/NAS-like box to shove under your TV at home, whose marketed purpose would be compute+storage offload for the workloads launched on your phone; or such that your office could have some server racks for free auto-offload of "server components" of apps running on any employee machine — reversing the usual "cloud app with local client" relationship into "local app with slaved cloud workload." Where, in either case, the relevant workloads are still canonically on your phone/PC, so if the "compute offload" has to be drained for an update, the workloads just temporarily migrate back to your phone/PC.) From my perspective, this would actually be a much better Internet in practice than the one we have today. Individuals would be far more able to host persistent, accessible services on a whim, without investment into local infra or being beholden to a commercial provider with a ToU. Individuals would be paying their ISPs for edge hosting, yes (if they don't have a server with a public IP to run an "edge layer" on themselves); but — * those would be small fixed costs (as apps' network-ingress components would be small fixed workloads); * and would likely be sold as free value-adds of data plans (just like web hosting, email, and access to locally-mirrored NNTP groups used to be sold as value-adds of residential Internet plans); * and such workloads would only be smarter versions of the "dumb pipe" the residential ISP was already providing, not backends in-and-of themselves; and so wouldn't be subject to a VPS-host-like "you can't host X/Y/Z on our servers" type ToU, because users are not hosting anything per se; * and as such edge workloads live on a very high-level abstraction layer, an edge-hosting ISP would be empowered to do all sorts of things to defend such workloads from DDoS attacks (e.g. putting the known-protocol workload behind a layer-7 WAF), that it can't do for individual customers' single-homed single-IP single-port, arbitrary-protocol home PC server processes.
- caf 2y ago
  I don't see this ever happening. As you say, residential ISPs used to provide additional services to their customers like web hosting, email, NNTP, shell access, time synch, IRC, mirrors of popular archives. They don't anymore - frequently, not even email. ISPs have clearly shown that they're not interested in being much more than the fastest dumb pipe around, because that's what their customers want, and I don't see that trend reversing.
  - derefr 2y ago
    To be clear, residential ISPs already do provide edge-compute hosting... for corporations. When Netflix and others put CDNs "at the edge", they aren't doing that by building their own DC inside your city; nor by renting space in a random colo facility. Rather, they partner with each of the local regional ISPs, to put their CDN inside the ISP's "edge hosting DC" — a facility that almost all ISPs own (if not necessarily manage) at least one of in every city, precisely for the purpose of enabling such agreements. So, unlike most Over-The-Top data services (which ISPs have long since lost the competency for), this one is something ISPs are actively doing. They're just not selling it B2C; their edge data-centers are currently a pure B2B play for them. But ISPs do know how to sell things B2C — so this would just be a question of them feeling enabled by product re-packaging to give this product line over to their B2C sales and marketing departments as something to charge their customers for. "Re-packaging" this B2B colo into something they can sell to customers, would in turn just require the mobile OS vendors to step up and write code to make doing so an ops question rather than an R&D question — just as they did for visual voicemail, wi-fi calling, eSIM deployment, and so on. Essentially, Apple and Google would just need to provide their own server racks to ISPs, which host workload hypervisors for offload of workloads from "their" devices — in such a way that offload wouldn't be something customers would be paying Apple or Google a subscription fee for, but rather, as with Visual Voicemail, something where usage records from this system could feed into the ISP's usage-accounting systems, to be reduced into billing items by arbitrary ISP data-plan business rules. --- And hopefully — but I'm not holding my breath — this would be done using open protocols and with FOSS-replicable software, such that eventually the ISPs could stop relying on Apple and Google to provide this only for specific devices, and instead could ask for their 3GPP hardware-integration vendor of choice to provide this as part of their 6/7/8G head-end system, in such a way that any device leased an IP by said head-end could make use of it. What would such a standard look like? Well, we're talking about a vendor-neutral, architecture-neutral abstract machine runtime, tuned to host persistent, network-mobile, IO-bound, highly-concurrent workloads "cheaply" on a highly-multitenant basis. And Ericsson, one of the largest 3GPP equipment providers, created a runtime a few decades back that coincidentally fits that set of constraints quite closely — so closely, in fact, that they'd likely just vaguely wave at it and say "here, standardize this." (After giving its architecture a few security tweaks to achieve multitenant safety guarantees, that is.) Just imagine: every mobile app on your iPhone, embedding its own little BEAM-bytecode relup package; one built by XCode, compiled from a combination of project source files written in a "network dialect" of Swift, plus Erlang library dependencies. And then pushed, on app launch, to a secure-multitentant Erlang VM sandbox, run by your ISP in its edge colo. Wouldn't that be just wild? ;)

by tjoff 2y ago

derefr 2y ago

> It will centralize the internet further and squash many attempts for alternative communications. Would it? It seems to me that a future where 1. every home land-line Internet connection is CGNATed; but 2. every cellular Internet connection is a public IPv6 prefix (as is already mostly the case today!); is actually a promising one. Provided, that is, that residential ISPs also get off their collective asses and provide the promised "hosted edge compute" capabilities they've been tinkering with for the last 10 years. Since the Internet's inception, people on residential connections have been stuck in a broken mindset of "your home PC can act as a monolithic Internet peer — but only an unreliable one, that can't receive messages when it's shut off and is prone to being DDoSed — so you probably shouldn't actually use it as a server/p2p node, for anything other than, say, VoIP, or hosting an ephemeral multiplayer FPS game session. And you can tinker with a development web-server on your home network — but if you want to actually host anything, you should go pay a cloud provider." Whereas, in a world with no well-Internet-connected home PCs providing the illusion of the possibility of hosting a home server, only instead: 1. home PCs — which can compute well, but can't be a network-ingress, and also might go down (often for laptops, less often for desktops, but both far more often than a real server would); 2. smartphones — which can network-ingress, but can't spend long periods computing (without burning all your battery life), and which will go down / out of wireless range extremely often; and 3. both commercial, and more importantly ISP-residential, edge-compute clusters — which would give tiny compute slices per workload, but ones with full network-ingress, and would never go down; ...then it'd be clear to all the people who had been thinking until that point that they could get away with p2p on home PCs using STUN/TURN-based protocols, that they would have to do something else; that operating systems (esp. mobile ones) and their client-server/p2p applications would have to evolve to become inherently edge-hybrid; that applications would need to evolve frameworks to embed persistent network-ingress "edge components" that could be shipped automatically and implicitly to the active network's associated edge deploy environment as part of the application's runtime; etc. If you can't picture that: think about a web server backend that automatically deploys/updates an associated Cloudflare Worker whenever it boots up; and which then expects to be talked to through that Cloudflare Worker proxying requests to it; and where that Worker can also buffer requests, store data into its edge key-value store, etc. But instead of a web server backend, it's the Minecraft app on your phone; and instead of Cloudflare, it's your residential ISP; and instead of the edge worker making a forward connection to your phone, your phone holds open an ngrok-like reverse connection to the edge worker to receive requests. (Oh, and one other point of necessary evolution: that the "server component" of any p2p app would also be a mobile workload — not shiftable to the edge itself, but rather through the persistent edge workload to any [similarly reverse-connected, not always online] "compute host nodes" owned by the same user/organization. Such that you could buy a little NUC/NAS-like box to shove under your TV at home, whose marketed purpose would be compute+storage offload for the workloads launched on your phone; or such that your office could have some server racks for free auto-offload of "server components" of apps running on any employee machine — reversing the usual "cloud app with local client" relationship into "local app with slaved cloud workload." Where, in either case, the relevant workloads are still canonically on your phone/PC, so if the "compute offload" has to be drained for an update, the workloads just temporarily migrate back to your phone/PC.) From my perspective, this would actually be a much better Internet in practice than the one we have today. Individuals would be far more able to host persistent, accessible services on a whim, without investment into local infra or being beholden to a commercial provider with a ToU. Individuals would be paying their ISPs for edge hosting, yes (if they don't have a server with a public IP to run an "edge layer" on themselves); but — * those would be small fixed costs (as apps' network-ingress components would be small fixed workloads); * and would likely be sold as free value-adds of data plans (just like web hosting, email, and access to locally-mirrored NNTP groups used to be sold as value-adds of residential Internet plans); * and such workloads would only be smarter versions of the "dumb pipe" the residential ISP was already providing, not backends in-and-of themselves; and so wouldn't be subject to a VPS-host-like "you can't host X/Y/Z on our servers" type ToU, because users are not hosting anything per se; * and as such edge workloads live on a very high-level abstraction layer, an edge-hosting ISP would be empowered to do all sorts of things to defend such workloads from DDoS attacks (e.g. putting the known-protocol workload behind a layer-7 WAF), that it can't do for individual customers' single-homed single-IP single-port, arbitrary-protocol home PC server processes.

caf 2y ago
I don't see this ever happening. As you say, residential ISPs used to provide additional services to their customers like web hosting, email, NNTP, shell access, time synch, IRC, mirrors of popular archives. They don't anymore - frequently, not even email. ISPs have clearly shown that they're not interested in being much more than the fastest dumb pipe around, because that's what their customers want, and I don't see that trend reversing.
- derefr 2y ago
  To be clear, residential ISPs already do provide edge-compute hosting... for corporations. When Netflix and others put CDNs "at the edge", they aren't doing that by building their own DC inside your city; nor by renting space in a random colo facility. Rather, they partner with each of the local regional ISPs, to put their CDN inside the ISP's "edge hosting DC" — a facility that almost all ISPs own (if not necessarily manage) at least one of in every city, precisely for the purpose of enabling such agreements. So, unlike most Over-The-Top data services (which ISPs have long since lost the competency for), this one is something ISPs are actively doing. They're just not selling it B2C; their edge data-centers are currently a pure B2B play for them. But ISPs do know how to sell things B2C — so this would just be a question of them feeling enabled by product re-packaging to give this product line over to their B2C sales and marketing departments as something to charge their customers for. "Re-packaging" this B2B colo into something they can sell to customers, would in turn just require the mobile OS vendors to step up and write code to make doing so an ops question rather than an R&D question — just as they did for visual voicemail, wi-fi calling, eSIM deployment, and so on. Essentially, Apple and Google would just need to provide their own server racks to ISPs, which host workload hypervisors for offload of workloads from "their" devices — in such a way that offload wouldn't be something customers would be paying Apple or Google a subscription fee for, but rather, as with Visual Voicemail, something where usage records from this system could feed into the ISP's usage-accounting systems, to be reduced into billing items by arbitrary ISP data-plan business rules. --- And hopefully — but I'm not holding my breath — this would be done using open protocols and with FOSS-replicable software, such that eventually the ISPs could stop relying on Apple and Google to provide this only for specific devices, and instead could ask for their 3GPP hardware-integration vendor of choice to provide this as part of their 6/7/8G head-end system, in such a way that any device leased an IP by said head-end could make use of it. What would such a standard look like? Well, we're talking about a vendor-neutral, architecture-neutral abstract machine runtime, tuned to host persistent, network-mobile, IO-bound, highly-concurrent workloads "cheaply" on a highly-multitenant basis. And Ericsson, one of the largest 3GPP equipment providers, created a runtime a few decades back that coincidentally fits that set of constraints quite closely — so closely, in fact, that they'd likely just vaguely wave at it and say "here, standardize this." (After giving its architecture a few security tweaks to achieve multitenant safety guarantees, that is.) Just imagine: every mobile app on your iPhone, embedding its own little BEAM-bytecode relup package; one built by XCode, compiled from a combination of project source files written in a "network dialect" of Swift, plus Erlang library dependencies. And then pushed, on app launch, to a secure-multitentant Erlang VM sandbox, run by your ISP in its edge colo. Wouldn't that be just wild? ;)