We use a commercial product from https://qwilt.com/. Here is some info for the month of August, while it does reduce transit the customers are also getting better speeds when it comes from us. We span links from our core to the server in order to get visibility into the server, this does cause some issues since we’ve expanded our core outside of one location.
[cid:image003.jpg@01D3306F.82F47BC0]
[cid:image004.png@01D3306F.82F47BC0]
Luke Guillory
Vice President – Technology and Innovation
Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084
Disclaimer:
The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
I used to run a transparent cache that redirected tcp/80 traffic to a squid instance that was configured to hold the objects for an extended period of time and ignore the do-not-cache type options sent from the CDNs.
A quick search in your favorite AltaVista location returns URLs like this:
I would have to read the stuff again, but my understanding is:
caching server starts.
caching server registers with Apple, gives it its local IP, as well as
the IP ranges that it manages.
When a client wants something, it first reaches out to an Apple server.
That server decides which content server is nearest to the client, and
if there is a caching server in the same network, will give the client
the IP address to access that local caching server. (and this is where
there is NAT friendliness , as other have pointed out, designed mostlty
for enterprise).
The business about TXT records is to allow real IPs with multiple ranges
to be used. I *assume* that it is the caching server which reads those
records upon startup and then transmits it to Apple when it "logs in" as
a caching server. You can have up to 24 chained TXT records to list all
the IP blocks you can service.
They also say the domain needs to be in your domain search field on your end user device, meaning I think the enduser device looks up whatever default hostname, appending whatever domain name is in your client. Your authoritative DNS then returns the IP of your Apple cache.
Apple seems to be quite behind on their node roll out. They were talking about our Indianapolis IX getting one this year, but now we're at least another year away from one.
I've never quite understood CDNs and why more of them aren't more nimble. For most of them when we talk to them they're talking a full rack or more of deployment. Why haven't they all figured out how to do a single box or even a handful of boxes?
Even if you're not doing Minis at that scale they easily fit into a 1U space. Someone said minis aren't rack friendly and no, they aren't rackmount standalone, but just add a 1U shelf.
Apple's peering/CDN strategy has completely changed in the last few years.
(Hi to my friends on the list here!) They do a much better job getting bits
delivered for this stuff now.
Some of the IOS coding is still occasionally not the most well thought out
when it comes to data retrieval, but it's gotten better.
A couple of the CDNs have one or multiple rack minimum deployments.
You can get a Netflix box in 4U that does many TB of storage, BGP, etc. CDN in a box.
A lot of them were just built with big scale in mind, based on the fact that the US has 10 or so major sites and the scale needed to serve that much of the US. Now it's all about getting to the edge, but they haven't made their deployment smaller to accommodate. Some parts of their businesses evolve very rapidly, while other parts of the same business plod along ridiculously slow.
Not meaning to pick on Apple (or Microsoft who's in the same boat), but they're the original reason for this thread. Most of Apple or Microsoft's peak usage (major OS updates) could fit in a 10 year old desktop's RAM drive, provided the rest of the system could keep up with the throughput needs.
I'm surprised more companies haven't more quickly adopted something the configuration of the Netflix box. It doesn't have to do everything, just do the high demand stuff well.
Serving different file types requires different things. If you
are serving the same episodes from storage it's much different than
live content, or serving dynamic updates based on entitlement
levels, etc.
Not all CDNs are like Netflix, for better or worse.
There are also considerations with the throughput capability of the
hardware too.
500T in a couple RU is nice and all, but if the box can only push ~15Gbps
because of bottlenecks in hardware, or the kernel isn't tuned, it's might
be a lot less useful depending on the content, as Jared points out.
Oh, thanks Jared, I don't know what Netflix puts in my caches that they have
locally here on -site... can I know ? Will the OCA portal show my what
types of things are in there ?
