Joost P2P protocol chewing about 35% of the used bandwidth?

Aug 15 2007 Update:

I had some good feedback from folks on the IRC channel regarding Joost P2P overhead. One comment was about buffering. Joost said they did not buffered much in the background… like 5 sec maximum. So I did not took that into account. But looking deeper in the traffic distribution it is clear that Joost actually buffer a lot more than expected. Out of a 3:30 minute clip I usually get 30 to 33 sec of buffered video (Joost stop sending me data 30-33 sec before the real-time playback).

What this mean is that I have to account for this buffering in my calculus. With this in mind I did took more traces and analysed 7 more clips. What I noticed is that the overhead appear to be much less that 35% in most cases. For 6 of the 7 clips I had about 14-17% overhead.

The last clip was different. It actually came to 29.3% overhead. What appear to have appened is that multiple peers outside of Joost sent me bits and peices for this one clip. The result was that the overall average bandwidth was much higher than usual and many more UDP packets where received. At the end I suspect that some of those packets where wasted as being “duplicate” of already received content and just got discarded by Joost… resulting in higher overhead.

It therefore appear that as the number of peers grow that overhead grows too (make sense actually).

Original post is below:

Tonight I played some Joost number games (note that those numbers have not been confirmed by Joost. I guessed some by studying network patterns and got others by discussing with a few people involved in beta testing the platform). I have been wondering for a while about how much overhead Joost P2P protocol might add on top of the actual video content.

With the new number of 390kbps for Joost video before packetization and P2P wrapping it became easy to do an estimation of what the actual overhead might be. Here is the actual explaination:

Joost video playback will generate about 80KB/s of inbound traffic on an internet connection (derived via network interface traffic monitoring). This is about 640kbps (a very interesting study done by students of the Carnegie Mellon University rated inbound traffic at 700kbps).

Joost video traffic is UDP based. A typical Joost UDP packet is of 1101 bytes. If you remove Ethernet Frame Data, IP header and UDP header you are left with 1059 bytes of payload. 1059 bytes is 96.19% of the original packet size.

Therefore out of the 80KB/s (640kbps) about 616kbps (96.19% * 640kbps) is used for Joost data.

616kbps – 390kbps (max Joost video avg bit rate) = 226kbps for P2P overhead

226kbps is equal to 36.65% overhead (226 *100 / 616)

If the actual bandwidth usage number of Carnegie Mellon University is more accurate than mine then the actual overhead is even worst. It would clock at about 42%.

Some of this overhead is most likely attributed to FEC (Forward Error Correction) and encryption.

The question is how does Joost overhead compare with other streaming protocols? I don’t know. Let me know if you have comparison numbers.

Update:

Some of the 35% overhead might also be related to:

• Ads being downloaded along side the content,
• Buffering of content (although Joost stated many times the the client was only keeping a small buffer in the range of 5 seconds)

More research will be required to measure the actual buffering effect and Ads download on the observed overhead.