[160656] in North American Network Operators' Group
Re: The 100 Gbit/s problem in your network
daemon@ATHENA.MIT.EDU (Ryan Malayter)
Mon Feb 11 00:46:14 2013
In-Reply-To: <511644F6.6020900@fredan.se>
From: Ryan Malayter <malayter@gmail.com>
Date: Sun, 10 Feb 2013 23:46:01 -0600
To: fredrik danerklint <fredan-nanog@fredan.se>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 9, 2013, at 6:45 AM, fredrik danerklint <fredan-nanog@fredan.se> wrot=
e:
> No. Streaming from services, like Netflix, HBO, etc..., is what's
> coming. We need to prepare for the bandwidth they are going to be
> using.
Then work on your HTTP caching infrastructure. All these services already us=
e a proprietary form of HTTP adaptive streaming, either MSFT, Adobe, or Appl=
e. These technologies are being unified by DASH in the MPEG/ISO standards bo=
dies.
Adaptive HTTP chunk streaming gives you the best of multicast-like and cache=
d VoD behavior, exploiting the temporal locality of popularity in content wh=
ile not requiring multicast.
As a content publisher, I must say it works wonders for us so far, even with=
just two bitrates. There is a huge HTTP caching infrastructure out there in=
businesses, schools, and other orgs that is unused by other video transport=
s; even plain HTTP downloads usually overrun cache object size limits.
The Olympic streaming in particular showed how well HTTP chunk video can sca=
le; dozen of screens in my org showed the same content all day from local ca=
che, with no noticeable spikes on our transit links.
Is HTTP as efficient a protocol as possible for transporting video? No, but 1=
K of headers per 1M of content chunk
puts it within 0.1% of netcat. And "working now with widely deployed infrast=
ructure" beats "stuck in Internet Draft forever".=
