[arghwhat]

This comments on why bittorrent as is isn't used for live streaming, not why P2P shouldn't be used for live streaming

> Latency matters. In bit torrent if the peer goes away, no big deal, just try again in 5 minutes with another peer, you are downloading in random order, who cares if one piecs is delayed 5 minutes. In a live stream your app is broken if it cuts out for 5 minutes.

First of all, BitTorrent clients do not download in random order or wait 5 minutes. They usually download the rarest block first, but can do whatever they want, whenever they want.

Second, standard HLS sets a nominal segment size of 6 seconds (some implementations will go as high as 10 seconds), and a client will usually cache multiple segments before playing (e.g., 3). This mean that you have 18 seconds before a segment becomes critical.

This is not a difficult thing for a P2P network to handle. You'd adapt things to introduce timing information and manage number of hops, but each client can maintain a connection to a number of other clients and have sufficient capacity to fill a segment if a connection fails. Various strategies could be used to distribute load while avoiding latency penalties.

Low-latency HLS uses much smaller segments and would be more demanding, but isn't impossible to manage.

> BitTorrent punishes people who dont contribute

Private communities punish this behavior, BitTorrent clients do not. Most new downloads will appear as freeriders for a long time, and only over long periods far exceeding the download time will enough compatible seeding opportunities arise for them to contribute in any substantial way.

The network does not need everyone to seed, it only needs enough people to seed.

[bavell]

> First of all, BitTorrent clients do not download in random order or wait 5 minutes. They usually download the rarest block first, but can do whatever they want, whenever they want.

The problem here is that BT works so well because the clients default to "good behavior" (prioritize rare pieces first) and discourages "bad behavior" (leeching/no upload).

This tilts the balance on the whole enough to maintain the health of the network. If you change these, you'd need to introduce other mechanisms to preserve the network incentives.

[amy_petrik]

>This tilts the balance on the whole enough to maintain the health of the network. If you change these, you'd need to introduce other mechanisms to preserve the network incentives.

This is the real key point here. In the P2P wars, only bittorrent was the winner (though the old networks still live on and you can find interesting stuff in them...) - the timeless lesson is leeches need to be getting the short end of the stick, people who give back, the prize bonus. It's a fundamental characteristic of human nature here, tragedy of the common leech or something like that

[fragmede]

ish? it's pretty stupid that in the age of seedboxes with gigabit we still prioritize that. The only way to be a seed these days is to get the release microseconds after it gets released, and download it before everyone else gets their hands on it, so you can upload to them. Everyone else then has to download from you, but since everyone that's more than slightly involved has a seedbox with symmetric gigabit, the issue of leeches just isn't the same as it was before in the dial up and DSL era. That the culture hasn't been able to evolve past that, and hangs on to such outdated notions is disappointing. I'm not saying people shouldn't be incentivized to give back. Leeches suck. But in this land of plenty, theres this problem of being unable to seed because there's just too many seeders trying to seed.

[arghwhat]

With streaming, the service provider is generally also controlling the clients, so they should be much better off when it comes to client behavior.

In case of bring-your-own-client, the incentives are exactly the same: Clients would likely default to good behavior as network health equals user experience, and exactly like BitTorrent there will be neither punishment nor need for it if some clients disobey.

[bawolff]

> exactly like BitTorrent there will be neither punishment nor need for it if some clients disobey.

"Punishment" (tit-for-tat algorithm) is one of the defining features of bit torrent, especially in comparison to what came before it.

[arghwhat]

This is not a "punishment", and what clients to differs greatly.

The original spec for the original client allocated a portion of its bandwidth to random peers instead of known-good/preferred peers, so if you had no chunks you were basically bandwidth and/or peer restricted.

If you take the arch linux ISO right now and put it into aria2c to be a new, unknown client with no data to offer, you'll find that while it takes a few seconds to join the network, fetch metadata and connect to peers, you'll quickly saturate your connection completely without ever uploading a single byte.

If you wanted, a streaming network could use direct access or low-hop access as seeding incentive - seed to get slightly lower content latency. When the streaming client is controlled by the content provider, seeding is easily forced and topology could be controlled centrally.

[mannyv]

In video streaming the client really controls everything...unless you have your own client and customize its behavior.

You should see how people try and get HLS to pick a stream. With the default players it's not possible - the client does it.

[arghwhat]

Yes that's the intended behavior of HLS - the content provider advertises which streams are available and at what bitrates, and the client picks which to use based on the current stream performance and its own capability.

The server can control the stream by advertising a customized manifest to individual clients, although it's a bit silly. HLS is designed to be extremely easy to load distribute and throw CDN/cache proxies in front, and it's a bad sad that content providers are this bad at load management. :/

Either way, the assumption here is that you would swap out the client doing HLS with a client designed to use a P2P protocol, including the seeding portion and network health management.

[PaulHoule]

I have a relatively slow ADSL connection, it's not unusual for me to be able to download 100% of the file at say 95% the theoretical rate without uploading anything. If the network has enough upload capacity to do this, does it really need my upload? (Note my client is still there if somebody needs a rare block)

I remember some Bittorrent networks circa 2005 or so which tried to monitor you and punish you for not contributing and this was a disaster for me since my upload is necessarily a small fraction of my download. What I found is that kind of network seemed to perform poorly even when I had a good bidirectional connection. As I saw it, people who have the ability to upload more than they download are a resource that that kind of network can't exploit if everybody is forced to upload as much as they download.

[arghwhat]

You are not required to seed immediately, nor even the same asset. Unless the rules have changed, you would usually just be required to maintain a particular minimum seed lifetime ratio that is easily achieved by idle seeding a library.

The point is to ensure network health with a metric that is simple to understand and verify: that you have been a productive. If you aren't seeding, someone else has to pick up the slack and the network didn't benefit from you obtaining the blocks.

The community itself benefits by giving members a guarantee that stuff there is available with abundant bandwidth, instead of relying purely on the unpaid goodwill of others.

[wruza]

You can't upload much of what's rarely downloaded. The usual way to help the network is to download something popular that you don't need and to seed it. This removes some strain from big seeders and helps them seed other things you don't have.

But personally I believe you're not obliged to anything in torrents, especially with adsl. We got you covered with our multi-hundred u/d ratios. Everyone participating honestly and comfortably is enough, even if that means no upload. Just don't turn it off out of unnecessary principle after downloading.

[mannyv]

Nobody who does live streaming should set their gop to 6 seconds. That's way too big. I set ours to 2 seconds, which lets mobile adjust more quickly to their bandwidth limits.

And as a note, video segments for live are usually set to no cache, as are vod segments. The CDN does the caching. The client should keep segments around if you're doing rewind, but that's a client thing.