C's safety features?

You crack me up!

The relevant information is the cost to the ISP. It's using that information that will help protect network neutrality. You can't scrape that from anywhere. What the torrent client does with that information is then the next issue. I can see that introducing an element of randomness may be useful.

Note that my suggesting is very simple to implement and costs nothing at run time (one failed or succeeded http request). If it turns out that the ISPs don't implement their side of it then that a) gives you an argument against them in the net neutrality debate and b) doesn't stop you going crazy with the heuristics.

I agree that this is a huge problem with BitTorrent. The calls for the preservation of net neutrality should go hand in hand with efforts to fix the one protocol that is causing most pain for ISPs. BitTorrent is 'efficient' from the point of view of the person hosting (seeding) the content. That's great, especially if the hoster isn't making any money from hosting (perhaps because they don't own the rights!). But from the point of view of the ISPs bittorrent is horrendously inefficient, sending the same file fragments across expensive undersea connections again and again.

I think any solution is going to involve the ISPs proving some way for the Bittorrent client to judge the proximity (in terms of $$) of a peer. Since the ISP controls your DNS that could be as simple as downloading an XML file from a server with a fixed name. Eg http://network-config/proximity-ipv4.xml

It could be implemented in clients now. If it was enabled by default I think ISPs would soon start providing the info. There's money involved after all. It would probably improve download speeds too!