May 2016 - rssac-caucus - lists.icann.org

[rssac-caucus] REMINDER FOR REVIEW: Version 3 of RSSAC002 - Measurements of Root Server System
by Steve Sheng June 1, 2016

June 1, 2016

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(a)icann.org> on behalf of Steve Sheng <steve.sheng(a)icann.org> Date: Wednesday, May 11, 2016 at 2:59 AM To: "rssac-caucus(a)icann.org" <rssac-caucus(a)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

1 1

[rssac-caucus] News ed Offerte Geek! Sempre aggiornati!
by GeekMail di Mrhost.it May 27, 2016

May 27, 2016

Entice the open with some amazing preheader text. Use a little mystery and get those subscribers to read through... https://mrhost.it https://mrhost.it/blog/eventi-domini/hai-un-dominio-eu-partecipa-anche-tu-a… MrHost.it La nuova Generazione di Hosting! https://mrhost.it/mydomainchecker.php Prova il nostro Hosting GRATIS! Prova il nostro piano Hosting Start 1 Gratis per 1 anno! Registra un dominio (ci sono domini in offerta a partire da 1 euro) ed inserisci anche il piano START 1 nel carrello è pagalo con questo coupon 1X1PROMO465 l'importo del piano START 1 sarà completamente rimosso dal carrello! Prova subito, clicca sull'immagine sceglie il dominio ed inserisci il codice coupone per l'hosting gratis!! https://mrhost.it/registra-dominio-site.php Dominio .SITE a EUR 9.40 Il nuovo dominio disponibile a tutti e per qualsiasi cosa . Accessibile a clienti di tutto il mondo,porta a un migliore branding, facile da cercare e ricordare.. https://mrhost.it/registra-dominio-top.php Offerta Dominio .TOP Super promozione per i domini .TOP ad 1EUR. TOP OF THE WORLD! .TOP È un vero e proprio dominio generico di nuova generazione. Con un nome a dominio .TOP, chiunque in tutto il mondo avra l'opportunità di possedere un "pezzo di Internet" facile da cercare e ricordare. HAI UN DOMINIO .EU? Partecipa anche tu ai Web Awards, che premiano il miglior dominio europeo! Da due anni a questa parte, EURID, il registry ufficiale dell'Unione Europea che si occupa della registrazione dei domini .eu indice, per il periodo estivo, un concorso che premia il miglior sito .eu tra quelli partecipanti. Leggi Articolo → https://mrhost.it/blog/eventi-domini/hai-un-dominio-eu-partecipa-anche-tu-a… GeekConcept Via Castellaccio 135, 40041 Gaggio Montano (BO) +39.051.0549333 Unsubscribe http://geekmail.it/index.php/lists/kp052y4rkh898/unsubscribe/co0851fd79af2/… | Visualizza Emal in Browser http://geekmail.it/index.php/campaigns/bc479z1mgkc01/web-version/co0851fd79… Servzio di GeekMail.it

1 0

[rssac-caucus] Honored to join the RSSAC Caucus
by Mahdi Taghizadeh May 26, 2016

May 26, 2016

Hi all! I'm very happy to join the RSSAC Caucus and hope to contribute more and more and learn from each of you. Cheers! *Mahdi Taghizadeh* *More at mahdi.ws <http://mahdi.ws>* *PGP at keybase.io/mahdi <http://keybase.io/mahdi>*

1 0

Re: [rssac-caucus] REMINDER FOR REVIEW: Version 3 of RSSAC002 - Measurements of Root Server System
by George Michaelson May 18, 2016

May 18, 2016

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(a)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(a)icann.org> on behalf of Steve Sheng < > steve.sheng(a)icann.org> > *Date: *Wednesday, May 11, 2016 at 2:59 AM > *To: *"rssac-caucus(a)icann.org" <rssac-caucus(a)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 > > >

3 2

Re: [rssac-caucus] REMINDER FOR REVIEW: Version 3 of RSSAC002 - Measurements of Root Server System
by George Michaelson May 17, 2016

May 17, 2016

since interface MTU is a fundamental driver of the response size, and the TC=1 outcome, I repeat a request I sent in a direct mail: can we get a formalized response from the operators of the MTU setting they use, so that we can understand the resulting impact on IPv4 and IPv6 fragmentation, and on implied UDP sizes, and TC=1 outcomes. -G On 18 May 2016 at 06:16, Steve Sheng <steve.sheng(a)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(a)icann.org> on behalf of Steve Sheng < > steve.sheng(a)icann.org> > *Date: *Wednesday, May 11, 2016 at 2:59 AM > *To: *"rssac-caucus(a)icann.org" <rssac-caucus(a)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 > > >

1 0

[rssac-caucus] FOR REVIEW: Version 3 of RSSAC002 - Measurements of Root Server System
by Steve Sheng May 10, 2016

May 10, 2016

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

1 0

[rssac-caucus] RSSAC Caucus Meeting at IETF 96
by Carlos Reyes May 6, 2016

May 6, 2016

Dear RSSAC Caucus, As a reminder there will be an RSSAC Caucus meeting at IETF 96 in Berlin, Germany. This keeps with the schedule of convening the RSSAC Caucus at every other IETF meeting. More details about the agenda, exact date, time and room for the meeting will follow. Please do not hesitate to suggest potential agenda items on the mailing list as well. Regards, Carlos On Behalf of RSSAC Co-Chairs Tripti Sinha and Brad Verd Carlos Reyes | Policy and Community Engagement Manager carlos.reyes(a)icann.org | +1 (202) 802-8019 ICANN | Internet Corporation for Assigned Names and Numbers 801 17th Street NW, Suite 400 | Washington, DC 20006

1 0

[rssac-caucus] Can we get the MTU/MSS for the roots?
by George Michaelson May 4, 2016

May 4, 2016

It would be informative to understand what interface MTU the hosts providing DNS use, in the roots. This is not to suggest there has to be a defined one, but it would help understand how people interact in the UDP/TCP shift under TC=1, because of the lack of ICMP/ICMPv6 signal (ICMP filters) and the effect of the server-side in TCP setting a lower MSS avoiding the problem. Could the caucus act as a channel to get this data? -George

1 0