The bit of WebRTC which everyone outside the industry tends to overlook is the datachannel, partly because it doesn't fit with the popular - but wrong - view that that WebRTC is just "Skype in your browser".
WebRTC is neither just about voice/video calls, nor just about browsers.
I've dealt with non-browser WebRTC several times before, and I'm drilling into it further for the current update to my research report (due for imminent publication) so I'm not focusing on that here. *NEW* March 2014 Disruptive Analysis WebRTC Report & Forecast Update DETAILS HERE
Instead, I've been thinking closely about some of the datachannel use-cases I've been seeing. Probably the most-common is file/screen-sharing, typically alongside various types of conferencing functionality. While there's a few interesting sub-categorisations (co-browsing, shared whiteboards etc) most are fairly intuitive replications or extensions of tools seen on other VoIP or video diallers and conferencing/UC tools.
But the other category that stands out is that of WebRTC-based CDNs (content delivery networks). I wrote about Yahoo's acquisition of PeerCDN in December, which provided an early heads-up about this model. It replaces part of the normal way websites and apps get content from servers owned by Akamai, Limelight etc (or a telco on-net CDN) with a peer-to-peer exchange of data directly between users.
Since then, a couple of things have happened. Firstly, two more WebRTC CDN players have emerged that I'm aware of - SwarmCDN and Viblast, as well as Peer5 and Streamroot, which I referenced in December. All are small companies, but, interestingly, already have a business model based on the amount of traffic diverted away from the other mainstream CDNs.
The other thing has been the much-ballyhooed deal between NetFlix and Comcast, which many people wrongly put down to non-neutral "sender pays" models or prioritisation, but which in fact nothing of the sort. It is a paid-peering deal that just clears a bottleneck between one of NetFlix's CDN providers, and Comcast's network, by means of NetFlix connecting directly at various IXP locations. (Sidenote: fantastic explanation here - ignore all the shrill-but-ignorant political commentary, as this is nothing to do with actual, all-important and valid Neutrality).
Potentially the WebRTC approach suggests that content delivery costs (to the provider/broadcaster) could be driven down substantially. And the peering issue hightens the rationale for looking into ways to save costs sooner, and in more disruptive/innovative fashion. Linked to this are reports that some CDN players - notably Google - are having to pay to install their servers in some telcos' networks.
I'm starting to tip towards the newer P2P-CDN approach as viable, initially at least for content forms that might be free/low-revenue bearing, rather than premium streaming. I'd expect that some broadcast organisations like the BBC will do their own research and maybe build in-house tools as well. And given its parentage, it certainly wouldn't surprise me if YouTube takes a good look as well, especially for its newer live-streaming and Hangouts-on-Air products. This domain also might be where to locate the worryingly-absent adult industry in WebRTC (worrying because normally it's at the front of the queue for cool new web technologies, yet bafflingly seems quite invisible in WebRTC thus far).
There's even a possibility that telcos/ISPs might benefit in some ways, from reduced load on their transit/peering, improved video performance experienced by customers, and maybe even hosting bits of WebRTC infrastructure like TURN servers on a localised basis. (China Mobile's take on the latter is here).
But the other side to all this is perhaps less-rosy. Like other, less-legitimate uses of P2P such as illegal file-sharing, this type of browser-CDN/app-CDN approach generates incremental upstream traffic. Data flows "up" from one user, "across" the network, and then "down" to the other user. Of course, it's also already been transmitted "down" to the first user to start all this off in the first place.
Generally, uplink capacity is much more constrained than downlink, especially on mobile networks. It also consumes lots of battery from mobile devices as sending is clearly more energy-intense than receiving. It also potentially increases costs to the end-user, assuming that the volumes are meaningful in the context of a data cap or quota. (And also assuming that the network actually measures upstream data transmission as well as downlink).
The question is what can/should/should not be done about this.
It's not obvious that policy management and in-network DPI can do much about browser/app-CDNs using WebRTC specifically. Apart from anything, it's encrypted - so unless telcos try to block all P2P WebRTC, it will be hard to discriminate CDN-type traffic from filesharing or screensharing or 100 other more "legitimate" things.The growing volume of enterprise WebRTC traffic, in advance of most consumer applications, suggests that such a blanket policy intervention would be badly-received and possibly illegal.
(Sidenote: one of the things that initiated the original Net Neutrality legislation in the US was when Comcast's blocking of BitTorrent accidentally also impacted IBM Lotus Notes data as well. Business-affecting "collateral damage" is
It is possible that networks might try to associate a WebRTC CDN datachannel session with a particular website being viewed by the users, or perhaps a JavaScript CDN library being downloaded to a given browser. But again, there may well be multiple use-cases, such as "co-browsing" of a given website, even including multimedia content.
There are also options for networks to try to charge differentially for upstream and downstream traffic, but that is likely to lead to huge user confusion and dissatisfaction as it will also impact photo uploads, sending emails etc.
Overall, at the moment I suspect that neither the policy vendors, nor the broadband operations folk at most operators, have identified WebRTC-CDN as a possible traffic type or significant disruptor. It will be interesting to see what happens if and when it explodes - which could well happen overnight, for example if a common website starts using it suddenly.
I also suspect that we will see WebRTC datachannel emerge for other unexpected P2P use-cases (eg distributed DropBox or similar - imagine being able to have encrypted online backups spread across your friends' PCs or phones). It also has the opportunity to play havoc with non-neutral broadband business models as people could take advantage of each others' data-plan policies, using another phone as a network proxy. Arbitrage city....
It would also not be surprising to me if we see Akamai, or other established CDNs, also looking into P2P approaches as a value-added service, or cost-mitigation approach for their customers. We could even see some of this working between network-resident web caches, rather than proprietary protocols. As a thought experiment, consider distributed SDN-based cacheing, with low-latency P2P datachannel connections, spread throughout a mobile network, and perhaps even co-located with base stations.
Overall, I continue to believe that the datachannel is ultimately going to be the most disruptive part of WebRTC, which might change the way networks and applications are built and operated. The original versions of P2P had a huge impact, but more mostly illicit. This time around, P2P is going to go mainstream and be legitimised, courtesy of WebRTC.
One takeout from this is that WebRTC datachannel p2P application developers should think about collecting performance statistics from Day 1. This will allow any subsequent attempts to throttle, deliberately degrade or limit connections to be more easily-spotted at a later date.
*NEW* March 2014 Disruptive Analysis WebRTC Report & Forecast Update DETAILS HERE
WebRTC is neither just about voice/video calls, nor just about browsers.
I've dealt with non-browser WebRTC several times before, and I'm drilling into it further for the current update to my research report (due for imminent publication) so I'm not focusing on that here. *NEW* March 2014 Disruptive Analysis WebRTC Report & Forecast Update DETAILS HERE
Instead, I've been thinking closely about some of the datachannel use-cases I've been seeing. Probably the most-common is file/screen-sharing, typically alongside various types of conferencing functionality. While there's a few interesting sub-categorisations (co-browsing, shared whiteboards etc) most are fairly intuitive replications or extensions of tools seen on other VoIP or video diallers and conferencing/UC tools.
But the other category that stands out is that of WebRTC-based CDNs (content delivery networks). I wrote about Yahoo's acquisition of PeerCDN in December, which provided an early heads-up about this model. It replaces part of the normal way websites and apps get content from servers owned by Akamai, Limelight etc (or a telco on-net CDN) with a peer-to-peer exchange of data directly between users.
Since then, a couple of things have happened. Firstly, two more WebRTC CDN players have emerged that I'm aware of - SwarmCDN and Viblast, as well as Peer5 and Streamroot, which I referenced in December. All are small companies, but, interestingly, already have a business model based on the amount of traffic diverted away from the other mainstream CDNs.
The other thing has been the much-ballyhooed deal between NetFlix and Comcast, which many people wrongly put down to non-neutral "sender pays" models or prioritisation, but which in fact nothing of the sort. It is a paid-peering deal that just clears a bottleneck between one of NetFlix's CDN providers, and Comcast's network, by means of NetFlix connecting directly at various IXP locations. (Sidenote: fantastic explanation here - ignore all the shrill-but-ignorant political commentary, as this is nothing to do with actual, all-important and valid Neutrality).
Potentially the WebRTC approach suggests that content delivery costs (to the provider/broadcaster) could be driven down substantially. And the peering issue hightens the rationale for looking into ways to save costs sooner, and in more disruptive/innovative fashion. Linked to this are reports that some CDN players - notably Google - are having to pay to install their servers in some telcos' networks.
I'm starting to tip towards the newer P2P-CDN approach as viable, initially at least for content forms that might be free/low-revenue bearing, rather than premium streaming. I'd expect that some broadcast organisations like the BBC will do their own research and maybe build in-house tools as well. And given its parentage, it certainly wouldn't surprise me if YouTube takes a good look as well, especially for its newer live-streaming and Hangouts-on-Air products. This domain also might be where to locate the worryingly-absent adult industry in WebRTC (worrying because normally it's at the front of the queue for cool new web technologies, yet bafflingly seems quite invisible in WebRTC thus far).
There's even a possibility that telcos/ISPs might benefit in some ways, from reduced load on their transit/peering, improved video performance experienced by customers, and maybe even hosting bits of WebRTC infrastructure like TURN servers on a localised basis. (China Mobile's take on the latter is here).
But the other side to all this is perhaps less-rosy. Like other, less-legitimate uses of P2P such as illegal file-sharing, this type of browser-CDN/app-CDN approach generates incremental upstream traffic. Data flows "up" from one user, "across" the network, and then "down" to the other user. Of course, it's also already been transmitted "down" to the first user to start all this off in the first place.
Generally, uplink capacity is much more constrained than downlink, especially on mobile networks. It also consumes lots of battery from mobile devices as sending is clearly more energy-intense than receiving. It also potentially increases costs to the end-user, assuming that the volumes are meaningful in the context of a data cap or quota. (And also assuming that the network actually measures upstream data transmission as well as downlink).
The question is what can/should/should not be done about this.
It's not obvious that policy management and in-network DPI can do much about browser/app-CDNs using WebRTC specifically. Apart from anything, it's encrypted - so unless telcos try to block all P2P WebRTC, it will be hard to discriminate CDN-type traffic from filesharing or screensharing or 100 other more "legitimate" things.The growing volume of enterprise WebRTC traffic, in advance of most consumer applications, suggests that such a blanket policy intervention would be badly-received and possibly illegal.
(Sidenote: one of the things that initiated the original Net Neutrality legislation in the US was when Comcast's blocking of BitTorrent accidentally also impacted IBM Lotus Notes data as well. Business-affecting "collateral damage" is
It is possible that networks might try to associate a WebRTC CDN datachannel session with a particular website being viewed by the users, or perhaps a JavaScript CDN library being downloaded to a given browser. But again, there may well be multiple use-cases, such as "co-browsing" of a given website, even including multimedia content.
There are also options for networks to try to charge differentially for upstream and downstream traffic, but that is likely to lead to huge user confusion and dissatisfaction as it will also impact photo uploads, sending emails etc.
Overall, at the moment I suspect that neither the policy vendors, nor the broadband operations folk at most operators, have identified WebRTC-CDN as a possible traffic type or significant disruptor. It will be interesting to see what happens if and when it explodes - which could well happen overnight, for example if a common website starts using it suddenly.
I also suspect that we will see WebRTC datachannel emerge for other unexpected P2P use-cases (eg distributed DropBox or similar - imagine being able to have encrypted online backups spread across your friends' PCs or phones). It also has the opportunity to play havoc with non-neutral broadband business models as people could take advantage of each others' data-plan policies, using another phone as a network proxy. Arbitrage city....
It would also not be surprising to me if we see Akamai, or other established CDNs, also looking into P2P approaches as a value-added service, or cost-mitigation approach for their customers. We could even see some of this working between network-resident web caches, rather than proprietary protocols. As a thought experiment, consider distributed SDN-based cacheing, with low-latency P2P datachannel connections, spread throughout a mobile network, and perhaps even co-located with base stations.
Overall, I continue to believe that the datachannel is ultimately going to be the most disruptive part of WebRTC, which might change the way networks and applications are built and operated. The original versions of P2P had a huge impact, but more mostly illicit. This time around, P2P is going to go mainstream and be legitimised, courtesy of WebRTC.
One takeout from this is that WebRTC datachannel p2P application developers should think about collecting performance statistics from Day 1. This will allow any subsequent attempts to throttle, deliberately degrade or limit connections to be more easily-spotted at a later date.
*NEW* March 2014 Disruptive Analysis WebRTC Report & Forecast Update DETAILS HERE
6 comments:
P2P CDNs are unlikely to disrupt anything. They offer very little of value on any of the main points a CDN is evaluated on: cost, control, latency, robustness or scalability. There may be some niche areas where they excel, but are very unlikely to replace or significantly eat into normal CDNs.
Walter - I think you'll need to be a bit more descriptive of your assertions.
Clearly on the cost side, a number of the proposed solutions *do* potentially offer an advantage. If a content provider can essentially have a proportion of its traffic self-provisioned by end-users rather than delivered by commercial CDN, that should cost less.
Latency will depend on the specific topology of the network. In some cases, Datachannel latency may be less than user-CDN node, once a connection is set up, maybe <100ms and maybe <10ms
I'm not suggesting it's a gamechanger from Day 1, but I think it maybe deserves a bit closer scrutiny than you suggest.
I'm particularly curious to know whether you have evaluated WebRTC-based P2P, or just much older client-based approaches?
Dean
> Clearly on the cost side, a number of the proposed solutions *do* potentially offer an
> advantage.
The much touted costs savings are more theoretical than anything else. The bottom line is this: any webRTC CDN will have to be backed by a conventional CDN if asset delivery is going to be guaranteed.
There is an implicit assumption that a webRTC CDN will be low cost. This is not a given, especially if the party offering webRTC CDN services also offers the required conventional CDN service. If the party offering webRTC CDN services does not offer conventional CDN services, the technical overhead of integrating webRTC delivery and normal CDN delivery falls to the CDN client. This is not free nor is it likelt to be low cost.
Due to the peer to peer nature of webRTC any cost savings are likely to come at a cost higher latency. This is fine for some applications, but does not make it suitable as a general purpose CDN replacement. I can see it as a "clientless" replacement for bittorrent for site specific popular large size content, but not for delivering normal HTML assets.
WebRTC clients are also *very* ephemeral. Unless the user is interacting with the webRTC app they have no incentive to stick around. This makes the swarm *very* volatile and up the required size for the swarm to be able to reliably be able to deliver any assets.
Cache control will also most likely be a hugh issue. Not only will peers be short lived, volatile, bandwidth limited and resource constrained, there are no guarantees that they will be well behaved. Any changes to the content to be cached will most likely result in having to write off the whole swarm that has the old content. Peers may not download the new content or even if they do it might take a long time before they do so. Corrupt or misbehaving peers may result in having to download the content twice, once from the swarm and once from the CDN to get a valid copy.
So, what do the costs savings look like?
Savings = TBs transferred over webRTC CDN * ( CDN rate - webRTC CDN)
First order observation: even if the webRTC CDN usage was free the savings are capped at the CDN rate times transfer volume. With TB costs measured in the pennies, the webRTC CDN would have to move petabytes per month to have any meaningful econonomic impact in a business setting.
TBs transferred over webRTC CDN = users of website * percentage of webRTC clients * average upstream bandwidth of users * probability of other users having requested asset in cache * average webRTC client lifespan * probability of transfer completing without errors
Second order observation: even in a perfect world, where all users have webRTC clients, all transfers complete without problems and all high traffic assets are cached, the TBs transferred are limited by the average upstream bandwidth of the users. Since almost all access networks in operation now are asymmetric, it follows that it is nearly impossible to offload more than average upstream traffic / average downsteam bandwidth of all CDN traffic.
Now since the world is far from perfect, the webRTC CDN offload percentage is bound to be fairly low due to the hard limits of penetration and network constraints.
Walter
> Latency will depend on the specific topology of the network.
Of course. So the question becomes, what is the probability that the webRTC swarm will be on-net when the user visits a random website?
> I'm not suggesting it's a gamechanger from Day 1, but I think it maybe deserves a bit
> closer scrutiny than you suggest.
Sure, I'll grant that I may end up being proved wrong, but I'm not holding my breath. Bandwidth prices are now so low that even bittorrent and other peer to peer traffic is migrating to various centralized streaming and tube sites, despite bittorrent traffic being "free".
> I'm particularly curious to know whether you have evaluated WebRTC-based P2P, or just
> much older client-based approaches?
I'm more versed in older P2P technologies, but have checked out the webRTC offering, but have never run webRTC in a production environment. That being said, I have yet to see anything based on webRTC that would warrant me to even do a large scale lab test.
Walter
Walter - thanks for the comments. Most insightful.
I suspect that like many areas of technology evolution, this will fall into the heading of "disruption from adjacency", with early use-cases being niches, or completely new.
One thing to note is that WebRTC's innards can be wrapped up and . We inserted directly into apps, as well as browsers. We will also likely see it crop up directly embedded into some OS's (Firefox OS first, but maybe Android too) which could be a game-changer.
Add proximity networking too - Google's Chromecast already uses some aspects of WebRTC to shove content from laptop browser to TV dongle.
I have a sneaking suspicion this may develop faster than many anticipate - but I'm not a CDN expert so could be wrong.
This is an insightful article and also a fascinating discussion with strong arguments for both perspectives. It will be interesting to see how this evolves.
Dean - can you complete the missing text from the side-note please. It is truncated.
Post a Comment