<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 12, 2021 at 8:16 AM Jared Brown <<a href="mailto:nanog-isp@mail.com">nanog-isp@mail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Mark Tinka wrote:</blockquote><div>[...] </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> But I doubt that<br>
> will work, unless someone can think up a clever way to modify BitTorrent<br>
> to suit today's network architectures.<br>
  Unless network topology is somehow exposed, this isn't possible. All anybody can do is use latency, IP and ASN information as a proxy.<br>
<br>
  Nothing is stopping a BitTorrent client from being selective about its peers. The current peer selection algorithm optimizes for throughput, not adjecency or topology.<br></blockquote><div><br></div><div>Thank you to everyone who pointed out this has </div><div>already been tried in the past--I wasn't aware of </div><div>it, but it stands to reason.  By the time I think of </div><div>something as a good idea, there's a high probability </div><div>it's already been done somewhere.  ;)</div><div><br></div><div>In terms of exposing network topology, remember the </div><div>clients get their information on what chunks to fetch </div><div>from whom from the tracker.  As each client connects </div><div>to the tracker to report what chunks it has, the tracker </div><div>can build a mapping of client IP to ASN, coupled with </div><div>latency.  For added fanciness, a traceroute towards the </div><div>client's public IP can be performed, and then clusters </div><div>can be mapped of clients with the highest numbers </div><div>of common elements in the traceroute path back, </div><div>which would give you a measure of network topological </div><div>"closeness".</div><div><br></div><div>That is, if the traceroutes to client A and client B are the </div><div>same for 12 out of 15 hops, but the traceroutes to client A </div><div>and client C are only the same for 8 out of 15 hops, we have </div><div>a good hint that client A and client B are probably topologically </div><div>closer than client A and client C, and therefore when client A makes </div><div>a request for chunks of movie 1, if both client B and client C have </div><div>relevant chunks, we would provide client A with client B's information </div><div>preferentially over client C's information.</div><div><br></div><div>That way, the tracker can help cluster data transfers in roughly </div><div>topological "closeness".  Over time, you can build up a more and </div><div>more accurate topological map as you collect path information </div><div>from each tracker back to each client.  For added points, since </div><div>we're talking about subscription-based content delivery, associate </div><div>each client's IP address(es) with the subscriber login information </div><div>and now you have a mapping of where that subscriber watches </div><div>content from, over time.  Knowing their viewing history would </div><div>allow you to get an idea of what they're likely to watch next, and </div><div>where in the network they're likely to watch it, and you can nudge </div><div>your pre-seeding of chunks of the next-most-likely-to-be-watched </div><div>content to other clients topologically near to where the subscriber </div><div>is most likely going to be connected when they want to watch that. </div><div><br></div><div>...but perhaps I'm getting a bit too far into the "creepy" factor at </div><div>this point.   ^_^;</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Jared<br>
<br></blockquote><div><br></div><div>Thanks!</div><div><br></div><div>Matt </div></div></div>