[rssac-caucus] REMINDER FOR REVIEW: Version 3 of RSSAC002 - Measurements of Root Server System

[George Michaelson]

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 at 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 at icann.org> on behalf of Steve Sheng <
> steve.sheng at icann.org>
> *Date: *Wednesday, May 11, 2016 at 2:59 AM
> *To: *"rssac-caucus at icann.org" <rssac-caucus at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20160518/27699e2f/attachment.html>