4 ms·

> Doesn't really matter, it is fast enough. If it isn't you back it up from a datacenter. Sorry but no it really isn't. You'd have to rely so much in your own

> Doesn't really matter, it is fast enough. If it isn't you back it up from a datacenter. Sorry but no it really isn't. You'd have to rely so much in your own data centre that you'd loose the benefit of bittorrent. Plus many services will use a commercial CDN, none of which current support bittorrent. So you'd end up having to build your own infrastructure there, which would be a great deal more expensive. > Shouldn't be any real difference in reliability. Home connections might drop off due to power cuts, router failure or any of the other numerous conditions that datacenters battle against. Home connections might get throttled by ISPs. Where I work we offer 5 "9s" of reliability on some services, good luck asking consumer broadband to offer the same ;) > The client can decide this. There are torrent clients that do this already. Buffer 2 minutes, if some chunk is missing when 20 seconds remains pull it from a datacenter instead. 2 minutes is an excessively long buffer compared to.how long most RMTP segments are (often 15 seconds or below). > No, you start streaming from the datacenter. So then why bother with bittorrent at all? > Not sure, but if a minute is acceptable delay (depends on what is being broadcasted) it should be feasible. A live webcam for a tourist resort should be fine, a sports event, maybe not. A minute isn't even close to acceptable delay. Imagine if you're watching a sports match and Twitter is ahead of your video fees, you wouldn't be grateful for the spoilers. This is a real world problem with video streaming and why they talk about getting the latency down to 5 seconds or less. > Spotify even used to work this way. When a user clicked play (or seeked to a different part of the song) the first (if I remember correctly) 15 seconds was fetched from their CDN. After that it used its own torrent-like system to continue and pre-fetch the next song. Spotify is audio only. People love to compare video streaming to audio streaming but they don't realise that HD video is an order of magnitude more complex to stream - in terms of bandwidth, syncing, dropped frames, etc. It's one of those problems that seems easy to solve from a superficial level but when you start getting to the broadcaster level it's actually a great deal more complex than even Plex and other self-hosted streaming services would lead you to believe. (Disclaimer, I've worked at the broadcaster level)

tjoff 8y ago
I just can't address this further. I'm not convinced you have the slightest clue what bittorrent is (how on earth does not having 5 9s matter for a consumer connection? If a node drops noone will notice). I'm not saying there won't be problems. A major problem is the asymmetric nature of many consumer connections. Not only is the upload often a fraction of the download (that is the easy part), but the download speed can be greatly sacrificed if upload is utilized. Add to that issues that home users might want to use the connection for other stuff. The nightmare and confusion surrounding "I can't game because someone is watching torrent-tube" will be real and add to that issues with ISPs that have a fixed quota or people on mobile (or tethering a mobile connection to laptop). Netflix et al would not like to deal with that kind of FUD spreading around. And all this is before considering local ISP bottlenecks as it isn't what the network was designed for. A vastly superior option is to put a proxy on the ISP network itself (but yes, hard to do for small players). Those alone are probably a magnitude worse than the technical issues you speak of. Even spotify got much flak for it, and no, I don't think anyone on earth think the bandwidth requirements of audio and HD video are similar.
- laumars 8y ago
  I actually did cover that point (albeit at a much higher level) and of course I know what bittorrent is. Just because I don't agree with you it doesn't mean I don't understand the problems. Quite the opposite, I happen to work in the video delivery industry so it's my job to understand these problems. Like I said, it's ever so easy being an armchair critic but try deploying this stuff at scale with SLAs covering 5 "9s" and paying customers then tell me you've got all the kinks in bittorrent solved ;)
  - tjoff 8y ago
    Arguably, no, you contrive issues that don't make any sense. Such as presenting the issue that the end of the file might be downloaded first. Or that you can't have different quality versions and dynamically switch. The end will only be downloaded if the client requests it, which won't be unless the user is watching the credits...
    - laumars 8y ago
      The client matters though. Even just getting that client onto your end users systems is going to be problematic. And even those bullet point aside I raised other issues you're yet to reconcile. Plus there are other problems I'd not considered (eg RMTP is often sent over UDP and bittorrent is not only TCP but has additional CRC checks that you don't really want with video streaming). But as you're clearly an expert in video delivery you should build a torrent based video delivery platform. You could make a killing (assun. Or alternatively you might discover these opinions you were dismissing might have had a point and actually video delivery is a lot harder than you first assumed.
      - ubercow13 8y ago
        Like Popcorn Time?
        laumars 8y ago
        I know it can be done via bittorrent. Anything can be hacked to do anything if you're motivated enough. However the question asked was whether it's good enough for paying customers in a commercial environment (ie Netflix). That's a very different set of expectations.
windexh8er 8y ago
To your first point on speed: check out Popcorn Time. Even though this example is, likely, streaming copyrighted material - it showcases that BitTorrent is indeed fast enough to stream reliably at FHD quality. Bandwidth, even from a mildly seeded torrent, can easily push down hundreds of megabits per second. As others have noted place a few well connected, data center oriented, seeds and you have speed and distributed sources (reliability). Content caching boxes already handle the majority of Netflix traffic at the DC/head end of your ISP today. So Netflix could easily add BT to that caching layer and bake it in to their native apps (Android/IOS) as a first test bed.
- laumars 8y ago
  If you're placing cache servers at the ISP then they will charge Netflix for the seeding bandwidth, which would work out more expensive than running traditional RMTP streams because the BT protocol has much more overhead (TCP vs UDP, CRC checks, tracker syncing, etc). And that's without factoring in the likelihood that the cost of bandwidth per GB from a CDN would be much lower than from an ISP. So what would Netflix gain in doing so? They'd need to build new clients, convince content owners that P2P is secure[1], convince ISPs to seed content, pay for new infrastructure, etc. And the final product would be more expensive and _at best_ equivalent to what they already have - though realistically it will be worse on all but the top end viewing platforms (ie laptops and desktops). And for added bonus this infrastructure "upgrade" then removes the possibility of Netflix running live services and dynamic ad injection, etc. So it's more expensive, less future proof, less performant on low end internet connections and wouldn't work on any of the existing smart TVs or streaming HDMI sticks. Like I've said in other comments, BT is fine for hackers and pirates - for people who want to run something for free, willing to run it on a laptop or even willing to be inconvenienced a little for the sake of running something different. But it simply couldn't compete once you start scaling it out as a commercial platform with all of the customer expectations from non-techies and the unseen requirements / complications that happen with professional video delivery platforms behind the scenes. Plus for all of this talk about how good BT could be, people seem to miss the key point I made right from the start: that existing delivery platforms actually aren't that bad. [1] I actually have no qualms with the security side of P2P in terms of protecting copyrighted content. But content owners are notoriously slow to adapt to change and hard to please. Getting them on side might prove an even tougher problem than engineering BT to compete with RMTP at the commercial scale.
rakoo 8y ago
> Plus many services will use a commercial CDN, none of which current support bittorrent. Actually S3 can deliver blobs through bittorrent: https://docs.aws.amazon.com/AmazonS3/latest/dev/S3Torrent.html https://docs.aws.amazon.com/AmazonS3/latest/dev/S3Torrent.ht...
- laumars 8y ago
  Interesting. I wasn't aware of that. Thank you. The 5GB limit would mean you couldn't use it for movies but TV shows should be fine

tjoff 8y ago

I just can't address this further. I'm not convinced you have the slightest clue what bittorrent is (how on earth does not having 5 9s matter for a consumer connection? If a node drops noone will notice). I'm not saying there won't be problems. A major problem is the asymmetric nature of many consumer connections. Not only is the upload often a fraction of the download (that is the easy part), but the download speed can be greatly sacrificed if upload is utilized. Add to that issues that home users might want to use the connection for other stuff. The nightmare and confusion surrounding "I can't game because someone is watching torrent-tube" will be real and add to that issues with ISPs that have a fixed quota or people on mobile (or tethering a mobile connection to laptop). Netflix et al would not like to deal with that kind of FUD spreading around. And all this is before considering local ISP bottlenecks as it isn't what the network was designed for. A vastly superior option is to put a proxy on the ISP network itself (but yes, hard to do for small players). Those alone are probably a magnitude worse than the technical issues you speak of. Even spotify got much flak for it, and no, I don't think anyone on earth think the bandwidth requirements of audio and HD video are similar.

laumars 8y ago
I actually did cover that point (albeit at a much higher level) and of course I know what bittorrent is. Just because I don't agree with you it doesn't mean I don't understand the problems. Quite the opposite, I happen to work in the video delivery industry so it's my job to understand these problems. Like I said, it's ever so easy being an armchair critic but try deploying this stuff at scale with SLAs covering 5 "9s" and paying customers then tell me you've got all the kinks in bittorrent solved ;)
- tjoff 8y ago
  Arguably, no, you contrive issues that don't make any sense. Such as presenting the issue that the end of the file might be downloaded first. Or that you can't have different quality versions and dynamically switch. The end will only be downloaded if the client requests it, which won't be unless the user is watching the credits...
  - laumars 8y ago
    The client matters though. Even just getting that client onto your end users systems is going to be problematic. And even those bullet point aside I raised other issues you're yet to reconcile. Plus there are other problems I'd not considered (eg RMTP is often sent over UDP and bittorrent is not only TCP but has additional CRC checks that you don't really want with video streaming). But as you're clearly an expert in video delivery you should build a torrent based video delivery platform. You could make a killing (assun. Or alternatively you might discover these opinions you were dismissing might have had a point and actually video delivery is a lot harder than you first assumed.
    - ubercow13 8y ago
      Like Popcorn Time?
      - laumars 8y ago
        I know it can be done via bittorrent. Anything can be hacked to do anything if you're motivated enough. However the question asked was whether it's good enough for paying customers in a commercial environment (ie Netflix). That's a very different set of expectations.

windexh8er 8y ago

To your first point on speed: check out Popcorn Time. Even though this example is, likely, streaming copyrighted material - it showcases that BitTorrent is indeed fast enough to stream reliably at FHD quality. Bandwidth, even from a mildly seeded torrent, can easily push down hundreds of megabits per second. As others have noted place a few well connected, data center oriented, seeds and you have speed and distributed sources (reliability). Content caching boxes already handle the majority of Netflix traffic at the DC/head end of your ISP today. So Netflix could easily add BT to that caching layer and bake it in to their native apps (Android/IOS) as a first test bed.

laumars 8y ago
If you're placing cache servers at the ISP then they will charge Netflix for the seeding bandwidth, which would work out more expensive than running traditional RMTP streams because the BT protocol has much more overhead (TCP vs UDP, CRC checks, tracker syncing, etc). And that's without factoring in the likelihood that the cost of bandwidth per GB from a CDN would be much lower than from an ISP. So what would Netflix gain in doing so? They'd need to build new clients, convince content owners that P2P is secure[1], convince ISPs to seed content, pay for new infrastructure, etc. And the final product would be more expensive and _at best_ equivalent to what they already have - though realistically it will be worse on all but the top end viewing platforms (ie laptops and desktops). And for added bonus this infrastructure "upgrade" then removes the possibility of Netflix running live services and dynamic ad injection, etc. So it's more expensive, less future proof, less performant on low end internet connections and wouldn't work on any of the existing smart TVs or streaming HDMI sticks. Like I've said in other comments, BT is fine for hackers and pirates - for people who want to run something for free, willing to run it on a laptop or even willing to be inconvenienced a little for the sake of running something different. But it simply couldn't compete once you start scaling it out as a commercial platform with all of the customer expectations from non-techies and the unseen requirements / complications that happen with professional video delivery platforms behind the scenes. Plus for all of this talk about how good BT could be, people seem to miss the key point I made right from the start: that existing delivery platforms actually aren't that bad. [1] I actually have no qualms with the security side of P2P in terms of protecting copyrighted content. But content owners are notoriously slow to adapt to change and hard to please. Getting them on side might prove an even tougher problem than engineering BT to compete with RMTP at the commercial scale.

rakoo 8y ago

> Plus many services will use a commercial CDN, none of which current support bittorrent. Actually S3 can deliver blobs through bittorrent: https://docs.aws.amazon.com/AmazonS3/latest/dev/S3Torrent.html https://docs.aws.amazon.com/AmazonS3/latest/dev/S3Torrent.ht...

laumars 8y ago
Interesting. I wasn't aware of that. Thank you. The 5GB limit would mean you couldn't use it for movies but TV shows should be fine