> On Oct 12, 2021, at 08:13 , Jared Brown <nanog-...@mail.com> wrote:
>
> Mark Tinka wrote:
>> Someone can correct me if I'm wrong, but the way I know BitTorrent to
>> work is the file is downloaded to disk, unarchived and then listed as
>> ready to watch.
> 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.
>
>> It also assumes the device has all the necessary apps
>> and codecs needed to render the file.
> Well, yes. Or you could just stream content that is guaranteed to be
> compatible with the device used.
>
>> On the other hand, BitTorrent could just make an Apple
>> TV/PS4/PS5/Xbox/whatever-device-you-use app as well.
> 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.
>
>> 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.
Well, latency + measurements of e2e bandwidth and possibly IP+ASN information.
However, in reality, if you are trying to optimize your ability to receive
data, latency + e2e bandwidth are pretty good assuming they don’t
vary greatly (which is, admittedly a problem, they do, and worse, any
client-level continuous measurement at scale will affect the experiment
in a very negative way).
> Nothing is stopping a BitTorrent client from being selective about its
> peers. The current peer selection algorithm optimizes for throughput, not
> adjecency or topology.
Is that bad?
It might be suboptimal for the eyeball ISP, but it seems to me that it’s
probably optimal for everyone else involved.
Owen
