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