After a long day at the Hackathon, the second day started with some exciting meetings. The tutorial for newcomers provides useful information about IETF and associated organizations, the official and unofficial activities during the week and the resources that IETF staff bring to make the best conference possible. Then, the Newcomer's Quick Connections was a space for new attendees to meet experienced people at different WGs. Finally, the IETF fellows dinner with public policy special guests and mentors was a great moment to discuss not only engineering related subjects, but also others that were very interesting as well.

The first-morning session had the WGs: dispatch, 6man, pearg, netconf, netmod, bier, ccamp, emu and ippm. My schedule was focused on documents of pearg and ippm. Nowadays, privacy is a topic that concerns most everyone who uses the Internet. Based on this, the Privacy Enhancements and Assessments Research Group (pearg) showed advances in privacy enhancing technologies for network protocols and distributed systems.

Interesting slides about the Internet-Draft (ID) Guidelines for Performing Safe Measurement on the Internet presented by Iain R. Learmonth opened a discussion about the benefit of using and measuring live Internet traffic against the cost of user's privacy. Iain presented the Tor project as an open network which provides security, privacy, and anonymity according to the key safety principles: data minimalization (minimal details of measured data), source aggregation (sensitive data for short time), and transparency (statistical data publicly available). For all researchers from academia and industry that use Internet measurements, I recommend following this work to ensure that such measurements can be performed safely.

On the other hand, I would also like to highlight the extended ID Registry for Performance Metrics in version 19 in IP Performance Measurement (ippm) WG. This ID is very important considering the role of the performance metrics in IETF protocols and its uses in operational/research measurements. A general guideline is specified for reviewers of registered metrics. It also provides the format for the IANA performance metric registry as well as the criteria for registration, method of measurement category, and the life-cycle of registered performance metrics. It was also followed by the ID Initial Performance Metrics Registry Entries which defines the set of the basic entries for the IANA performance metrics registry including UDP Round-trip Latency and Loss, Packet Delay Variation, among others. For new metrics, this is a good way to standardize the impact of results in other measurements.

Another interesting presentation was the ID Multipoint Alternate Marking method for passive and hybrid performance monitoring which defines a method called Multipoint Alternate Marking to monitor a multipoint-to-multipoint network. Until now the Alternate Marking method has been used in a point-to-point flow considering that all the measured packets on one node are measured again by a single second node. However, a simple algorithm can be used for cluster partition of a graph allowing the measurement of unicast flows without examining it in depth.

On Tuesday, the morning session II had the following WGs: doh, lwig, qirg, bcause, teas, lamps, mile, and tsvwg. In the DNS over HTTPS (DoH) WG were presented the 3 versions of Paul Hoffman’s draft Associating a DoH Server with a Resolver (although he said the draft is a contribution of all community, please if you are interested do not hesitate to contact him or write in the specific DoH mailing list). The draft presents two protocols for a client to identify: the DoH servers associated with the DNS resolvers being used by the operative system, DoH servers from HTTPS and DoH servers from DNS. This allows better DNS response times to get the URI templates or addresses of these servers.

One of the most active WG in the operations and management area was DNS operations (DNSOP). The Tuesday afternoon session presented advances for the 6 drafts at the DNSOP WG. The first draft was Multi-Provider DNSSEC models which presented multiple models that may be suitable for deploying DNSSEC in zones simultaneously signed by multiple DNS providers. The advances are focused on the Pros and Cons section that compares the 2 models, fleshing out the inter-provider handoff section and explaining how CDS and CDNSKEY use works in these models.

The second draft was Running a Root Server Local to a Resolver. This draft is a guide to start and maintain such a copy of the root zone in a DNS recursive resolver, with the aim of decreasing the round-trip time, providing more reliable answers for queries to the root zone during network attacks and preventing requests from being observed. The advances were updated from examples and goals, but it is missing more examples of future root zone data providers.

The third draft was the DNS Transport over TCP - Operational Requirements, which encourages the use of TCP as the transport protocol for DNS messages, analyzing the consequences and the operational issues. Currently, the actions of the internet community in the past DNS Flag day 2019 contribute to deal with large responses to DNS requests. If you are interested in the cooperation of the IETF community and the operational world, you can find more information about the next DNS Flagday 2020 here.

The fourth presentation is the combination of two-related drafts, Responsibility for Authoritative DNS and DNSSEC Mistakes and In Case of DNSSEC Validation Failures, Do Not Change Resolvers. Both drafts are new and motivated by a pattern of observation over a long period of time in the DNS operational world. The first draft discussion revolved around how recursive DNS operators get blamed for the mistakes made by authoritative DNS providers. This is based on DNSSEC validation failures caused by a bad/missing authoritative DNS RR. The second draft discussion was about a security downgrade and the risks for users when a DNSSEC validation fails and switch to a non-validating resolver to access the content. Comments on this presentation were positive and others are looking forward to seeing a recommendation or examples to mitigate errors, for instance, TTL configuration.

The fifth was a draft to analyze the YANG module iana-dns-class-rr-type which defines two IANA registries as YANG derived types, DNS classes, and resource record types. An enumeration of mnemonic names and a numeric reference are advantages of the YANG derived types.

On Wednesday morning the IETF technical fellows and IETF policy fellows met to share ideas on how to improve the IETF meeting in general and share experiences about the cooperation from all sectors around the Internet. In the afternoon, the IETF plenary session started with laughs and a useful guide to maximize the time in Prague. Then, the incoming and outgoing people of the different roles in the IETF, acknowledgment to outstanding people according to their contributions and news about the next meetings were presented.

On Thursday morning there was space for the research groups to gather. The IRTF had 3 sessions: Path Aware Networking RG (panrg), Computing in the Network Proposed Research Group (coinrg) and Measurement and Analysis for Protocols (maprg). The maprg schedule had 5 presentations based on research measurements. The first work was the Micro Dependability Measurements, global measurement of the inter-domain dependability in a research network. The goals of the measurements are to study the end-to-end quality of traffic, the micro dependability of routing and interaction with network operations to diagnose problems. In the following figure number 1, the results show a high volume of network outages and the way to infer the reasons as to why this happens are proposed by methods using aggregation and visualization techniques.

The second work presented the performance of web protocols over satellite links. The goals of the active measurements are the One-way delay, bulk data transfers, page load times in the 2 current versions of HTTP (1.1 and 2) HTTP/TCP, HTTP/TCP in OpenVPN UDP tunnels and QUIC. The method used included deploying VPN tunnels to disable and enable Performance Enhancement Proxies (PEPs) to split TCP. The tests were performed with three operators across Europe, without IPv6 support. The results in figure 2 show HTTP over TCP traffic benefits from PEPs. Also, there is a clear difference between the operators as shown in figure number 3, even in large websites.

 

The third work was the DNS Observatory. A project to monitor the performance and security of the global Domain Name System (DNS). The goal of the passive measurements is the analysis of the traffic volume, response codes, returned IP addresses, queried names, delays, among others. The results can be observed in figure number 4: approx. 50% of the world’s DNS traffic is likely handled by just <1k nameservers located in <10 networks. Additionally, the performance of DNS resolution is affected when many resolvers have to cross continents to reach a DNS zone authority, that means more reliability on the anycast solutions.

The next presentation was a work developed in NIC Research Labs Chile, the work EDNS Compliance Status of Resolvers is an algorithm to monitor the EDNS compliance and support of multiple extensions. The algorithm is based on the I-D “A Common Operational Problem in DNS Servers”. The goals of the measurements were to test the EDNS support and to make a comparison between the DNS resolvers state before and after DNS Flag day 2019. The algorithm processes flags and response codes in the answer section to classify the resolver status. In figure number 5 the minimal EDNS compliance is compared. The overall results show a 40% increase in the expected response codes and flags after DNS Flag day 2019.

The fifth work was Floodbox, A tool for Measuring the Impact of IP DiffServ Code Point in the Internet. Floodbox was developed to measure the impact that end systems perceive when they set the DiffServ Code Point (DSCP) to a specific value without any prior agreement. The goal is to understand the performance evaluation of a specific code point with best effort code point CS0, after the congestion produced in the network path via traffic floods. The results in figure number 6 show that 2% of the routers of more than 100,000 links differentiate between the WebRTC DSCP values (EF, AF42 and CS1) and reduce delay in comparison with probes carrying a CS0.

In general, I found the IETF meeting similar to a real community, where everyone contributes to reach a better Internet. I would like to emphasize how the work environment allows the sharing and improving ideas, not only in the hackathon .. you can see people coding all days in different spaces. I would like to thanks the DNS experts for the feedback about my research and the support to my advisors Sandra Céspedes and Javier Bustos to achieve this objective.

Thanks for the edition to María José Vilches.