WebRTC P2P CDN carry no risk.
When I’ve written last time about WebRTC P2P CDN use cases, some were concerned about capacities and user experience. There’s one thing that was missing in all this:
All WebRTC P2P CDN vendors today include a traditional CDN as part of the solution (the term CDN here is used loosely to indicate a traditional server holding the resource).
Look at the illustration above. What you see there are a number of clients trying to reach a resource, using Peer5. To do so, they are directly connected to the server (the CDN) as well as to additional clients.
These clients decide in real time what pieces of the resource to get from the CDN and which pieces of the resource to get from other clients (also known as peers).
How do this decisions happen? Heuristics, with each vendor implementing a different heuristic. Here are a few examples:
- If this is a VOD, where latency is important, we download the next piece of the video from the CDN and try to download future pieces from other peers
- We connect the client only to peers who are geographically close, in an effort to reduce latencies and to remain within the same network
- When the resource is meaningful only when fully downloaded (an executable for example), we try using peers whenever possible and for whatever pieces of the files they hold at the moment
The end result? If the P2P component can’t find a peer that has the piece of the resource we need within the timeslot we need it, then we can always go and fetch that piece from the CDN directly.
What this really means?
Adoption WebRTC P2P CDN is risk free.
If you add it to your service, you stand to lose nothing at all:
- When WebRTC P2P can’t improve your performance or meet your goals, it will revert to using the traditional CDN
- When browsers don’t support WebRTC are used, then the service will again revet to using the tradition CDN
- When WebRTC P2P can be used to improve performance (be it latency, download time, bandwidth use) without harming the user experience, it will kick in
This makes me wonder why there isn’t more adoption for the WebRTC P2P CDN vendors out there…
the customer yelling at you because you used more expensive traffic from their mobile data plan is not a risk?
But this use case didn’t work out back in 2009 for Adobe, I am not surprised it doesn’t work this time either.
Agree with Philip (or blowing you past data caps), also there’s a privacy leak to the peer that you’re accessing the same resource. It’s a cool idea with big bandwidth/latency wins in same-LAN and same-provider cases, but not without significant problems.
I have to agree with Philipp and Randell. I’ve recently gone from having unlimited Internet through my fixed phone line to limited Internet through 3G/4G (with very expensive charges when I go over my allowance). I use a mifi for the 3G/4G so as far as my computer is concerned it’s just on wifi. In my current situation the thought of of a P2P CDN fills me with horror.
I suppose you could have an option to turn off the P2P part – but this would mean telling people what you’re doing upfront and making it understandable to non-techies (while being short enough that people actually pay attention), very easy to turn off, and so on. I suppose you could have P2P off by default – but you face the same issues explaining it to people and many just wouldn’t turn it on.
I’m not sure P2P CDN is going to be practical for everyday use cases. I am quite sure it isn’t risk free.
yeah, consent worked great for RTMFP Netgroups… oh wait, nobody uses it so the consent prompt killed it? 🙂
So much negativity here 🙂
The data caps issue is a matter of geography. Here in Israel, most are on unlimited plans – wireline or wireless. So in that sense, it is a matter market realities.
I disagree with Philipp :), I don’t think mobile data plans is the biggest issue, you can always enable it only in desktop clients. Is not what Skype does to promote clients to relay nodes? I’m not sure how is it in latest versions.
I think the problem is that in most of the cases the complexity and difficulty to manage, operate and support a distributed CDN are not worth the savings in bandwidth and other resources over well known standard CDN solution that provides out of the box support for more endpoints and solutions for content adaptation, security, logging….
The main use case of a P2P CDN is still in places requiring special security considerations (for example illegal content distribution).
Gustavo,
Thanks for the comment. I am not sure though what complexity and difficulty you are speaking of. The technical challenges are the ones addressed by the vendors in this space. The business ones are a matter of discussion. Assuming my proposition to you would be that you pay 50% of what you would have for the same traffic over your CDN – would that be a challenge for you?
There is negativity because you’re arrogant and make assumptions. Who cares if you live in Israel. That’s a one country. Data caps are a reality for lots of people; don’t just dismiss them because its convenient so you can make your point.
Not the first time I hear this about me. The point I was trying to make is that countries have different patterns – saying that data caps won’t work for a given use case is making an assumption. While true for some, it may not true for others.