On 10 Dec 2021, at 18:25, Wessels, Duane <dwessels@verisign.com> wrote:
Hi Andrew,
I think this looks really good! Thank you for working on this implementation.
It looks like maybe your latencies are reported in seconds, and the document says it should be milliseconds?
Looked again and you’re right. This is an easy change I can make.
Looking at the data, I admit I was surprised to see 10x COM/NS and COM/DS measurements. Rereading RSSAC057, I can see why you did that, although I’m not sure that was the intention of the document? I get why it is a good idea to make 10 queries to average out latency, but I’m not sure we really need to do that for all of the query types. Over all transports and protocols each identity receives 40 COM/NS and 40 COM/DS queries, which seems like a lot. Do we really expect COM/DS, COM/NS, and hostname.bind latencies to be all that different? Does someone remember the rationale here?
I had the same thought, but implemented it the way the pseudocode in RSSAC057 is written. It also says to record both data and latencies, but it’s not really clear what is meant by ‘data’. Is that Answer || Additional || Authority, and should I record the TTL? My decisions here were somewhat arbitrary. It’s the same stuff every time and I didn’t want a giant repetitive JSON output.
In your JSON structure you have:
"CH": { "ipv4": { "udp": { ".": [
and
"NS": { "ipv4": { "udp": { "com": [
I might suggest that something like this might be a little better:
“hostname.bind/CH/TXT”: { “ipv4”: {
“com/IN/NS”: { “ipv4”: {
mostly because “CH” and “NS” and “DS” aren’t from the same set of thing.
I just used them as shorthand, but I see how that’s confusing. I could use different identifiers. Instead of CH/NS/DS I could use q1/q2/q3 since they correspond to RSSAC057 Section 3.2.[1|2|3]. Thanks for the feedback. —Andrew
DW
On Dec 10, 2021, at 6:14 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus Members,
I’ve been working on an implementation of RSSAC057: Requirements for Measurements of the Local Perspective on the Root Server System.
It can be found here: <https://urldefense.com/v3/__https://github.com/rssac-caucus/perf_root__;!!Pt... >
It’s a python script that relies heavily on dnspython. It has a bunch of CLI options, but if executed without any options it will perform according to RSSAC057 and output JSON when it finishes. Attaced is a JSON file from running it at an Amsterdam datacenter.
There are two discrepencies I note below. Otherwise I believe it conforms with RSSAC057. - It only performs UDP traceroutes and RSSAC057 specifies UDP and TCP traceroutes. TCP traceroute requires root and I didn’t think it wise for this script to require root. - RSSAC057 specifies a traceroute probe timeout of 5 seconds. I instead chose to use the variable default of the traceroute binary judging that it probably knows best.
And below are a couple gotchas I note for people interested in testing it. - It requires dnspython 2.2.0, which is really new. I needed 2.2.0 because it adds the ability to set specific DNS flags in dns.message.make_query(). - I’ve developed this on Debian Linux, but it theoretically should work on anything that supports python3 and dnspython. The thing that will break is the python mulItprocessing.pool library which I use to perform all the testing asynchronously. I could not get this library to properly handle UNIX signals on OpenBSD, so I don’t recommend running this on OpenBSD. It did work on FreeBSD when I tested it. I’m definitely interested in the experiences of others on OSs other than Linux.
Thanks, Andrew
<rootperf.json> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://urldefense.com/v3/__https://secure-web.cisco.com/15Hdo9RHzZrgLQxz5ij...
_______________________________________________ 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://urldefense.com/v3/__https://secure-web.cisco.com/1nPzmve-FV7p-2a1WVu... ) and the website Terms of Service (https://urldefense.com/v3/__https://secure-web.cisco.com/1padnI8AIN6nBD0EyIY... 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.