[rssac-caucus] Opening RSSAC-002 for revision
Dear RSSAC Caucus, RSSAC has decided to open the RSSAC-002 "Measurements of the Root Server System" document for revision and is asking the Caucus to produce an update. Based on implementation experience, three minor problems have been identified in the current document. It is my belief that these problems and remedies are simple enough that a work party is not warranted. I'd like to ask the Caucus to consider my descriptions of the problems and proposed remedies below as a starting point for this discussion. If we can come to a consensus by RSSAC's December 3 meeting then it is likely the revised document can be approved and published shortly after that. Duane W. #1 YAML Indentation =================== Problem: In sections 4.3 (traffic-volume) and 4.6 (unique-sources) the example YAML shows some lines indented when they should not be. In these YAML documents none of the lines should be indented. If they are indented as given in the example, a YAML parser generates an error and fails to load the document. Proposed Remedy: Remove indentation from the example YAML documents in sections 4.3 and 4.6. #2 TCP Response Size ==================== Problem: Section 2.4 describes the query and response size distributions. The description does not specifically mention the two-octet prefix for TCP messages, which leads to ambiguity. While the difference is not especially significant (i.e. two octets out of 50-500), the ambiguity should be removed. The text currently says: DNS query sizes are determined by the length of the entire DNS message. Thus, in practical terms, the transport headers (Ethernet, IP, and TCP or UDP etc) are removed leaving the DNS payload to measure. The DNS query message sizes should be recorded for both TCP and UDP. Proposed Remedy: Amend the paragraph above to read: DNS query sizes are determined by the length of the entire DNS message. Thus, in practical terms, the transport headers (Ethernet, IP, and TCP or UDP etc) are removed leaving the DNS payload to measure. The DNS query message sizes should be recorded for both TCP and UDP. For TCP the DNS payload also includes a two-octet size prefix. Implementations should include these two octets in the calculation of message size. #3 Zone Size Metric =================== Problem: Section 2.2 describes how to calculate the zone size as a wire-format AXFR response. Since AXFR happens only over TCP, those DNS messages also have a two-octet length prefix. The description is unclear whether or not to include the two-octet length prefix in the reported value. Proposed Remedy: Amend the paragraph in section 2.2 to read: The size of the compiled root zone is measured in wire-format AXFR response encoded as if to be transmitted in the smallest number of messages with the names in the zone and the resource records in each RRset sorted into DNSSEC order, and using compression pointers wherever possible. Note that since AXFR occurs over TCP, this measurement must also include the two-octet size prefix for each message transmitted.
On 20/10/2015 16:50, Wessels, Duane wrote:
Proposed Remedy:
Amend the paragraph above to read:
DNS query sizes are determined by the length of the entire DNS message. Thus, in practical terms, the transport headers (Ethernet, IP, and TCP or UDP etc) are removed leaving the DNS payload to measure. The DNS query message sizes should be recorded for both TCP and UDP. For TCP the DNS payload also includes a two-octet size prefix. Implementations should include these two octets in the calculation of message size.
My preference is that those two framing octets should be *excluded* from the calculation, and treated as if they were part of the transport overhead. Whilst the current development version of BIND does include them, I believe that to be an oversight that should be corrected, and there's already a ticket in our bug tracking system requesting that. My rationale is that with the 16-byte wide histograms it's impossible to do an exact 1:1 comparison of UDP packets against TCP packets. You can't tell from the binning whether the packets in a particular TCP bin might have gone into a different bin with UDP. Even before this issue came up a couple of months ago it had caused me slight puzzlement when I discovered this quirk in BIND's stats channel when two packets that I expected to be in the same bin didn't get counted that way. Ray
On 10/20/15, 5:02 PM, "rssac-caucus-bounces@icann.org on behalf of Ray Bellis" <rssac-caucus-bounces@icann.org on behalf of ray@isc.org> wrote:
On 20/10/2015 16:50, Wessels, Duane wrote:
Proposed Remedy:
Amend the paragraph above to read:
DNS query sizes are determined by the length of the entire DNS message. Thus, in practical terms, the transport headers (Ethernet, IP, and TCP or UDP etc) are removed leaving the DNS payload to measure. The DNS query message sizes should be recorded for both TCP and UDP. For TCP the DNS payload also includes a two-octet size prefix. Implementations should include these two octets in the calculation of message size.
My preference is that those two framing octets should be *excluded* from the calculation, and treated as if they were part of the transport overhead.
Whilst the current development version of BIND does include them, I believe that to be an oversight that should be corrected, and there's already a ticket in our bug tracking system requesting that.
My rationale is that with the 16-byte wide histograms it's impossible to do an exact 1:1 comparison of UDP packets against TCP packets. You can't tell from the binning whether the packets in a particular TCP bin might have gone into a different bin with UDP.
Even before this issue came up a couple of months ago it had caused me slight puzzlement when I discovered this quirk in BIND's stats channel when two packets that I expected to be in the same bin didn't get counted that way.
I am fine with explicitly saying either saying the payload size does or does not include the two-octet size prefix. Ray's logic here for exclusion seems fine. --Paul Hoffman
On Oct 20, 2015, at 5:02 PM, Ray Bellis <ray@isc.org> wrote:
On 20/10/2015 16:50, Wessels, Duane wrote:
Proposed Remedy:
Amend the paragraph above to read:
DNS query sizes are determined by the length of the entire DNS message. Thus, in practical terms, the transport headers (Ethernet, IP, and TCP or UDP etc) are removed leaving the DNS payload to measure. The DNS query message sizes should be recorded for both TCP and UDP. For TCP the DNS payload also includes a two-octet size prefix. Implementations should include these two octets in the calculation of message size.
My preference is that those two framing octets should be *excluded* from the calculation, and treated as if they were part of the transport overhead.
Whilst the current development version of BIND does include them, I believe that to be an oversight that should be corrected, and there's already a ticket in our bug tracking system requesting that.
My rationale is that with the 16-byte wide histograms it's impossible to do an exact 1:1 comparison of UDP packets against TCP packets. You can't tell from the binning whether the packets in a particular TCP bin might have gone into a different bin with UDP.
Ray, I don't really get this argument. I don't see why the "width" of the histogram matters. And I don't see, from an RSSAC-002 perspective, why it matters if packets end up int he same bin or not. The measurements are highly aggregated. DW
On 20/10/2015 21:45, Wessels, Duane wrote:
I don't really get this argument. I don't see why the "width" of the histogram matters. And I don't see, from an RSSAC-002 perspective, why it matters if packets end up int he same bin or not. The measurements are highly aggregated.
It's not a big deal either way, but to me the proposal to make the figures inclusive rather than exclusive feels intuitively wrong. Many common EDNS buffer sizes are multiples of 16 bytes, so IMHO the results will just be that little bit more accurate if the framing octets are omitted. Ray
On 20/10/2015 16:50, Wessels, Duane wrote:
#3 Zone Size Metric ===================
Problem:
Section 2.2 describes how to calculate the zone size as a wire-format AXFR response. Since AXFR happens only over TCP, those DNS messages also have a two-octet length prefix. The description is unclear whether or not to include the two-octet length prefix in the reported value.
Proposed Remedy:
Amend the paragraph in section 2.2 to read:
The size of the compiled root zone is measured in wire-format AXFR response encoded as if to be transmitted in the smallest number of messages with the names in the zone and the resource records in each RRset sorted into DNSSEC order, and using compression pointers wherever possible. Note that since AXFR occurs over TCP, this measurement must also include the two-octet size prefix for each message transmitted.
I wasn't around when this was first set, and I'm not so bothered about the two byte per-message overhead, since there's no UDP to compare against. However - the current choice of using the 'smallest number of messages' is curious, particularly in light of the text in the remained of section 2.2 We've recently observed that AXFRs from RIPE's 'k' root are (sometimes?) more than 10% shorter than those from our 'f' roots. I just ran a test and got 619050 bytes from 'k' vs 696472 for 'f'. The reason is that compression pointers can only address the first 16kB of any message. BIND defaults to 'smallest number of messages' by using as much of the 64kB maximum as possible but the corollary is that 3/4 of the data doesn't get compressed at all. If the expectation is that operators will just perform an AXFR against their servers and measure the bytes received, that clearly isn't going to produce consistent results across all operators / implementations. Ray
On 15/10/20 18:17 , Ray Bellis wrote:
On 20/10/2015 16:50, Wessels, Duane wrote:
#3 Zone Size Metric ===================
Problem:
Section 2.2 describes how to calculate the zone size as a wire-format AXFR response. Since AXFR happens only over TCP, those DNS messages also have a two-octet length prefix. The description is unclear whether or not to include the two-octet length prefix in the reported value.
Proposed Remedy:
Amend the paragraph in section 2.2 to read:
The size of the compiled root zone is measured in wire-format AXFR response encoded as if to be transmitted in the smallest number of messages with the names in the zone and the resource records in each RRset sorted into DNSSEC order, and using compression pointers wherever possible. Note that since AXFR occurs over TCP, this measurement must also include the two-octet size prefix for each message transmitted.
I wasn't around when this was first set, and I'm not so bothered about the two byte per-message overhead, since there's no UDP to compare against.
However - the current choice of using the 'smallest number of messages' is curious, particularly in light of the text in the remained of section 2.2
We've recently observed that AXFRs from RIPE's 'k' root are (sometimes?) more than 10% shorter than those from our 'f' roots. I just ran a test and got 619050 bytes from 'k' vs 696472 for 'f'.
The reason is that compression pointers can only address the first 16kB of any message. BIND defaults to 'smallest number of messages' by using as much of the 64kB maximum as possible but the corollary is that 3/4 of the data doesn't get compressed at all.
If the expectation is that operators will just perform an AXFR against their servers and measure the bytes received, that clearly isn't going to produce consistent results across all operators / implementations.
Please keep in mind that for this particular metric 'consistent results across all operators' are not necessarily to be expected. As RSSAC-002 itself also explains, the goal of providing this metric was "to detect any trends in the growth of the zone". Of course serious issues like truncated zone files are a different thing altogether, but size differences related to compression differences could occur. Cheers, Romeo
Ray
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
On Oct 20, 2015, at 12:58 PM, Romeo Zwart <romeo.zwart@ripe.net<mailto:romeo.zwart@ripe.net>> wrote: Please keep in mind that for this particular metric 'consistent results across all operators' are not necessarily to be expected. As RSSAC-002 itself also explains, the goal of providing this metric was "to detect any trends in the growth of the zone". Of course serious issues like truncated zone files are a different thing altogether, but size differences related to compression differences could occur. Personally, I would have preferred to keep track of the uncompressed sizes of all the RRs in the Answer section of the Zone transfer. This should be more repeatable between implementations and reflects the actual size of the Zones. D-Root’s RSSAC002 tracking code is keeping track of that value as an alternate Zone size metric (we are also tracking the counts of each RR Class/Type).
On 20/10/2015 17:58, Romeo Zwart wrote:
Please keep in mind that for this particular metric 'consistent results across all operators' are not necessarily to be expected. As RSSAC-002 itself also explains, the goal of providing this metric was "to detect any trends in the growth of the zone". Of course serious issues like truncated zone files are a different thing altogether, but size differences related to compression differences could occur.
In between the text Duane quoted, and what you've quoted above, RSSAC002 says: "The size of the compiled root zone is not expected to change from operator to operator; but in an effort to ensure consistency in the root system all operators should report the size of the root zone so if there are any differences that are seen on the platform they can be identified and remedied." To my reading that very much looks like an expectation of consistent results across all operators. To be fair, if everyone _emulated_ an AXFR using the given parameters, that's what you'd get, but if you perform a real AXFR and measure the results, you probably won't. FWIW, I endorse the later suggestion that the measurement should be made on the *uncompressed* zone post AXFR. Ray
"To my reading that very much looks like an expectation of consistent results across all operators." Yes. On October 20, 2015 11:08:11 AM PDT, Ray Bellis <ray@isc.org> wrote:
On 20/10/2015 17:58, Romeo Zwart wrote:
Please keep in mind that for this particular metric 'consistent results across all operators' are not necessarily to be expected. As RSSAC-002 itself also explains, the goal of providing this metric was "to detect any trends in the growth of the zone". Of course serious issues like truncated zone files are a different thing altogether, but size differences related to compression differences could occur.
In between the text Duane quoted, and what you've quoted above, RSSAC002 says:
"The size of the compiled root zone is not expected to change from operator to operator; but in an effort to ensure consistency in the root system all operators should report the size of the root zone so if there are any differences that are seen on the platform they can be identified and remedied."
To my reading that very much looks like an expectation of consistent results across all operators.
To be fair, if everyone _emulated_ an AXFR using the given parameters, that's what you'd get, but if you perform a real AXFR and measure the results, you probably won't.
FWIW, I endorse the later suggestion that the measurement should be made on the *uncompressed* zone post AXFR.
Ray
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Tue, 20 Oct 2015 18:18:54 -0000, P Vixie wrote:
"To my reading that very much looks like an expectation of consistent results across all operators."
Yes.
On October 20, 2015 11:08:11 AM PDT, Ray Bellis <ray@isc.org> wrote:
On 20/10/2015 17:58, Romeo Zwart wrote:
Please keep in mind that for this particular metric 'consistent results across all operators' are not necessarily to be expected. As RSSAC-002 itself also explains, the goal of providing this metric was "to detect any trends in the growth of the zone". Of course serious issues like truncated zone files are a different thing altogether, but size differences related to compression differences could occur.
In between the text Duane quoted, and what you've quoted above, RSSAC002 says:
"The size of the compiled root zone is not expected to change from operator to operator; but in an effort to ensure consistency in the root system all operators should report the size of the root zone so if there are any differe! nces that are seen on the platform they can be identified and remedied."
To my reading that very much looks like an expectation of consistent results across all operators.
To be fair, if everyone _emulated_ an AXFR using the given parameters, that's what you'd get, but if you perform a real AXFR and measure the results, you probably won't.
FWIW, I endorse the later suggestion that the measurement should be made on the *uncompressed* zone post AXFR.
To pick up at the end of this thread, what I'm hearing is: current goal A: "ensure consistency in the root system all operators should report the size of the root zone so if there are any differences that are seen on the platform they can be identified and remedied." current method A: report zone transfer size. But the problem Duane reported at the start of this thread is: transfer size is unclearly specified, so it's not consistent across letters. Various people have proposed tightening the definition, the limit of which is: proposed method B: basically do exactly what bind8 does, and anything else is a bug. That path WILL succeed in getting consistency across letters. I have nothing against bind8, but I think we've failed to accomplish the actual goal, because: "same size" != "no differences in contents". Given known attacks on md5 and threats on sha1, even some cryptographic hashes don't prove consistency. There seems little benefit (and non-zero cost!) to going to great lengths to get an perfect number, when it won't actually answer the question (!). I suggest we need to align our technical methods with the question we're asking. Perhaps either: new goal C: each root should detect changes in its trend of size. new method C: each letter should report zone transfer size consistently across its reporting (but not necessarily across other letters) OR old goal D: Each letter should guarantee consistency of the zone contents against the master copy. new method D: some cryptographic checksum on a precisely specified input that produces a result that actually proves goal D. But let's not incrementally create something that splits the difference, lest we build the worlds most carefully engineered, Stradivarius-esque ukulele. -John Heidemann
On Oct 20, 2015, at 7:08 PM, Ray Bellis <ray@isc.org> wrote:
FWIW, I endorse the later suggestion that the measurement should be made on the *uncompressed* zone post AXFR.
Sigh. We've already gone around those circles and a number of operators are already producing and publishing data based on the compressed AXFR description. DW
On 20/10/2015 21:37, Wessels, Duane wrote:
Sigh. We've already gone around those circles and a number of operators are already producing and publishing data based on the compressed AXFR description.
Oh well... :( I'm late to the party having only joined caucus very recently, but that description is potentially awkward to answer consistently if your servers don't use the maximum 64 kB message size that results in the specified fewest number of messages. Unfortunately the caucus mailing list archive starts after the publication date of RSSAC02. Ray
Hi Ray, On 15/10/20 20:08 , Ray Bellis wrote:
On 20/10/2015 17:58, Romeo Zwart wrote:
Please keep in mind that for this particular metric 'consistent results across all operators' are not necessarily to be expected. As RSSAC-002 itself also explains, the goal of providing this metric was "to detect any trends in the growth of the zone". Of course serious issues like truncated zone files are a different thing altogether, but size differences related to compression differences could occur.
In between the text Duane quoted, and what you've quoted above, RSSAC002 says:
"The size of the compiled root zone is not expected to change from operator to operator; but in an effort to ensure consistency in the root system all operators should report the size of the root zone so if there are any differences that are seen on the platform they can be identified and remedied."
To my reading that very much looks like an expectation of consistent results across all operators.
Indeed, that part of the text reads like it. However, the original intention of adding this metric was a different one, as the part that I quoted illustrates. I have the impression that we are trying to overload root zone size with a misunderstood content verification function. BTW, wasn't there this great DNS security technology, deployed to the root roughly 5-6 years ago, that had to do with securing DNS zone content? Cheers, Romeo
On 20/10/2015 22:28, "rssac-caucus-bounces@icann.org on behalf of Romeo Zwart" <rssac-caucus-bounces@icann.org on behalf of romeo.zwart@ripe.net> wrote:
Hi Ray,
On 15/10/20 20:08 , Ray Bellis wrote:
On 20/10/2015 17:58, Romeo Zwart wrote:
Please keep in mind that for this particular metric 'consistent results across all operators' are not necessarily to be expected. As RSSAC-002 itself also explains, the goal of providing this metric was "to detect any trends in the growth of the zone". Of course serious issues like truncated zone files are a different thing altogether, but size differences related to compression differences could occur.
In between the text Duane quoted, and what you've quoted above, RSSAC002 says:
"The size of the compiled root zone is not expected to change from operator to operator; but in an effort to ensure consistency in the root system all operators should report the size of the root zone so if there are any differences that are seen on the platform they can be identified and remedied."
To my reading that very much looks like an expectation of consistent results across all operators.
Indeed, that part of the text reads like it. However, the original intention of adding this metric was a different one, as the part that I quoted illustrates. I agree with romeo here, this measurement and the whole of the RSSAC002 document was, to mt knowlage, intended to measure the impact of scaling the root zone and is not intended as a consistency check.. I would also like to echo Duane's comment. This was discussed at length during the document draft, unfortunately the archives don't go back that far but i could forward relevant mails of list if people are interested.
John
On 21/10/2015 10:34, John Bond wrote:
I agree with romeo here, this measurement and the whole of the RSSAC002 document was, to mt knowlage, intended to measure the impact of scaling the root zone and is not intended as a consistency check.. I would also like to echo Duane's comment. This was discussed at length during the document draft, unfortunately the archives don't go back that far but i could forward relevant mails of list if people are interested.
OK, but if the document is being opened for editing could paragraph 3 at least be amended to remove the text about "to ensure consistency in the root system" ? Then at least the original intent and the document might be consistent ;-) Ray
On 15/10/21 12:14 , Ray Bellis wrote:
On 21/10/2015 10:34, John Bond wrote:
I agree with romeo here, this measurement and the whole of the RSSAC002 document was, to mt knowlage, intended to measure the impact of scaling the root zone and is not intended as a consistency check.. I would also like to echo Duane's comment. This was discussed at length during the document draft, unfortunately the archives don't go back that far but i could forward relevant mails of list if people are interested.
OK, but if the document is being opened for editing could paragraph 3 at least be amended to remove the text about "to ensure consistency in the root system" ?
Then at least the original intent and the document might be consistent ;-)
I'd be quite in favour of that. :) As a matter of fact, in view of that original goal, I even would want to go further and propose to measure root zone size at a canonical source and not at the root server level. I guess that would beg the question if this metric would even have to remain as part of rssac-002. Cheers, Romeo
Ray
Bind8 used 16kbyte messages in axfr for exactly this reason. Bind9 should do the same. On October 20, 2015 9:17:13 AM PDT, Ray Bellis <ray@isc.org> wrote:
On 20/10/2015 16:50, Wessels, Duane wrote:
#3 Zone Size Metric ===================
Problem:
Section 2.2 describes how to calculate the zone size as a wire-format AXFR response. Since AXFR happens only over TCP, those DNS messages also have a two-octet length prefix. The description is unclear whether or not to include the two-octet length prefix in the reported value.
Proposed Remedy:
Amend the paragraph in section 2.2 to read:
The size of the compiled root zone is measured in wire-format AXFR response encoded as if to be transmitted in the smallest number of messages with the names in the zone and the resource records in each RRset sorted into DNSSEC order, and using compression pointers wherever possible. Note that since AXFR occurs over TCP, this measurement must also include the two-octet size prefix for each message transmitted.
I wasn't around when this was first set, and I'm not so bothered about the two byte per-message overhead, since there's no UDP to compare against.
However - the current choice of using the 'smallest number of messages' is curious, particularly in light of the text in the remained of section 2.2
We've recently observed that AXFRs from RIPE's 'k' root are (sometimes?) more than 10% shorter than those from our 'f' roots. I just ran a test and got 619050 bytes from 'k' vs 696472 for 'f'.
The reason is that compression pointers can only address the first 16kB of any message. BIND defaults to 'smallest number of messages' by using as much of the 64kB maximum as possible but the corollary is that 3/4 of the data doesn't get compressed at all.
If the expectation is that operators will just perform an AXFR against their servers and measure the bytes received, that clearly isn't going to produce consistent results across all operators / implementations.
Ray
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Well, let's define 16kb as part of this spec, and file a bug report against bind9. Vixie On October 20, 2015 10:48:56 AM PDT, Ray Bellis <ray@isc.org> wrote:
On 20/10/2015 18:34, P Vixie wrote:
Bind8 used 16kbyte messages in axfr for exactly this reason. Bind9 should do the same.
I agree that it should, but it doesn't appear to.
Ray
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Oct 21, 2015, at 12:52 AM, Wessels, Duane <dwessels@verisign.com> wrote:
RSSAC has decided to open the RSSAC-002 "Measurements of the Root Server System" document for revision and is asking the Caucus to produce an update. Based on implementation experience, three minor problems have been identified in the current document.
The following are notes from D-Root on RSSAC002. Some of the comments may have already mentioned by others... - load-time: - In a system with a large number of sites,there may be a large variance in the time it takes to load specific sites. Should the metric reflect worst case, average, or what? This should be specified so that meaningful comparisons may be be made. - The examples in the document should not include the quotes in the keys. - zone-size: - It would be nice if metric was based on something other than a specific implementation's zone traffic compressed message size. There appears to be differing opinions if that size includes the TCP 2-byte DNS message length prefix. A suggested alternative would be the sum of the uncompressed RR's in the answer set of the AXFR/IXFR response that implements the zone transfer. - The examples in the document should not include the quotes in the keys. - traffic-volume: - Correct YAML syntax in example. - traffic-sizes: - Why is the '0-15' range not included? They do appear to exist. - The TCP message size should not include the 2-byte length prefix, since that is really a transport header and not part of the DNS message itself. - Buckets with zero counts should be allowed to be ignored and not written to the output YAML file, as is done with the 'rcode-volume' metric. - unique-sources: - Correct example indenting. - Question the usefulness of this metric. It appears to involve more work than it is worth. - General: - Many metrics are written from the viewpoint that they represent a single server. The reality is that all RSOs have multiple sites and servers at each site and the document does not take into account about how metrics are to be merged to form a single value representing all the available values. The method should be specified. - Individual RSOs may wish to make available additional metrics, or alternate versions of the existing metrics. Should we specify a mechanism to support the definition of such metrics?
On Oct 31, 2015, at 12:42 PM, Bruce E. Crabill <bcrabill@umd.edu> wrote:
On Oct 21, 2015, at 12:52 AM, Wessels, Duane <dwessels@verisign.com> wrote:
RSSAC has decided to open the RSSAC-002 "Measurements of the Root Server System" document for revision and is asking the Caucus to produce an update. Based on implementation experience, three minor problems have been identified in the current document.
Hi Bruce,
The following are notes from D-Root on RSSAC002. Some of the comments may have already mentioned by others...
- load-time: - In a system with a large number of sites,there may be a large variance in the time it takes to load specific sites. Should the metric reflect worst case, average, or what? This should be specified so that meaningful comparisons may be be made.
I think the document is pretty clear about this already: Due to the nature of operating anycast DNS clouds there may be multiple steps in the distribution of the Root Zone, dependent on the internal distribution processes at each root-server operator. Additionally the availability of anycasted instances may present as anomalies in measurements and investigators are therefore forewarned. Therefore measurements may only represent the average for 95% of the operationally-active instances of a root server per root zone serial.
- The examples in the document should not include the quotes in the keys.
I see that that the sample YAML for load-time and zone-size do have single quotes around the keys. In my test the parser doesn't complain about this, but I'm happy to suggest they be removed.
- zone-size: - It would be nice if metric was based on something other than a specific implementation's zone traffic compressed message size. There appears to be differing opinions if that size includes the TCP 2-byte DNS message length prefix. A suggested alternative would be the sum of the uncompressed RR's in the answer set of the AXFR/IXFR response that implements the zone transfer.
As we discussed in the in-person caucus meeting yesterday, I think this will be addressed separately from some of these easier errata and simple clarifications.
- The examples in the document should not include the quotes in the keys. - traffic-volume: - Correct YAML syntax in example. - traffic-sizes: - Why is the '0-15' range not included? They do appear to exist.
My guess is that the sample YAML output is from an actual, but short, data collection during which no '0-15' messages were observed. If you think it would be helpful to include something like: 0-15: 1 in the sample YAML, I am happy to support that.
- The TCP message size should not include the 2-byte length prefix, since that is really a transport header and not part of the DNS message itself.
It was the consensus of the in-person caucus meeting that the 2-byte length prefix should be excluded.
- Buckets with zero counts should be allowed to be ignored and not written to the output YAML file, as is done with the 'rcode-volume' metric.
I agree. This is probably implied but could be made explicit.
- unique-sources: - Correct example indenting. - Question the usefulness of this metric. It appears to involve more work than it is worth.
We talked about this during the caucus meeting as well. My opinion is that while it is somewhat tricky, it is still doable and I think the data is useful and interesting.
- General: - Many metrics are written from the viewpoint that they represent a single server. The reality is that all RSOs have multiple sites and servers at each site and the document does not take into account about how metrics are to be merged to form a single value representing all the available values. The method should be specified.
Personally I don't see the need for such specifications, but I'd like to hear others' opinions.
- Individual RSOs may wish to make available additional metrics, or alternate versions of the existing metrics. Should we specify a mechanism to support the definition of such metrics?
That sounds to me like something that would warrant a work party. DW
participants (8)
-
Bruce E. Crabill -
John Bond -
John Heidemann -
P Vixie -
Paul Hoffman -
Ray Bellis -
Romeo Zwart -
Wessels, Duane