A couple years ago, Apple unleashed an IOS update which made the news
because network operators reported serious congestion on their networks
as everyone and their uncle tried to download the gig+ package at 11:00 PDT.
Was the problem solved simply by Apple staggering the announcement of
downloads? or were there distribution network changes also made to
reduce the load?
In Canada, during net neutralirty hearings, it was revealed that
cellular carriers zero rated over the air updates. I know my iPhone
gets updates without me asking for them, only getting a "update ready to
install" while on a long cycling ride (aka: must have used cellular data).
Does anyone know whether this is pushed by Apple who has gotten the OK
form individual carriers, or is it pushed by carriers (with Apple's OK)
in a low priorioty stream that doesn't cause congestion on cellular
network? (carriers delivering content in "push mode" would change their
role).
Peering would reduce an ISP's reliance on transit provider (and thus
load on transit providers) hut still present same problem on the ISP's
internal network.
Also, doesn't Apple use a CDN such as Akamai or L3 to deliver content
like that?
Considering Apple has been out of the server business since 2010, Would
ISPs really bother installing/configuring (and finding a spot on a rack
shelf ) for a Mac Mini only to reduce load once a year ?
Server is an app now, any MacOS can have it running.
But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini
or iMac at a carrier hotel? If the Server App could run on Linux, or if
OS-X could boot on standard servers, perhaps, it it seems to be a very
bad fit in carrier/enterprise environments.
Implementation will be a little tricky, because you need your
customers to look a record in your domain.
I've tried reading some about it.
The cache server app registers with Apple its existence and the IP
address ranges it serves
When a client wants to download new IOS version, Apple checked and finds
that the client's IP is served by the caching server whose "local" IP is
a.b.c.d (akaL the inside NAT IP address). Tells client to get version of
software from that IP address.
The DNS TXT records are used by the Caching Server to get the list of IP
blocks it can serve. (not needed in the target small office
environments where everyone is on same subnet and the caching server can
tell the apple serves the one subnet it seves).
Apple does use CDN’s and does peer quite a bit as well.. What I have seen is our peering with Apple goes to a certain level of bandwidth and then spills over to CDN’s that we are either peered with or have on-net caches. From our network perspective it’s simply a matter of ensuring there is enough capacit on the peering links and/or cache capacity. If both of those options are exceeded then upstream transit starts to fill in the gap (only seen that happen once).
MacMiniColo is now part of MacStadium, we have tons of Mac Minis and Mac Pros in Las Vegas NV, Atlanta GA and Dublin Ireland. We are currently moving out of SWITCH's NAP2 and into zColo Las Vegas. Our speciality it private clouds on the Mac platform for CI/CD environments.
My best experience with Apple has been directly peering with them. Definitely handles the update issue without putting strain on transit links. Apple is very well connected.
My best experience with Apple has been directly peering with them.
Definitely handles the update issue without putting strain on transit
links. Apple is very well connected.
We've been looking into the caching server bit lately given that we're not due to get an official Apple node for at least another year yet.
It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a lot easier to implement.
Curious as mentioned if anyone doing this on scale? I kind of doubt it but love to hear otherwise. My assumption is this is more Enterprise focused than ISP
*nods* It appears to be very enterprise focused, but then it's mentioned on their PeeringDB page, so that makes one wonder.
It doesn't seem like it would be easy for an ISP to manage given that they can't set the required domain search field via static or PPPoE. That would leave DHCP as the only way to assign that field and then that's assuming that whatever router is at the customer location passes that field through to the end user devices.
It seems like it would be a lot more effective to ditch the requirement for the domain search field and just let the caching server tell Apple what prefixes it supports and there be an automated verification system using RIR records that the request is legitimate.
While we don’t use Apple's caching servers we do have transparent caching in place which nets us about 82% of their content being serverd locally. On a big IOS update it will probably be close to 99% for that one title.
Luke Guillory
Vice President – Technology and Innovation
The cache thing mentioned in their peeringdb entry appears useless outside of an enterprise environment where a DNS search domain can be forced. Ideally the cache should be able to speak BGP and learn prefixes that way, especially if Apple can't or won't peer in a region.
While we don’t use Apple's caching servers we do have transparent caching in place which nets us about 82% of their content being serverd locally. On a big IOS update it will probably be close to 99% for that one title.
Would you be open to elaborating a bit on how that’s set up on your network?
