No. The problem is that Apple is capping the bandwidth for each file downloaded.
First of all, I'm currently connected to the Internet by an OC-3, which is rated for 155mbps. Furthermore, I'm connected to Internet2 by an OC-12, which is rated for 622mbps. It's a weekend, so traffic and congestion over these links should be relatively low. I believe this qualifies as an "amazingly fast Internet connection."
Secondly, Apple is contracting with Akamai to provide distribution services. Akamai works by mirroring content on its [thousands of?] servers around the world. These servers are strategically placed in the core networks of ISPs. The Akamai DNS resolution system automatically detects your location and routes the data to you via the topologically closest server. Chances are that, unless you are served by a very minor ISP, you have an almost direct link to an Akamai server. This means that you
should be able to download content from Akamai more or less at your rated line speed.
Try this. Open Terminal and type the following:
host www.whitehouse.gov
You should see something like this:
www.whitehouse.gov is an alias for www.whitehouse.gov.edgesuite.net.
www.whitehouse.gov.edgesuite.net is an alias for a1289.g.akamai.net.
a1289.g.akamai.net has address 209.124.184.143
a1289.g.akamai.net has address 209.124.184.150
As you can see, the White House uses Akamai to distribute its Web content. (The White House Web site is probably quite popular, and building a server that can handle the amount of data, including streaming media, to be transferred would be quite expensive.)
Chances are your IP numbers are going to be different--that's because Akamai's DNS servers will detect your network location and will return the best IP addresses for you to use.
Take one of the IP addresses that you come up with and type the following into Terminal:
traceroute [IP address]
You should also be able to use:
traceroute www.whitehouse.gov
You should see something similar to the following:
traceroute to 209.124.184.143 (209.124.184.143), 30 hops max, 40 byte packets
1 * * *
2 225-188-165-209.gci.net (209.165.188.225) 38.959 ms 11.342 ms 25.671 ms
3 161-128-165-209.gci.net (209.165.128.161) 6.054 ms 8.079 ms 5.842 ms
4 136-128-165-209.gci.net (209.165.128.136) 7.355 ms 12.204 ms 15.642 ms
5 178-129-165-209.gci.net (209.165.129.178) 56.088 ms 50.717 ms 95.403 ms
6 221-129-165-209.gci.net (209.165.129.221) 57.662 ms 68.27 ms 56.988 ms
7 acr2-so-1-2-0.seattle.savvis.net (208.172.81.153) 38.712 ms 67.25 ms 80.858 ms
8 acr1-ae0.seattle.savvis.net (208.172.83.45) 72.198 ms 44.956 ms 43.981 ms
9 bpr3-so-0-0-0.seattleswitchdesign.savvis.net (208.172.83.61) 37.994 ms 39.336 ms 37.959 ms
10 peer-1-networks.seattleswitchdesign.savvis.net (208.173.49.54) 37.517 ms p4-1-1-0.r04.sttlwa01.us.bb.verio.net (208.173.50.66) 74.252 ms 42.668 ms
11 xe-3-2.r00.sttlwa01.us.bb.gin.ntt.net (129.250.2.137) 214.729 ms 40.494 ms 36.567 ms
12 ge-0.uw.sttlwa01.us.bb.gin.ntt.net (129.250.10.193) 69.217 ms 86.734 ms 36.522 ms
13 ccar1-ads-ge-0-0-0-0.pnw-gigapop.net (209.124.176.32) 88.709 ms 56.494 ms 69.827 ms
14 a209.124.184.143.deploy.akamaitechnologies.com.184.124.209.in-addr.arpa (209.124.184.143) 49.389 ms 39.004 ms 52.607 ms
Obviously, your routing and destination will differ.
The example I showed above is not quite correct--the university I'm connecting via blocks traceroutes, so I had to use an external server, resulting in a more circuitous route. If traceroute worked over this connection, I should reach the destination in 7 hops, and it would show that I'm connecting over the 622mbps link to the Pacific Northwest GigaPOP in Washington, where the closest Akamai server resides--basically, I'm almost directly connected to the Akamai server and shouldn't have a lot of competition in accessing it.
If your ISP has traceroute blocked, you can see an example using the route from DNS Stuff's server to its closest Akamai server here:
http://www.dnsstuff.com/tools/tracert.ch?ip=www.whitehouse.gov
DNS Stuff's server is 5 hops away from its nearest Akamai server (in Washington, DC and maybe near Dulles, Virginia, judging by the "iad" in the last router's hostname--you can often tell the location of intermediate routers by various three-letter city codes, often mirroring nearby airports). That site is showing a 2.3ms ping time to the Akamai server--extremely good and indicative of a very high-speed and uncongested connection to it.
The point is, Akamai has developed their network of servers to be as close to the "edge" of the Internet (relative to the consumers) as possible in order to reduce the competition for bandwidth on the Internet's backbones, which therefore maximizes the possible data transfer speed. (Data transferred solely by the Internet often travels through very congested backbones, which reduces the speed at which you can download from a given server. The more routers the data has to go through, the more competition for bandwidth you have. For an extreme example, traceroute to a site based in a foreign country, such as www.kremlin.ru, which takes me 21 hops over several different networks. Each hop is a potential bottleneck.)
My point in describing this is to show that when using Akamai, there is absolutely NO reason for any slowdown--no matter how many customers are downloading from a given content provider at once. That's the whole selling point behind Akamai's network: it scales to any demand, no matter how large. Even high demand that is localized (say, every user on Verizon on the East Coast) would not cause slowdowns on AT&T's West Coast network, since the Verizon users would only be accessing content from Akamai servers located on Verizon's network in that area. And with multiple servers directly connected at each location (most likely collocated at the ISP and connected by GigE or even 10GigE) balancing the load, even Verizon users probably wouldn't notice a slowdown. It would take most of the entire Internet population grabbing content from every available Akamai server at precisely the same time to cause a noticeable slowdown.
So, why are downloads from the iTunes Store so slow? My guess is that, to save money, Apple has had Akamai implement a cap (or is only paying for a certain level of service) on iTS data.
If I'm connected via a 622mbps OC-12 to the nearest Akamai server, why am I seeing download speeds of about 80KB/sec (0.625mbps, or 0.1% of the available line speed)? Even factoring in the last-mile connection, which is an 802.11b wireless network, I'm still seeing less than 5% of the available speed. And it's a weekend in an otherwise unoccupied building, so I shouldn't have any competition for the wireless network's bandwidth, either. I know the university does not cap individual connection's bandwidth either--first of all, it's outlined in one of their policy statements: all data connections have equal priority--there is an aggregate cap for the public wireless and residential hall networks, but it's well above the saturation point, and the network is fairly calm on weekends. Besides, I can run a speed test to a server located nearby on the general 155mbps OC-3 link (which is even more congested than the Internet2 OC-12 link) and come back with upload and download speeds of about 8-9mbps, so I know that I should be able to get the same from the Akamai server. And my private Internet connection (an EV-DO card rated for 2.4mbps and which consistently gives me 1.1mbps) shows almost the exact same data transfer rate. My 5mbps cable modem at my permanent residence also shows a similar bandwidth usage when downloading from the iTS.
I'm also inclined to believe that it is a per-connection (i.e. per individual file transfer operation) cap, because when I downloaded two files with the new iTS download mechanism, which allows multiple file transfers at once, the bandwidth usage approximately doubled (to about 160KB/sec). When the first file ended, the bandwidth used dropped back down to approximately 80KB/sec.
This is all speculation, but given the evidence I've gathered, I can see no other reason why downloads are so slow. Most likely, the majority of iTS users may not notice the exact transfer speeds, but they will notice that it's taking fully half of a day to download Cars or Pirates of the Caribbean. With the speeds available on today's Internet connections, 0.6mbps is an abysmally slow speed to restrict data transfers to. Perhaps Apple has implemented that restriction to allow the iTS to make money (my guess is that distribution is their greatest overhead cost), but I don't know the specific numbers. The bottom line is that Apple needs to take action to ensure high data transfer rates if it wants to ensure customer satisfaction, and ultimately, to be competitive, in the distribution of media.
I hope this helps clarify the subject.
One more thing: I believe that podcasts are not hosted on Apple (or Akamai) servers. The podcasts shown in iTunes are simply a collection of links to outside servers. Therefore, the download speeds of podcasts should be completely independent of any Apple/Akamai speed cap. The reason for the slower speeds is likely because most podcast producers operate on limited budgets and probably host their files on slower Internet connections (relatively speaking) or on collocated servers with speed and data transfer caps to save money. I highly doubt you'll see a speed increase on your DiggNation video podcasts no matter what happens with Apple. I could be wrong: Apple may offer podcasters a free hosting platform, but judging by Apple's previous actions, I highly doubt they would be willing to give so much bandwidth away for free.
PB G4 17" 1.67GHz, G4 350 PCI Graphics (Yikes!) Mac OS X (10.4.7) PB: 1GB RAM
