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.
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? ;)
On the telco side, as I understand it the CDN hosting isn't seen as a revenue centre - rather, it's there because it makes their pipe faster than the competition's (for the principle use cases of most of their customers, anyway).
Because Apple/Google can only run so many data centers. And these DCs are all too high-latency / "out of the way" of the connection path between the user's device and the devices it wants to talk to, to make "diverting" the connection path to one of these DCs worth it.
Besides that, though — doing such "diversions" would massively increase cost, because it would turn a one-backbone-path (or sometimes even zero-backbone-path) route into a two-backbone-path route.
Instead of,
userA → ispA → userB
userA → ispA → backbonePath → ispB → userB
userA → ispA → backbonePathA → Apple/Google → backbonePathB → ispB → userB
Now put yourself in Netflix's shoes. You don't want to deal with residential ISPs; they're usually large conglomerates that have more bargaining power than a random commercial colo facility in a city would have. But you do anyway. Why? Because, by doing so, you get a connection to the ISP's customers that is:
- extremely low latency
- extremely low bandwidth cost (because there's no need to traverse a backbone for any hop — the CDN's data can stay on the un-congested "residential streets" of the ISP, without ever needing to get on the "highway" where it would have to fan in and wait on an "on-ramp")
- never-degraded QoS — because their traffic on the residential ISP's network is just delivered with a default priority class (like everything else on that network, other than maybe the residential ISP's own OTT VoIP-based POTS service); whereas, when traversing any backbone, other providers who were willing to pay more per byte (because they had far fewer bytes to send and valued them more — which is basically every provider compared to a movie streaming service) get higher priority classes, narrowing the virtual pipe [= re-allocating to fewer circuits on circuit-TDMI backbone routers] and so degrading service for the CDNs whenever other higher-priority-rate traffic wants to flow.
The argument for Apple/Google putting their edge compute offload into residential ISP DCs would be exactly the same. It takes a network path that the customer was already establishing anyway, and adds a place for a "user-programmable virtual router" to live in that network path — without lengthening the path, making QoS worse, or any of that.
---
But let's go at this another way: if the cost/benefit worked out in favor of Apple/Google doing this in their own DCs... then why wouldn't they have already offered this years ago?
Apple might not be a B2B cloud provider that has hypervisor clusters ready for customer use — but Google certainly is. Why isn't "Android Offload Services, powered by Google Cloud Run on ARM" a thing?
What I said above (doing so creating a network "diversion", doubling backbone connections, wrecking QoS, etc) still applies.
But I think there's another obvious reason: if Apple/Google ran the DCs themselves, then this is something that would require that you pay Apple/Google a subscription fee for. Without a subscription fee, it'd just be a money pit — one a short-sighted CFO would either never green-light, or cancel after a single quarter.
And yet, a subscription model can't be the model used to support the very first instance of such a service at its inception, either. "Workload offload" is something with (currently) zero customer education behind it — i.e. it's something that customers would have absolutely no understanding of the value of, and so would never want to pay for, let alone sign up for a subscription they might not already be paying just to receive, until they see the value of it demonstrated in at least some other market, somewhere else.
These two properties create a seeming catch-22: given their corporate structures, Apple/Google can't subsidize it themselves; and given lack of user education, they can't immediately charge for it, either. So what do they do?
Well, if Apple/Google can talk someone else into hosting their compute racks, in such a way that the CapEx of deployment is Apple's/Google's, but the initial few years of OpEx and revenue for the effort winds up on that other party's balance sheets — then things could work. It wouldn't make money, but it also wouldn't (look like it's) costing Apple/Google any ongoing money — so they'd be able to keep the project going for its first few years, until user education played out and people started demanding it.
What properties would this "someone else" doing the hosting need to have?
Well, they'd need to be a near-commodity business, always in desperate need of "differentiators" to swing customers — i.e. new things that are nearly nothing for them to set up and run, but which they can then bundle into some subscription service they're charging customers for, such that having this feature makes their $60/mo plan look just ever-so-slightly more compelling than their competitors' $60/mo plans.
And they need to have a willingness to eat any short-to-medium-term OpEx costs associated with doing so, looking toward the long-term profits of such systems. They need a long demonstrated pattern of doing exactly this, over and over.
Ideally, they'd be paying virtually no "real" OpEx — as they'd already have some under-populated DCs laying around, with bulk-purchased power commitments and bandwidth provided as some kind of internal sweetheart deal.
Even more ideally, they'd have lobbyists who would get them massive government "technology evolution" subsidies for doing anything like this, that would more than pay the OpEx costs.
Know any companies like that? Because I sure do!
---
That being said, I would imagine that the math would work out slightly differently for different residential-ISP customer-base compositions.
It might be impossible to launch "workload offload" as a feature in the Bay Area or other tech-hubs at first, as those would be unprofitable if given away for free, due to the number of novelty-seeking nerds who'd actually make use of (apps that make use of) the service from day 1. The ISPs would likely get quite irritated if Apple/Google were coming into their DC to constantly rack more and more of these servers — even if the literal OpEx works out, they'd have to staff up their DC ops just to handle the increased hardware churn rate!
As such, I'd expect an ISP's workload-offload offering, to be something rolled out first in big cities that aren't tech hubs, and "proven out" there, mostly by users using the feature entirely unaware that they're doing so (because it's the app on your phone that decides to launch a workload, not you-the-user!)
Viral user education about the benefits of such services would filter out from such cities, to the rest of the world, where demand for them would build over the course of maybe... two years? — for ISPs to then start actually billing (and usage-based billing, with flat-rate billing only on premium data plans!) for the service.
It might work for a usecase you have in mind but in general, it can't work. And it assumes that the world is a perfect place where the incentives are aligned and that ISPs cooperates and that you'd actually want to expose your phone. As if the tech we have (mobile networks, phone batteries, coverage) would allow for it, which it don't.
And somehow denial of service attacks is only worth mentioning when you have a dedicated PC with proper 100+mbit internet but not when you have a battery powered phone with wireless connection?
And I truly fail to see how all anyone could even argue that all that complexity would be better than direct access.
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.