Re: [rssac-caucus] REMINDER FOR REVIEW: Version 3 of RSSAC002 - Measurements of Root Server System
you know I was a little terse: I'll try again. TCP happens because people can't get answers in UDP. UDP frags from the server response happen when the interface MTU drives below the size of the response packet in UDP. Firewalls block UDP frags. This leads to re-requests in UDP with either no EDNS0 or EDNS size 512 which drives to TC=1 In IPv6, tunnels cause pMTU ICMP which (along with other ICMP) is blocked. It gets bad. Its assymetric. If we know the root server MTU, we understand to what extent large response serve and UDP serve might be influenced by UDP->IP->Frag outcomes. If it's a static value, across all nodes, invariant, it makes no sense to report in 002: Just declare what it is, and we can move on. If its variant, then the information about whats happening in the IP layer(s) necessarily needs to understand the MTU to be complete. We can't intuit all TCP to one cause, we need to understand all the underlying causes. Thats my motivation for asking for MTU information, in 002, or elsewhere. Oh, I should add: TCP/UDP offload onto cards plays in the space too, as does the kernel (duh) so understanding that the platform uses smart cards, and if its BSD or Linux (because they tune Ip differently) matters too. -George On 18 May 2016 at 06:16, Steve Sheng <steve.sheng@icann.org> wrote:
Dear RSSAC Caucus,
This is a reminder to submit your review of this document by close of business *27 May 2016. *
Best
Steve
*From: *<rssac-caucus-bounces@icann.org> on behalf of Steve Sheng < steve.sheng@icann.org> *Date: *Wednesday, May 11, 2016 at 2:59 AM *To: *"rssac-caucus@icann.org" <rssac-caucus@icann.org> *Subject: *[rssac-caucus] FOR REVIEW: Version 3 of RSSAC002 - Measurements of Root Server System
Dear RSSAC Caucus,
On behalf of the work party to revise RSSAC002, attached please find v3 of RSSAC002 – Measurements of the Root Server System.
The work party was created by RSSAC on 4 February 2016 with the following scope of work: https://www.icann.org/en/system/files/files/rssac-002-scope-04feb16-en.pdf .
The work party met every other week for the last three months and revised RSSAC002. The major changes are:
- Added section 2 "Scope of Measurements" and tried to improve scope and rationales throughout the document. - 'load-time' is now defined as a strict 95th percentile. - although 'load-time' is reported as seconds, we note that it should not be assumed to have such accuracy. - for 'zone-size' metric, now only the Root Zone Maintainer should report this. - clarified definitions of responses in traffic-volume metric - for traffic-volume, included some discussion on why queries and responses might differ - clarified definition of RCODE measurements. In particular it is only for responses sent FROM the root server (not TO the server). - for 'num-sources' only count messages sent TO the server. - in section 4 rewrote the paragraph stating that TCP reassembly is non-trivial and therefore including data from DNS-over-TCP is optional. - removed 'end-period' from YAML. All measurements cover a 24 hour period and the start time is sufficient. - Added a version keyword to YAML files. - Described a YAML format that allows operators to publish custom metrics - Updated examples to be real operator statistics
The work party invites you to review this document and provide your feedback by close of business *27 May 2016. *
Feedbacks should be sent to the caucus list directly.
Best
Steve
On 2016-05-17 20:39, George Michaelson wrote:
UDP frags from the server response happen when the interface MTU drives below the size of the response packet in UDP.
But isn't this true for every networking device along the path? If the MTU is too low, the packet get fragmented (v4) or discarded (v6)?
Firewalls block UDP frags.
And home routers / nats.
Oh, I should add: TCP/UDP offload onto cards plays in the space too, as does the kernel (duh) so understanding that the platform uses smart cards, and if its BSD or Linux (because they tune Ip differently) matters too.
Smart cards for me is something else, but I may have DNSSEC tattooed on my forehead next time you see me ;-) How does offloading onto hardware play a role? -- Robert Martin-Legene Internet Infrastructure Specialist Packet Clearing House
On 18/05/2016 00:39, George Michaelson wrote:
If it's a static value, across all nodes, invariant, it makes no sense to report in 002: Just declare what it is, and we can move on.
If its variant, then the information about whats happening in the IP layer(s) necessarily needs to understand the MTU to be complete. We can't intuit all TCP to one cause, we need to understand all the underlying causes.
Thats my motivation for asking for MTU information, in 002, or elsewhere.
George, This sounds like an interesting research question. However IMHO it's completely out of scope for 002. kind regards, Ray
participants (3)
-
George Michaelson -
Ray Bellis -
Robert Martin-Legene