5 ms·

>Instead of one endpoint pulling down a single unique stream, the P2P approach allows simultaneous users to exchange video segments among themselves rather than

by jasode 12y ago

>Instead of one endpoint pulling down a single unique stream, the P2P approach allows simultaneous users to exchange video segments among themselves rather than each connecting to a server to do so. Issues: -- residential/mobile internet service has asymmetric upload/download speeds. -- ISPs are suspicious of heavy uploads originating from residential homes and could be flagged as "servers" in violation of ISP's TOS or reclassified as "business tier pricing" thereby increasing the billing amount. -- too much latency for live mega events (World Cup, etc) because of asymmetry mentioned above. (Your neighbor tweets that Spain scored the winning goal before your P2P stream received the last packets showing that it happened.) Latency for bittorrent is ok, but for live megaevents, no. I don't think P2P down to residential is realistic. However, P2P between commercial entities looks more workable. If Akamai projects that their CDNs can't handle the next mega event, they contract with Amazon AWS CDNs to handle some of the spillover bandwidth. And/or work with ISPs (Comcast, FiOS edge servers) to act as CDNs. Yes, it involves competitors partnering with each other but this looks more feasible than coordinating residential internet service to deliver the extra bandwidth. As an analogy, residential neighbors don't transfer supplemental electricity to each other but power stations in Canada might supply extra peak electricity to power stations in New York.

rakoo 12y ago
> I don't think P2P down to residential is realistic. However, P2P between commercial entities looks more workable. The nice thing with P2P is that both model are not mutually exclusive. You can have a single peer that is effectively served by Akamai's CDN, and you can have another single peer that is served by you behind your poor ISP line; the protocol will work the same and automatically select the one that offers the better bandwith -- so people will in practice fetch from Akamai's CDN when it has capacity, and automatically switch to anybody else when Akamai alone isn't enough. You don't even need any logic, it will be handled automatically.
higherpurpose 12y ago
You're thinking backwards of the problem. The ISPs don't offer high upload speeds because there's no demand for it. If there was, they would be forced to raise those speeds (in a competitive market, at least). Google Fiber offers symmetrical 1Gbps for download and upload speeds.
basiliothecat 12y ago
The presence of those consumer/server distinction in ISP's TOS should get waded out at some point. And distributed content is much move viable solution than a centralized ones - probably a troublesome one regarding streaming live data, but one which is potent to utilize network for the task at hand more harmoincally. And at the same time it'll bring all the benefits of distributed systems (as well as downsides) - e.g. you could stream a video of yours on your own website and not rely on likes of youtube.
joncrocks 12y ago
In terms of live events this was meant to be solved by multicasting. http://en.wikipedia.org/wiki/IP_multicast http://en.wikipedia.org/wiki/IP_multicast or http://en.wikipedia.org/wiki/Broadcast_address http://en.wikipedia.org/wiki/Broadcast_address The point being that if you have a stream of data that is the same for a large number of recipients, you can send the data down the tubes once, and it's then shared by recipients. Although doesn't solve the general case (people wanting to watch the same thing, but out of order).
- justincormack 12y ago
  In ISP caches more or less solve that problem, as Netflix and others use, while allowing some out of sync views. At this point multicast just isnt going to make it.
avn2109 12y ago
Doesn't Spotify do p2p for fairly-high-resolution audio already?
- vlan0 12y ago
  As of this time last year, they were slowly migrating from a P2P platform, to only using centralized servers. However, I do not see much information on this topic other than what was posted nearly a year ago.
Rodi 12y ago
Hey, I am the founder of the company providing the pluginless peer-to-peer video streaming service the article is talking about (www.streamroot.io). >-- residential/mobile internet service has asymmetric upload/download speeds. Indeed, but it is not so much of an issue: 1. the average video stream bitrate today is 1.5 Mbps, which is closer to the upstream limits than the downstream limits. 2. Our solution is hybrid, so if you can't get all the data from other peers, you just get the rest from the CDN, so even if someone has a 100 kbps uplink, he still contributes to the swarm. 3. With fiber there are more and more people having 100+ Mbps uplink, and these people can serve dozens of others peers, and this balances the asymmetry partially. >-- ISPs are suspicious of heavy uploads originating from residential homes and could be flagged as "servers" in violation of ISP's TOS or reclassified as "business" thereby increasing the billing amount. This must be different depending your country and ISP, but the upside comparing to some full P2P service like Bittorent is that you share video segments only while you are on the streamer webpage (as soon as you close your tab the p2p stops), and also all the communications are encrypted with DTLS provided by WebRTC, so it is not so easy for ISPs to figure out what is exchanged. And finally, we actually help the ISPs by connecting the peers that use the same ISPs, and are on the same sub-networks first, so they have less peering issues. >-- too much latency for live mega events (World Cup, etc) because of asymmetry mentioned above. (Your neighbor tweets that Spain scored the winning goal before your P2P stream received the last packets showing that it happened.) Latency for bittorrent is ok, but for live megaevents, no. I think that this where our technology really differentiates with the old peer-to-peer systems : we don't add any additional latency to the stream, but just use the latency already generated by HTTP streaming protocols like HLS or MPEG-DASH. So with or without our system, you will still have a 20-30 seconds latency with the encoder, as it is already the case with all the professional live streams like the ones used during Superbowl or the World Cup. As for CDNs cooperating to broadcast a live stream, it is not really the spirit of the CDN market right now, instead what happens is that the Broadcaster can contract one or several backup CDNs for their biggest events, and use them in case the primary CDNs breaks down. This is what happened for the Superbowl stream : NBC had Akamai as their primary CDN, and Level3 as a backup. In the end they didn't have to use the backup, but still paid both CDNs for the event !
- JoeAltmaier 12y ago
alecco 12y ago
> -- residential/mobile internet service has asymmetric upload/download speeds. > -- ISPs are suspicious of heavy uploads originating from residential homes and could be flagged as "servers" in violation of ISP's TOS or reclassified as "business tier pricing" thereby increasing the billing amount. Yes, but ISPs would love to join with p2p to reduce their upstream bills. There are 2 problems currently. First, there is no single protocol or system so maintaining one cache box for each system is crazy (YouTube/Google, Netflix, HBO, Amazon, Hulu... all proprietary). Second, even though there could be a payoff in the long run with savings, there's no immediate payoff for setup. This could all be solved with a standardized protocol and system. But sadly the big bodies, in particular IEEE, are a bureaucratic mess and filled with industry sponsored members. Internet is going backwards. Something's gotta give.

by jasode 12y ago

rakoo 12y ago

> I don't think P2P down to residential is realistic. However, P2P between commercial entities looks more workable. The nice thing with P2P is that both model are not mutually exclusive. You can have a single peer that is effectively served by Akamai's CDN, and you can have another single peer that is served by you behind your poor ISP line; the protocol will work the same and automatically select the one that offers the better bandwith -- so people will in practice fetch from Akamai's CDN when it has capacity, and automatically switch to anybody else when Akamai alone isn't enough. You don't even need any logic, it will be handled automatically.

higherpurpose 12y ago

You're thinking backwards of the problem. The ISPs don't offer high upload speeds because there's no demand for it. If there was, they would be forced to raise those speeds (in a competitive market, at least). Google Fiber offers symmetrical 1Gbps for download and upload speeds.

basiliothecat 12y ago

The presence of those consumer/server distinction in ISP's TOS should get waded out at some point. And distributed content is much move viable solution than a centralized ones - probably a troublesome one regarding streaming live data, but one which is potent to utilize network for the task at hand more harmoincally. And at the same time it'll bring all the benefits of distributed systems (as well as downsides) - e.g. you could stream a video of yours on your own website and not rely on likes of youtube.

joncrocks 12y ago

In terms of live events this was meant to be solved by multicasting. http://en.wikipedia.org/wiki/IP_multicast http://en.wikipedia.org/wiki/IP_multicast or http://en.wikipedia.org/wiki/Broadcast_address http://en.wikipedia.org/wiki/Broadcast_address The point being that if you have a stream of data that is the same for a large number of recipients, you can send the data down the tubes once, and it's then shared by recipients. Although doesn't solve the general case (people wanting to watch the same thing, but out of order).

justincormack 12y ago
In ISP caches more or less solve that problem, as Netflix and others use, while allowing some out of sync views. At this point multicast just isnt going to make it.

avn2109 12y ago

Doesn't Spotify do p2p for fairly-high-resolution audio already?

vlan0 12y ago
As of this time last year, they were slowly migrating from a P2P platform, to only using centralized servers. However, I do not see much information on this topic other than what was posted nearly a year ago.

Rodi 12y ago

Hey, I am the founder of the company providing the pluginless peer-to-peer video streaming service the article is talking about (www.streamroot.io). >-- residential/mobile internet service has asymmetric upload/download speeds. Indeed, but it is not so much of an issue: 1. the average video stream bitrate today is 1.5 Mbps, which is closer to the upstream limits than the downstream limits. 2. Our solution is hybrid, so if you can't get all the data from other peers, you just get the rest from the CDN, so even if someone has a 100 kbps uplink, he still contributes to the swarm. 3. With fiber there are more and more people having 100+ Mbps uplink, and these people can serve dozens of others peers, and this balances the asymmetry partially. >-- ISPs are suspicious of heavy uploads originating from residential homes and could be flagged as "servers" in violation of ISP's TOS or reclassified as "business" thereby increasing the billing amount. This must be different depending your country and ISP, but the upside comparing to some full P2P service like Bittorent is that you share video segments only while you are on the streamer webpage (as soon as you close your tab the p2p stops), and also all the communications are encrypted with DTLS provided by WebRTC, so it is not so easy for ISPs to figure out what is exchanged. And finally, we actually help the ISPs by connecting the peers that use the same ISPs, and are on the same sub-networks first, so they have less peering issues. >-- too much latency for live mega events (World Cup, etc) because of asymmetry mentioned above. (Your neighbor tweets that Spain scored the winning goal before your P2P stream received the last packets showing that it happened.) Latency for bittorrent is ok, but for live megaevents, no. I think that this where our technology really differentiates with the old peer-to-peer systems : we don't add any additional latency to the stream, but just use the latency already generated by HTTP streaming protocols like HLS or MPEG-DASH. So with or without our system, you will still have a 20-30 seconds latency with the encoder, as it is already the case with all the professional live streams like the ones used during Superbowl or the World Cup. As for CDNs cooperating to broadcast a live stream, it is not really the spirit of the CDN market right now, instead what happens is that the Broadcaster can contract one or several backup CDNs for their biggest events, and use them in case the primary CDNs breaks down. This is what happened for the Superbowl stream : NBC had Akamai as their primary CDN, and Level3 as a backup. In the end they didn't have to use the backup, but still paid both CDNs for the event !

JoeAltmaier 12y ago

alecco 12y ago

> -- residential/mobile internet service has asymmetric upload/download speeds. > -- ISPs are suspicious of heavy uploads originating from residential homes and could be flagged as "servers" in violation of ISP's TOS or reclassified as "business tier pricing" thereby increasing the billing amount. Yes, but ISPs would love to join with p2p to reduce their upstream bills. There are 2 problems currently. First, there is no single protocol or system so maintaining one cache box for each system is crazy (YouTube/Google, Netflix, HBO, Amazon, Hulu... all proprietary). Second, even though there could be a payoff in the long run with savings, there's no immediate payoff for setup. This could all be solved with a standardized protocol and system. But sadly the big bodies, in particular IEEE, are a bureaucratic mess and filled with industry sponsored members. Internet is going backwards. Something's gotta give.