Dear Akamai, you got a /32 there not a bunch of /48s - how to break Facebook and annoy lots of users

[Bill Walker]

Sorry, just had to reply, this section of your email is
brilliant!!! Shame I can't convince my bosses the only way forward is
distributed content.... 

On Mon, 20 Aug 2012 15:44:46 -0400, Patrick W.
Gilmore wrote: 

> One last note, on a slightly more personal nit to
pick. People have been screaming about the "exponential" growth of the
table for well over a decade, and how the world was coming to an end Any
Second Now. I double-checked Nick and he is right, the sky is not
falling. Of course, it is important to not waste slots needlessly, or
otherwise be silly with a limited resource. But The End is not nigh.
>

> I've been doing this for a little while now, and my biggest fear is
not another order of magnitude in the v6 table. Far more likely to
destroy the Internet is the growth of Mbps, Gbps, Tbps - in fact, some
would argue it has already caused us harm.
> 
> The only realistic way
to manage the growth of things like VoD is massive distribution of
content. Everyone who has a _LOT_ of traffic is following in Akamai's
footsteps by placing non-network connected caches inside broadband
networks. Assuming ISPs treat content providers alike, you will see this
problem with many content companies.
> 
> Without this distribution, I
posit the Internet would have already failed. To put this in
perspective, 1 in 5 bits on most broadband modems worldwide come from an
Akamai server. Google has similar traffic, NetFlix has a lot of traffic
in the US and a non-trivial amount in other countries, etc. It seems
more than obvious to me the real danger is creating obstacles to
distributing traffic more widely, not whether we have a few thousand
more or even a couple orders of magnitude more prefixes in the v6 DFZ.
>

> But then, maybe I'm biased....
> 
> -- 
> TTFN,
> patrick
> 
> P.S.
Regarding the Subject line: Jeroen, we have different definitions of
"lots of users".

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20120820/54f2c84c/attachment.htm>