Peer-To-peer Architecture Could Save Streaming Video • Hacker News Board

Re: Peer-To-peer Architecture Could Save Streaming Video

#31

Post by JoeAltmaier » Thu, Feb 12, 2015, 4:14 PM UTC

Rodi wrote: post #27

JoeAltmaier wrote: post #23

Earlier quoted context omitted.

We do p2p communications. A big issue is network interruption. Somebody walks around with a laptop or mobile device, roams, link broken and a gap in your experience as it scrambles to reroute. Or somebody else in the house starts to use the network, and your negotiated link drops available bandwidth/congests. If its free or just for fun, then yes you can go this route. But people paying for an experience are, in our…

Networks interruptions happen a lot, this is why our system is hybrid: if you didn't have time to get the segment from the peer-to-peer, you dynamically switch back to the CDN to get the missing parts of your video segments, so in practice the quality can't be worse than what you have with the CDN only.

I have to wonder at the claim of no added latency then? By the time the peer fails, and the CDN is queried and responds, the replay stream would have passed the point where it needed that frame. Unless the reassembly/replay engine is running substantially behind realtime.

Re: Peer-To-peer Architecture Could Save Streaming Video

#32

Post by KaiserPro » Thu, Feb 12, 2015, 5:00 PM UTC

sylvinus wrote: post #18

KaiserPro wrote: post #15

Sorry, but no. For a p2p system to work you need to have a nearest neighbour finder(please wait 5 minutes whilst we probe your network) you then need to have a realtime "rationilser" that will go through and re-route the live stream according to how many peers in one segment are connected to another. Then, you need a number of backup peers for when your current master peer disappears. Then you have to deal with parti…

Did you read the article? Your points are irrelevant because it's not 100% P2P, they say they reach ~58% of P2P use, while the rest comes from regular CDNs.

yes, I read the article, I also note that they were using a 1 meg stream.

They didn't describe the jitter, dropout rate, cache misses and eventual fall back. For example was that 58% peak? was that 58% attempted p2p use? what was the threshold? did the users notice?

what happens when peers go away? does that mean that create burst loads on the cache master?

What is the success rate when they stream 4meg, 8meg? or a bitrate that changes significantly? for example going from a semi static image to fast moving sports (think transition from commentator studio to live action) Having dealt with these types of systems in the bad old days (think 2007-9) I can tell you that they suck hard.

All that engineering work required to patch over a under resourced and terribly unreliable transport, when many a pre-built system with SLAs already exists

Re: Peer-To-peer Architecture Could Save Streaming Video

#33

Post by justincormack » Thu, Feb 12, 2015, 5:06 PM UTC

joncrocks wrote: post #12

jasode wrote: post #6

>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…

In terms of live events this was meant to be solved by multicasting. http://en.wikipedia.org/wiki/IP_multicast or 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…

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.

Re: Peer-To-peer Architecture Could Save Streaming Video

#34

Post by KaiserPro » Thu, Feb 12, 2015, 5:06 PM UTC

Rodi wrote: post #28

KaiserPro wrote: post #15

Sorry, but no. For a p2p system to work you need to have a nearest neighbour finder(please wait 5 minutes whilst we probe your network) you then need to have a realtime "rationilser" that will go through and re-route the live stream according to how many peers in one segment are connected to another. Then, you need a number of backup peers for when your current master peer disappears. Then you have to deal with parti…

Hey, what you describe what clearly the case with old peer-to-peer systems, but things changed a lot. With webRTC and ICE/STUN, the p2p connection takes less than 5s on average and goes through NATs in 95% of the cases. As for the bandwidht issues, it is not a problem as the solution is hybrid and doen't need every peer to be a full seeder. If you don't beleive me you can always try by yourself, with a Chrome/Firefox…

one connection takes 5s, but using a stun server means you don't understand peer locality. This means you as the service owner has to map the network to find correct peer placement.

How do you asses the bandwidth available now, and in the future? is the bandwidth between two peers inside and ISP greater than two peers from different ISPs. How do you manage peer re-routing when one disappears. What happens if more than one peer disappears?

webrtc is designed for 1 to 1 mapping, and not 1 to many paid for content delivery. Sure you can do it, but your users arn't going to be happy you chose to engineer your way out of a bad idea. (You don't want buffering during an expensive movie/tv/sports game)

Re: Peer-To-peer Architecture Could Save Streaming Video

#35

Post by justincormack » Thu, Feb 12, 2015, 5:08 PM UTC

sylvinus wrote: post #19

tootie wrote: post #14

I don't understand the benefit of P2P when CDNs like Akamai are already distributing load across their massive network of servers.

A smaller Akamai bill?

Will I see the cost saving of handing over my bandwidth?

Re: Peer-To-peer Architecture Could Save Streaming Video

#36

Post by KaiserPro » Thu, Feb 12, 2015, 5:09 PM UTC

alecco wrote: post #22

KaiserPro wrote: post #15

Sorry, but no. For a p2p system to work you need to have a nearest neighbour finder(please wait 5 minutes whilst we probe your network) you then need to have a realtime "rationilser" that will go through and re-route the live stream according to how many peers in one segment are connected to another. Then, you need a number of backup peers for when your current master peer disappears. Then you have to deal with parti…

That can be cached if there's only one system. And BitTorrent DHT takes about 30s to start finding peers. That's a very old type of DHT, a new protocol could prioritize finding closer neighbors.

but that takes time, which means depleting cache. As most domestic connections are limited by upload, its not like you can get that cache back.

Especially if you are at the edge of the the p2p chain. Your cache might be dependent on three other people refreshing their cache first.

Re: Peer-To-peer Architecture Could Save Streaming Video

#37

Post by victor_s » Mon, Feb 16, 2015, 4:08 PM UTC

Rodi wrote: post #21

jasode wrote: post #6

>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…

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,…

Hi, my company operates in the same area (viblast.com)

I would like to add on Rodi's answers above:

- Yes, for mobile (data-plan based) connections P2P puts a heavy load, but WiFi-connected smartphones/tablets are not a problem to serve.

- Latency is not the issue being discussed here (from the Twitter example above), even Twitch latency is no less than 12 seconds: http://www.reddit.com/r/Twitch/comments/2j8b4c/has_the_strea... It seems that you are talking about asynchronous viewing, and that is something that can be made to work better so viewers at least watch with the same delay.

- The real value of P2P streaming is mostly seen by Broadcasters who wish to send their online linear signals at high and uninterrupted quality, but low cost as their traditional model.