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.
Hi Joostteam,
This is very interesting and it definitely adds to the sum of knowledge. I have also done some analysis into Joost’s network usage, strategy etc, but the 390kbps figure is new to me.
I’d be really interested to hear how you got it, as I have also done a few pieces on Babelgum, VeohTV and the Konitiki based BBCs iPlayer and 4oD. The Veoh one is unpublished but the others can be found here.
I have all the Wireshark data so if you can help me with the method, I can help you with the results!
Cheers
Jeremy Penston
Jeremy,
I remember reading your analysis. Very interesting. The number 390kbps was discussed in the Joost IRC channel (irc.freenode.net #joost) among other beta testers. It is certainly not confirmed but this is the best I have to work with. I am sure it is not too far off the mark.
Until an official number is made available by Joost I will go by it.
Cheers
Aren’t you forgetting audio data?
Mr Alpha,
The estimated 390kbps actually include both Audio and Video. Most likelly 96kbps audio.