I don't think people are appreciating the nuance of what you're saying. Most of what you are saying isn't accurate for netflix style streaming, which would actually be more aptly called "video on demand", but is very applicable to "live streaming" in the sense of live sporting events or news broadcasts.
Video-on-demand is perfectly implementable on top of BitTorrent. As you say, there are some latency pitfalls you'll have to avoid, but that's nothing you can't hack yourself out of.
Livestreaming is a different beast. As you say, the problem with livestreaming is that everyone needs the same content at the same time. If I spend 200ms downloading the next 500ms worth of content, then there's nobody to share it with, they all spent the 200ms doing the same. BitTorrent relies on the time shift that is allowed between me downloading the content and you requesting it. If you request it before I've got it, well I can't fulfil that request, only the guy I intend to get it from can.
If you wanted to implement something like that, you would probably pick a tree of seeders where the protocol would pick a subset of trusted nodes that it would upload the content to before then allowing them to seed it, and the have them doing the same recursively.
That would obviously introduce a bunch of complexity and latency, and would very much not be BitTorrent anymore.
I don't think he's saying it needs to be BitTorrent, just applying some principles from it.
For example, say you have a cluster of people on the call in the US and another cluster in the UK. Ping times are 100ms or more across the ocean, there will be some random packets lost, but ping times within the UK are around 15ms max. By working co-operatively and sharing among themselves the clients in one cluster can fill in missing packets from a different cluster far quicker than the requesting them from the originating host.
In general, the ability to request missing packets from a more local source should be able to improve overall video call quality. It still might be "too late", because for minimal latency, you might choose to use packets as soon as they arrive and maybe even treat out-of-order packets as missing, and just display a blockier video instead, but if the clients can tolerate a little more latency (maybe a tunable setting, like 50ms more than the best case) then it should in theory work better than current systems.
I've been mulling over some of these ideas myself in the past, but it's never been high enough on my TODO list to try anything out.
> By working co-operatively and sharing among themselves the clients in one cluster can fill in missing packets from a different cluster far quicker than the requesting them from the originating host.
That's only true if you assume the nodes operate sequentially, which is not given. If the nodes operate independently from one another (which they would, being non-cooperating) they'd all get a response in ~100ms (computation and signaling time is negligible here), which is faster than they could get it cooperatively, even if we assume perfect cooperation (100ms for the first local node + 15ms from there). It's parallelism. Doing less work might seem theoretically nice, but if you have the capacity to do the same work twice simultaneously you avoid the synchronization.
Basically, it falls somewhere in my loose "tree based system" sketch. In this case the "trusted" nodes would be picked based on ping time clustering, but the basic sketch that you pick a subset of nodes to be your local nodes and then let that structure recursively play out is the same.
The problem you run into is latency. There's no good way to pick a global latency figure for the whole network, since it varies by how deep into the tree you are. As the tree grows deeper, you end up having to retune the delay. The only other option is to grow in width at which point you've just created a another linear growth problem, albeit with a lower slope.
I generally agree, but once you do that you lose most of the properties that make bit torrent so effective.
E.g. if you arrange the network into a tree like that, you need to make sure all nodes are matched appropriately in terms of bandwidth, latency, geography, number of connected nodes. Now you have to somehow the network topology stays good in face of churn and bad peers. Suddenly everything is complicated and not looking very p2p.
Maybe dufferent protocols are possible to manage that, but i think there is a reason why p2p protocols kind of didn't develop much beyond bit torrent.