[165839] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: iOS 7 update traffic

daemon@ATHENA.MIT.EDU (Carsten Bormann)
Mon Sep 23 09:53:56 2013

From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <aapprzfzv6.fsf@ext-dhcp-174.eduroam.unibe.ch>
Date: Mon, 23 Sep 2013 15:50:30 +0200
To: Simon Leinen <simon.leinen@switch.ch>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On Sep 23, 2013, at 15:10, Simon Leinen <simon.leinen@switch.ch> wrote:

> Glen Kent writes:
>> One of the earlier posts seems to suggest that if iOS updates were
>> cached on the ISPs CDN server then the traffic would have been
>> manageable since everybody would only contact the local sever to get
>> the image. Is this assumption correct?
>=20
> Not necessarily.  I think most of the iOS 7 update traffic WAS in fact
> delivered from CDN servers (in particular Akamai).  And many/most =
large
> service providers already have Akamai servers in their networks.  But
> they may not have enough spare capacity for such a sudden demand -
> either in terms of CDN (Akamai) servers or in terms of capacity =
between
> their CDN servers and their customers.

I have some anecdotal evidence that a large swatch of Telekom land in =
Germany was fed from two (2) Limelight servers in Frankfurt (?).  Of =
course, packet loss to them during Wednesday evening was around 50 %.
(I VPNed out of Telekom land to get my iOS 7 update, which was then no =
problem at all; that clearly shows that the access infrastructure wasn't =
overloaded.)

It doesn't help that Apple's update software has no way to make use of =
the results of a prematurely aborted transfer; this is a recipe for =
bistable behavior.

Gr=FC=DFe, Carsten



home help back first fref pref prev next nref lref last post