Many thanks for that link!
I realise now that I went off topic in my previous post because I started talking about the whole thing from the reverse perspective - the sysadmin in charge of servers wanting to make decisions based on topology. I was originally looking at things from the other end, the client looking into the network and trying to make choices based in ‘where’ it is in topology terms.
If all else fails you could start tracerouting to things. But to what? You would already have to sort-of know the answer, it wouldn't help you if you were in a completely unfamiliar part of the internet. Maybe you could just cheat by pre-mapping the world’s interconnection relationships somehow and just handing out a list of points to trace route to. This list would need to be able to be updated, republished reasonably regularly. Perhaps that could be done by using some suitable record type in the DNS, routed under a well-known domain name. Just using the DNS as a database and effectively broadcasting readonly info. You could perhaps even be a bit more helpful, with hints. Something like, “try these nodes, pick out the ones with the lowest hop count then from that set pick the ones with the lowest round trip time”. Also need to allow for the variance in the results, so that times that are within each others' variance ×
k (some factor) are considered ‘equal’, or something. Needs more work to spec it properly. Anyway you end up with one or more nodes that are considered approximately equal, best candidates. Each one is an L2 node and will have an associated set of nodes to traceroute, so you now recurse and consider all the nodes listed under L2 in the same way, until you get to the set L
n, which is a leaf, and there there is whatever database of info which you might need to help you make decisions that are right for that region of the internet. For example: This might have the best NTP server to use, not a very imaginative example. It could tell you which RIR you are in. Imagination fails me, but I am certain that if I were a bit less dopey then the examples could be numerous. It would certainly have an abstract, opaque long bit-width region identifier which is also for you to use with other services. For example an organisation you know might publish a database of useful info indexed by that region id and so you could look something up by that. I am also thinking about something to bootstrap a search process to get you as far as a local database, one of many, that lists ISPs and other large organisations and those databases can give you information that will help you test whether or not you are currently connected to which ISP or other organisation’s subnet and then info you need to know about that outfit. For an ISP, this might cover the range of services available and things like which protocol types are supported or blocked, info on charging or pointer to how to find such info.
DHCP and other systems broadcast various kinds of you-need-to know-this, some of it ‘to get you started’ info onto LANs, but sometimes this is only LAN-wide. Sometimes you need wider range info that comes from further away and has a much wider range of geographical or topological validity/relevance. Also DHCP is not so easily extensible, it's fields are not self-identifying and the total length of stuff has problematic limitations iirc. And then some people do not use DHCP at all. IPv6 RA is less informative and DHCPv6 is I presume far less frequently used as it simply is not needed so it does not enjoy the popularity that DHCPv4 does. So this kind of idea could greatly extend the info publishing idea that DHCP has started up. The two will never be the same as DHCP has very fine granularity, down to the level of the individual LAN, and this is either a great virtue or a showstopper, depending on what kind of info you want to publish and what you want to achieve.
I’m just musing. What a monster post this has become. I do apologise deeply.