Showing posts with label P2P bandwidth. Show all posts
Showing posts with label P2P bandwidth. Show all posts

Wednesday, May 21, 2008

Finally, the "Net" in Netflix; plus, the bandwidth question

Netflix has released a set-top box that users can use to receive movies directly over their broadband Internet connections. The box, developed by the silicon valley company Roku, has received good reviews on CNET and PC Magazine for its nice interface and more-or-less good performance over most home-broadband connections.

Advantages for users
  • No propagation delay from snail-mail shipping DVDs - no more waiting for 2 days.
  • No need to mail back DVDs.
  • Ability to switch to another movie or show - you are not stuck with that wrong movie you placed in your Netflix queue.
  • No extra cost except the broadband connection and the $99 cost of the box.
Advantages for Netflix
  • Savings in storage, handling, and shipping costs (to-and-fro) of the DVDs. Theoretically, if all Netflix subscribers switch to this technology then Netflix can close its nation-wide distribution centers and also save on postage costs: assuming that Netflix pays the standard first-class mail rate of $0.42 to USPS, thats a $0.84 saving per mailed DVD. I think that the present overall cost of circulating a DVD to a user may be well above a dollar for Netflix.
  • Centralized content control and the ability to speedily deploy new movies, shows etc.
  • Ability to expand beyond the US in a relatively painless way - no distribution centers to set up, no additional staffing costs (analogous to how iTunes operates in Europe).
And the Bandwidth cost?

The Netflix system delivers video streams at 2.2 Mbps, 1Mbps, and an even lower bit-rate depending on the connection between the server and the receiving box. The quality naturally degrades according to the lessening bitrate, but let us assume that a user has a great Internet connection and that no bandwidth bottleneck exists between the serving CDN and this user and so s/he can watch the best 2.2Mbps quality for the entire 120 minutes of a movie.

Size of the movie:
2.2 Mbps x 7200 seconds (i.e. 120 minutes) = 15840 Mb = 15840/8 MB = 1980MB = 1980/1000 GB

= 1.98 GB.

So downloading a movie at the best quality means the CDN serves about 2GB of data to the end-user's Netflix- Roku box.

To arrive on the bandwidth costs, lets go with the figures presented in this PBS article about CDN pricing. Disclaimer: This article is more than a year old, and I have been reading about CDN price wars all along. So the current cost of bandwidth may actually be lower than stated.

From the PBS article the costs for streaming a 2GB stream to a user (assuming volume wholesale pricing):

Single server: $0.26
Akamai : $0.32
P2P: $0.0024

Ok first off, I like the P2P number the most but lets ignore that because P2P may not be able to compete in quality with CDNs (See my paper on this). Even if Netflix uses the most expensive Akamai CDN, they are getting away with just $32 cents per movie instead of the dollar-plus cost in the DVD-mailing model. Even if we assume a few more cents of overhead per movie due to the technology costs, I think Netflix is well in the green with this.

The beauty of Netflix's strategy is that they will be able to gradually wean people from the DVD mailing model to the this online content delivery model because of the convenience of the latter. And this without jeopardizing the DVD mailing model because there is no cannibalization here - its perfect migration with one less DVD mailing customer corresponding to one more streaming customer. Every DVD streamed will add up and lead to a drastic reduction in Netflix's operating costs.

Meanwhile, Roku will probably make some money out of their $99 box.

Last question: And the ISP?
Thats for later. Enjoy your movies.



Update: Netflix bandwidth costs come to about $5cents as of June 2009, according to this article.

Wednesday, May 14, 2008

On dear peer-to-peer

I will be presenting a paper* at the IEEE IwQoS early next month containing the analysis of a large scale peer-to-peer live video multicast streaming session on the Internet. Think of the P2P video multicast system as the Bittorrent for video streaming (instead of file-sharing). The system was sending a video stream of a baseball match to 10s of thousands of viewers on the Internet using P2P technology.

The presentation and paper are available online. Here are two results from the paper that in my opinion warrant particular notice.

Figure 1 shows the aggregate download and upload bandwidth consumed by the P2P system. Note the scale on the Y axis - Gbps! I am wondering, this is only 1 video stream. What happens to the Internet when 1000s of such streams become available online? Were networks designed for such usage?

An interesting artifact in this figure is that the aggregate download rate of all peers exceeds the aggregate upload rate of all peers. The difference was made up through "bandwidth injecting super-servers" of the content provider. Still, it is absolutely remarkable that the amount of additional bandwidth required is almost constant even as the number of peers increase (Figure 2).
Figure 1: Total bandwidth. Click to enlarge.

In Figure 2, you can see the number of concurrent peers in the P2P system over the time-period of the streamed game (hour 4 to hour 8). Look at the rate of change of peers in (peers joining, peers leaving) the P2P system. Keeping in mind that most of the bandwidth comes from these very peers, it is remarkable that this highly dynamic pool of peers is able to sustain the P2P system. Things get very exciting at the end of the baseball game (Hour 8): Everybody wants to leave. Now that is a big challenge for any P2P system.
Figure 2: Peer Dynamics. Click to Enlarge.


*Joint work with Jatinder Pal Singh (T-Labs) and Aditya Mavlankar, Pierpaolo Baccichet, and Bernd Girod (Stanford University)