Ask HN: Why don't streaming services make use of P2P?
Wouldn't this drastically reduce their bandwidth costs? I would imagine the majority of people streaming HD/4K Netflix don't have bandwidth caps to worry about, so it wouldn't be very noticeable to the end user and be largely beneficial to the streaming service. Why isn't this more common?
8 comments
P2P is for decentralization. Why would a centralized entity want to implement a decentralized service when they can create a centralized version of that same service faster, easier, and cheaper?
P2P is _hard_ with a capital H.
P2P is _hard_ with a capital H.
Why hard?
On server maintain list of ips. Serve ip to the client-peer. If the connection gets spotty replace it or use direct connection to your server. All State exists on your server. Caching may be an anti-pattern depending.
What's so hard?
On server maintain list of ips. Serve ip to the client-peer. If the connection gets spotty replace it or use direct connection to your server. All State exists on your server. Caching may be an anti-pattern depending.
What's so hard?
Netflix has considered it in the past, so there must be some kind of catch. If it's a technical reason, I'd guess at poor ISP performance when it comes to a large routing table with many small transfers from many IPs.
In contrast, Netflix currently puts caches on location at ISPs, creating a fast CDN and allowing the ISP to do quality of service filtering on Netflix data (probably to make it faster than other p2p data?).
In contrast, Netflix currently puts caches on location at ISPs, creating a fast CDN and allowing the ISP to do quality of service filtering on Netflix data (probably to make it faster than other p2p data?).
Spotify used P2P when it first launched, and I think it worked well. The move to phones as a primary playback device probably made it less feasible.
Joost used to do this; I think they dropped it because the cost of maintaining the P2P code was more than the cost of bandwidth.
It's simply not as efficient as you might first think, which is unfortunate, but just a nature of how networks are designed.
I'll take a typical UK broadband network as an example, as it's what I'm most familiar with, however the same is true for many networks around the world just different technologies.
A broadband (ADSL/VDSL/Cable) service creates a tunnel (PPP) from the router at your house or office back to a single gateway (BNG/BRAS/LNS) within the ISP's core network, any traffic to or from your router to the outside world will pass via this tunnel to your ISP. The ISP's backhaul network between your house and the core network is just dealing with the routing of these virtual tunnels, and not really paying attention to the traffic which they encapsulate. (For simplicity I'm ignoring QoS)
This means even if your communicating between your house and your neighbour via something such as P2P, FTP, HTTP etc. The traffic is always first tunnelled back to an ISP Exchange / Data Centre before it then routes towards its destination. If you were to draw the logical traffic flows out, that Gateway is always a pinch point regardless of the protocol used within the tunnel.
This is where caching services really come into their own (e.g. https://openconnect.netflix.com/en/ or https://peering.google.com/#/options/google-global-cache) - Typically content providers will offer up caching hardware to the ISP at zero cost, subject to some basic requirements been met. Really these are just servers with a large amount of storage space and high throughput network interfaces, which hold a copy of the most popular content for that provider.
The key to the success of Caching servers is the ISP can place these wherever they like, and therefore control the traffic within their core network – As an ISP your likely to put these literally a matter of meters away from your gateway (BNG/BRAS/LNS) nodes, however it really could go anywhere in their network.
Something else I’ve seen Netflix talk about publicly is the quantity of content they hold, and actually the quantity of the same content which people wouldn’t usually expect – For example a single 60min TV episode they might have hundreds of copies of on their servers and these cache servers, as there are so many device types in the market and so many bitrates that it’s not feasible to transcode these in real time based on user demand, instead it makes more sense to transcode the episode to 300 different files once, copy the resulting files to their cache layer and then serve the best one for the user.
So now if you switch back to P2P there’s a few problems which are a lot more apparent…
The bandwidth in P2P must first leave one subscriber to reach the data centre via the ISP backhaul network, at which point it loops back to the viewing subscriber, again via the ISP backhaul network – So you have “2n” the backhaul usage for P2P content vs Cache served content.
Users are unlikely to have the right transcoded version of content to hand for the person trying to view the content, in which case you would fall back to a hosted copy of the content anyway.
The reliability, latency and available bandwidth of someone’s home broadband line is always going to be poorer than that of a Cache server directly plugged into the ISP network.
Many users probably don’t want to have their upstream bandwidth used for this, or equally don’t want their GB of local storage to be consumed for content providers trying to save some money on content delivery.
I'll take a typical UK broadband network as an example, as it's what I'm most familiar with, however the same is true for many networks around the world just different technologies.
A broadband (ADSL/VDSL/Cable) service creates a tunnel (PPP) from the router at your house or office back to a single gateway (BNG/BRAS/LNS) within the ISP's core network, any traffic to or from your router to the outside world will pass via this tunnel to your ISP. The ISP's backhaul network between your house and the core network is just dealing with the routing of these virtual tunnels, and not really paying attention to the traffic which they encapsulate. (For simplicity I'm ignoring QoS)
This means even if your communicating between your house and your neighbour via something such as P2P, FTP, HTTP etc. The traffic is always first tunnelled back to an ISP Exchange / Data Centre before it then routes towards its destination. If you were to draw the logical traffic flows out, that Gateway is always a pinch point regardless of the protocol used within the tunnel.
This is where caching services really come into their own (e.g. https://openconnect.netflix.com/en/ or https://peering.google.com/#/options/google-global-cache) - Typically content providers will offer up caching hardware to the ISP at zero cost, subject to some basic requirements been met. Really these are just servers with a large amount of storage space and high throughput network interfaces, which hold a copy of the most popular content for that provider.
The key to the success of Caching servers is the ISP can place these wherever they like, and therefore control the traffic within their core network – As an ISP your likely to put these literally a matter of meters away from your gateway (BNG/BRAS/LNS) nodes, however it really could go anywhere in their network.
Something else I’ve seen Netflix talk about publicly is the quantity of content they hold, and actually the quantity of the same content which people wouldn’t usually expect – For example a single 60min TV episode they might have hundreds of copies of on their servers and these cache servers, as there are so many device types in the market and so many bitrates that it’s not feasible to transcode these in real time based on user demand, instead it makes more sense to transcode the episode to 300 different files once, copy the resulting files to their cache layer and then serve the best one for the user.
So now if you switch back to P2P there’s a few problems which are a lot more apparent…
The bandwidth in P2P must first leave one subscriber to reach the data centre via the ISP backhaul network, at which point it loops back to the viewing subscriber, again via the ISP backhaul network – So you have “2n” the backhaul usage for P2P content vs Cache served content.
Users are unlikely to have the right transcoded version of content to hand for the person trying to view the content, in which case you would fall back to a hosted copy of the content anyway.
The reliability, latency and available bandwidth of someone’s home broadband line is always going to be poorer than that of a Cache server directly plugged into the ISP network.
Many users probably don’t want to have their upstream bandwidth used for this, or equally don’t want their GB of local storage to be consumed for content providers trying to save some money on content delivery.