On 10/12/21 17:13, Jared Brown wrote:

That's not how it works. Several streaming BitTorrent clients specifically request blocks in order so that you can start watching immediately. Not that you need a special client, it works pretty well with the standard client as well on a well seeded torrent, as blocks are generally requested more or less in order.

Thanks. I wasn't aware there were torrent clients that streamed straight to video. The last time I used torrents, it was to download files for later consumption. I found Usenet feeds more reliable.

Well, yes. Or you could just stream content that is guaranteed to be compatible with the device used.

People on this list would bother to check compatibility. Jane + Thatho just point & click.

They could, and they might even have, I forget, but there is little demand for such a thing as a centralized CDN strategy works better.

Which is why I'm not sure it would work, in today's Internet. Mark.

On Tue, Oct 12, 2021 at 8:16 AM Jared Brown <nanog-isp@mail.com> wrote:

Mark Tinka wrote:

[...]

...

But I doubt that will work, unless someone can think up a clever way to modify BitTorrent to suit today's network architectures. Unless network topology is somehow exposed, this isn't possible. All anybody can do is use latency, IP and ASN information as a proxy.

Nothing is stopping a BitTorrent client from being selective about its peers. The current peer selection algorithm optimizes for throughput, not adjecency or topology.

Thank you to everyone who pointed out this has already been tried in the past--I wasn't aware of it, but it stands to reason. By the time I think of something as a good idea, there's a high probability it's already been done somewhere. ;) In terms of exposing network topology, remember the clients get their information on what chunks to fetch from whom from the tracker. As each client connects to the tracker to report what chunks it has, the tracker can build a mapping of client IP to ASN, coupled with latency. For added fanciness, a traceroute towards the client's public IP can be performed, and then clusters can be mapped of clients with the highest numbers of common elements in the traceroute path back, which would give you a measure of network topological "closeness". That is, if the traceroutes to client A and client B are the same for 12 out of 15 hops, but the traceroutes to client A and client C are only the same for 8 out of 15 hops, we have a good hint that client A and client B are probably topologically closer than client A and client C, and therefore when client A makes a request for chunks of movie 1, if both client B and client C have relevant chunks, we would provide client A with client B's information preferentially over client C's information. That way, the tracker can help cluster data transfers in roughly topological "closeness". Over time, you can build up a more and more accurate topological map as you collect path information from each tracker back to each client. For added points, since we're talking about subscription-based content delivery, associate each client's IP address(es) with the subscriber login information and now you have a mapping of where that subscriber watches content from, over time. Knowing their viewing history would allow you to get an idea of what they're likely to watch next, and where in the network they're likely to watch it, and you can nudge your pre-seeding of chunks of the next-most-likely-to-be-watched content to other clients topologically near to where the subscriber is most likely going to be connected when they want to watch that. ...but perhaps I'm getting a bit too far into the "creepy" factor at this point. ^_^;

- Jared

Thanks! Matt