
Peer-To-peer Architecture Could Save Streaming Video - ericaeb
http://www.webrtcworld.com/topics/webrtc-world/articles/394474-peer-to-peer-architecture-could-save-streaming-video.htm
======
jasode
>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.

~~~
Rodi
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
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 experience, intolerant of any interrupt or
quality drop.

~~~
Rodi
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.

~~~
JoeAltmaier
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.

------
dexen
A whole article on p2p video streaming, and yet Popcorn Time [1] is curiously
absent. The flagship program that proves p2p movie watching is feasible, even
comfortable, when delivered through BitTorrent doesn't get a mention. In a way
the program already saved streaming video already.

We can only speculate whether the omission is conscious attempt at avoiding
linking to risque programs, or does that indicate the article is copy-pasted
press release of content providers.

[1]
[https://en.wikipedia.org/wiki/Popcorn_Time](https://en.wikipedia.org/wiki/Popcorn_Time)
; [https://popcorntime.io/](https://popcorntime.io/) seems to be the leading
fork.

~~~
Rodi
The main difference with the solution the article describes and Popcorn time
is that the former can be used by the online broadcaster for their own videos
and integrates seamlessly in their webpage, whereas for Popcorn time you need
to install the soft, and can only download torrents.

------
KaiserPro
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 partition, and also make sure that NAT doesn't get
in the way. Also you'll need to block mobile phones as well.

the best part is, you'll be forced to use HVEC as the usable upload is around
2 megabits. That means a stream encoded at 750k (to allow uploading to two
other users) or half that if you want 4 other peers.

So no, P2P is not the answer. Iterate again.

~~~
Rodi
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/Opera browser :
[http://demo.streamroot.io](http://demo.streamroot.io)

~~~
KaiserPro
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)

------
jacquesm
We had peer to peer streaming 18 years ago. It does not scale for larger
audiences, so if it stays on the 'skype' level then it will do fine, otherwise
you're going to need some kind of redistribution network to handle the fan-
out.

If you're willing to tolerate lag and decreasing fidelity you can also use
peer-to-peer relaying but this only works for a very limited number of hops.

~~~
latch
I'm also skeptical. Off the top of my head, if I had to make this work, I
might try two things:

1 - While streaming normally from the CDN, also preload segments from peers.
Complexity and client-bloat aside, you don't lose much trying (assuming the
client has the bandwidth)

2 - Peering with folk that appear to be close. I feel that doing it by network
address or ip->geo lookup might work well.

~~~
Rodi
Hey, founder of the p2p service described in the article here
(www.streamroot.io)

This is exactly what we are doing :) We have have a hybrid p2p model that
fetches video segments from others peers as long as it can, and switches back
to CDN on urgency cases. And our tracker uses geoIp data, ISP and some network
topology elements to connect the best candidates together

------
diydsp
Note that this article claiming online video streaming needs to be saved is on
a WebRTC marketing site "Powered by Technology Marketing Corp" advocating a
competing technology.

I don't think online video streaming needs to be saved.

> There’s a clear event horizon where delivery overhead outstrips even CDN
> capacity.

If it's so clear, please enlighten me: All I see is network architecture
making ever bolder jumps to increase capacity... Look at Amazon's multiple
locations, look at _fiber-to-the-home_ , look at the server farms around the
country. Look at the bold instantiation of cell towers becoming ever-denser.

I think if the public demands 150 million individual 10Mbps streams, it will
be built.

Not that WebRTC isn't cool for what it is, but a soccer game isn't a volcano
(10 people punting a ball/data around like WebRTC isn't the same as a massive
one-way structure of energy/data like a Volcano).

------
dracolytch
So... I'm conflicted about this. Sure, on one hand peer-to-peer streaming
could solve some of the problems she's talking about, so long as there's a
large enough audience for each video. Services like Steam have used P2P very
effectively. At times it can break down to a very frustrating level quickly,
so you'll still want CDNs around to act as seeds. It also doesn't work for
live broadcasts which is becoming more common with the likes of Twitch. Also,
the current technologies being discussed (marketed?) would require a plugin to
work. I don't think this will fly until a browser-native solution is
engineered.

~~~
higherpurpose
> so long as there's a large enough audience for each video

Completely a non-issue. The providers would "seed" all the videos from their
own servers, too, so when there aren't enough peers seeding it, the bulk of
the streaming would be offered by the provider.

Using the Pareto principle, something like 80 percent of the videos would be
"long-tail" with few to no seeds (other than from the provider), but only use
20 percent of the video traffic (so the provider's burden is greatly reduced
anyway). The other 20 percent videos would represent 80 percent of the
traffic, and those are the videos that would be helped most by P2P streaming.

------
natar
I'm not sure if that's going to work when more and more people are using
mobile internet. Sure, we can all hope for real mobile flatrates but p2p
videodistribution will add more traffic the networks … wait, no it wouldn't,
would it?

------
williamcotton
WebTorrent is a streaming torrent client for node.js and the browser.

[https://github.com/feross/webtorrent](https://github.com/feross/webtorrent)

It can stream video torrents into a <video> tag (webm (vp8, vp9) or mp4
(h.264))

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

~~~
sylvinus
A smaller Akamai bill?

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

------
est
P2p video streaming has been used in China for over a decade now. from
earliest synacast to Flash p2p

