4 ms·

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 acces

• 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? ;)
  • caf 2y ago
    If Google and/or Apple have gone to the trouble to build the network side of this edge-computing infrastructure, presumably it's because they think their customers will see enough benefit from this to buy more devices. But then why would they tie this to the customer's telco being on board? Apple/Google surely know how to run a data centre, and there doesn't seem to be much that couldn't be hosted just as well by them as by each telco; on the contrary, owing the network side of the stack is going to make it a lot easier for them to make performance, security etcetera guarantees. And of course it means all their customers can be on board on day 1. 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).
    • derefr 2y ago
      > Apple/Google surely know how to run a data centre, and there doesn't seem to be much that couldn't be hosted just as well by them as by each telco 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 and/or, userA → ispA → backbonePath → ispB → userB you'd instead have: userA → ispA → backbonePathA → Apple/Google → backbonePathB → ispB → userB Apple/Google would have to pay for the bandwidth to connect the two users to their own network — where, in the case of a user running e.g. a BitTorrent seed-box, this is an unbounded downside risk! (Remember that by the design of such an "offload" system, it does not charge the customer for network traffic that transits through it — only for compute. Just like Cloudflare doesn't charge for basic proxying, only for Cloudflare Worker compute time. This will only ever make financial sense if your edge compute is "in" the existing connection path — i.e. hosted in the same DC as one of the path's existing hops.) 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.