The 100 Gbit/s problem in your network

Fri Feb 8 20:58:56 UTC 2013

On Fri, 2013-02-08 at 10:50 -0800, joel jaeggli wrote:
> On 2/8/13 9:46 AM, fredrik danerklint wrote:
> >>> About 40 - 50 Mbit/s. Not bad at all.
> >>>
> >>> Downloading software does not have to be in real-time, like watching
> >>> a movie, does.
> >> In both cases it's actually rather convenient if it's as fast as
> >> possible,
> >
> > Yes. What I would like to have is to allow the access switch, which a 
> > customer for an ISP is connected to, to let the customer have 1 Gbit/s
> > of bandwidth if the traffic is to or from the cache servers at their
> > ISP.
> >
> You're positing a situation where a cache infrastructure at scale built 
> close to the user has a sufficiently high hit rate for rather large 
> objects to be more cost effective than increasing capacity  in the 
> middle of the network as the bandwidth/price curve declines.  My early 
> career as an http cache dude makes me a bit suspicious. I'm pretty 
> confident that denser/cheaper/faster silicon is less expensive than 
> deploying boxes of spinning disks closer to the customer(s) than they 
> are today (netflix's cache for example isn't that close to the edge 
> (would support 2-10k simultaneous customers for that one application per 
> box), it aims to get inside the isp however) when you add 
> power/cooling/space/lifecycle-maintenance (I'm a datacenter operator) if 
> it wasn't the CDN's would have pushed even closer to the edge. Of course 
> if you can limit consumer choice then you can push your hit rate to 100% 
> but then you're running a VOD service in a walled garden and there are 
> plenty of those already.
> 
> That said provide compelling numbers and I'll change my mind.

The "problem" with increasing capacity is that it opens up captive
eyeballs to innovative services from "outside": monopoly operators will
prefer to deal with CDN providers & the like and keep control.

Sincerely,

Laurent