Research Paper - Optimal Selection of DNS Root Instance
Dear RSSAC Caucus, I thought it's worth sharing the subject research paper about optimal selection measurement of DNS Root Instance, with analysis of two approaches (shortest ASPath and geographic distance). https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10225500 Kind Regards *Hafiz Farooq* --- This message has been scanned via Symantec MessageLabs & SpamDefense Engine
On Wed, Aug 23, 2023 at 10:43 PM, Hafiz Farooq <hmfarouq@gmail.com> wrote:
Dear RSSAC Caucus,
I thought it's worth sharing the subject research paper about optimal selection measurement of DNS Root Instance, with analysis of two approaches (shortest ASPath and geographic distance).
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10225500
Interesting paper, but it seems to be based on a flawed premise, namely that geographic and network topology are correlated. The paper notes: "For example, when domestic telecom users access the I root instance, they all access the I root Tokyo instance and Singapore instance across the border, even though there are I root Beijing and Shenyang instances in China." Yes, so…? Network topologies often vary wildly from geographic topology. Networks only hand off traffic to each other where they actually peer, and this may not correlate with geography at all. As an example, a few years ago I was doing a network training at the University of Fiji in Suva. In order to reach a Fijian newspaper server in Nandi (120lm away) my packets went from Suva to Sydney on Southern Cross Cable (SCCN), changed networks in Sydney, and returned to Suva to get routed to Nandi. Return traffic would follow this same path. This is a one way trip of ~7,500KM, or a full round trip of ~15,000KM. Clearly this is wildly sub-optimal, but the failure here is not because of geography, the failure is that there are multiple networks in Fiji that **do not peer in Fiji**. If "domestic telecom users" accessing the I root instance travel to Tokyo and Singapore instead of Beijing and Shenyang, this is (largely) a failure of the network peering policies and incentives, not a failure of the RSS. Yes, I (or whoever) could potentially deploy servers on more / different networks — but the actual metrics should be "what is the latency, and is it OK?", not "what is the geographical distance?" W
Kind Regards *Hafiz Farooq*
--- This message has been scanned via Symantec MessageLabs & SpamDefense Engine
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Op 8 sep. 2023 om 18:41 heeft Warren Kumari <warren@kumari.net> het volgende geschreven:
Clearly this is wildly sub-optimal, but the failure here is not because of geography, the failure is that there are multiple networks in Fiji that **do not peer in Fiji**.
Whether this is sub-optimal or a failure at all depends also on what you are optimising for. In the case of a particular root server in a system when there are many, a system that is providing a service that most resolvers query only occasionally and usually not in the hot path for anything an end user is trying to do, it is reasonable to optimise for availability of the system as a whole rather than transaction latency for queries to any particular instance. As an extreme but not uncommon example, a resolver that keeps a local copy of the root zone and maintains its currency within the published SOA timers has very modest requirements of the root server system at all and probably doesn't consider a long trombone to get a response any kind of failure. In other examples where proximity is a clear advantage (like CDNs) the pressure from both supplier and consumer of services tends to mean that both ends have reasons to reduce transaction latency, and in those cases it's common to see the mismatch between topology and geography addressed in some way (at least when geography has a clear bearing on performance, as it does in your South Pacific example). The root server system is just not one of those examples. Joe
On Fri, Sep 08, 2023 at 1:23 PM, Joe Abley <jabley@strandkip.nl> wrote:
Op 8 sep. 2023 om 18:41 heeft Warren Kumari <warren@kumari.net> het volgende geschreven:
Clearly this is wildly sub-optimal, but the failure here is not because of geography, the failure is that there are multiple networks in Fiji that **do not peer in Fiji**.
Whether this is sub-optimal or a failure at all depends also on what you are optimising for.
Indeed. This case was sub-optimal for me as a user (the Internet felt slow), and very likely suboptimal for the Fijian network operators (submarine cable capacity is not cheap). Clearly, however, it is great for the investors in SCCN, whatever operators are charging for transit, etc.
In the case of a particular root server in a system when there are many, a system that is providing a service that most resolvers query only occasionally and usually not in the hot path for anything an end user is trying to do, it is reasonable to optimise for availability of the system as a whole rather than transaction latency for queries to any particular instance.
As an extreme but not uncommon example, a resolver that keeps a local copy of the root zone and maintains its currency within the published SOA timers has very modest requirements of the root server system at all and probably doesn't consider a long trombone to get a response any kind of failure.
In other examples where proximity is a clear advantage (like CDNs) the pressure from both supplier and consumer of services tends to mean that both ends have reasons to reduce transaction latency, and in those cases it's common to see the mismatch between topology and geography addressed in some way (at least when geography has a clear bearing on performance, as it does in your South Pacific example). The root server system is just not one of those examples.
Yah, full agreement. W
Joe
participants (3)
-
Hafiz Farooq -
Joe Abley -
Warren Kumari