Joost used to have a strategy of targeting the fat belly of content (in the midst between the head and the long tail). Seems to me that it’s become more tail than belly…

It effectively works as follows:
When you view a program, small encrypted packets of videocontent are called to your client (locally installed now, part of a browser plug-in in the new version) from other computers and some caching relay servers that are installed around the world.

The videopackets you view are cached on your local harddrive in a “heap”. If there is demand from other viewers roughly in your network neighbourhood (Joost operates some P2P algorithms that avoids to call in packets from a machine at the other side of the globe) you send packets out too.

With my Joost client the cached heap went up to about 1 GB, but then seemed to operate in a FIFO mode (the heap did not grow further in size).

The advantage of P2P is in particular during mass events with live streams, like the opening of the Olympic games. In that case many people look at the same content, so the packets are in many heaps and load on central servers can be kept down to a few. This contrasts with non-P2P streaming, where in such cases central server loads go up to hundreds of thousands of parallel streams.

When you have a sufficiently broad Internet Access pipe and the (encrypted) packets are reasonably small (e.g. the Ethernet MTU packet size of 1500 bytes), livestream delays are acceptable. For a 500 kbit/s / 60 kByte/s videostream you’ll receive about 40 packets per second of 1500 bytes. So there is quite some “wiggle room” for a P2P distribution with at most a 1 to 2 second delay, considering that with 32 P2P-splits you’ll could reach 4 billion devices. That is a number that is far larger than the current Internet host count and equals the current human population in possession of a (mobile) phone.

Considering that the largest livestreaming events around the world are viewed by near 2 billion people (Olympic ceremonies, Soccer world championship finals etc.) a P2P approach is the most logical and efficient route to go.

As could be glanced from the Beijing Olympics, where the Chinese supplied livestreams via PPlive (also P2P), the current largest viewer bases are nearing the 1 million (still a 2^10 scale down from the ultimate global viewer base to be expected in an all digital TV over IP distribution environment).

Companies active on the Internet attempt to outrun the more “classic” approach of IPTV, which requires operator control over IP Multicast routing and strict bandwidth guarantees, while a P2P approach with local cache buffers is a bit more tolerant of bandwidth variation at the cost of some delay.

There has been some math done in the past on the total amount of professional TV content, viewing time per day and viewer bases, which indicates that it is far more efficient to put it in local P2P.

This math however does not apply for most UGC that is only requested by a rather small group (hundreds or mere thousands of viewers for a particular clip over one or two years).

As the real pay-off of deploying P2P technology is in handling massive viewer bases for live videostreaming, the fact that many of the current P2P videoclients continu to run in the background, is illogical. Effectively, one can argue that browser-based plug-in software, that is only active during viewing time, already suffices to deliver most of the distribution efficiency benefits of P2P.

In reality, a plug-in can have as many install and upgrade challenges as a standalone application. We’ll see how it works out in this case.