Measurement and Analysis for Protocols Research Group (maprg) Agenda at IETF-104 (Prague)

Date: Tuesday March 28, 10:50-12:20 (Morning session II)
Room: Congress Hall 2

Overview & Hackathon Report

Dave Plonka & Mirja Kühlewind
15 min

Heads-up talk: Micro Dependability Measurements

Olav Kvittem
5 mins

Performance of web protocols over satellite links

Joerg Deutschmann
10 mins

DNS Observatory: Monitoring Global DNS for Performance and Security

Pawel Foremski
20 min


Jeisson Sánchez
15 min

Native SCTP, DCCP, UDP-Lite and Home Gateway NATs

Runa Barik
15 min

FloodBox: A tool for Measuring the Impact of IP DiffServ Code Point in the Internet

Runa Barik
10 min


Micro Dependability Measurements (Olav Kvittem)

We have conducted a small scale end to end inter domain micro dependability measurement covering about 10 sites in 3 continents. These measurements show an alarming high volume of network outages that obviously are hitting our day to day network use. The measurements are high resolution and show a high number of small outages. We are working on methods to infer what the cause of the outages are using aggregation and visualization techniques. I want to present this to MAPRG to get feedback on the methods, the results and how to proceed. How we can cooperate to facilitate such measurements on a bigger scale and how to understand where the problems are in operating an inter domain network like The Internet.


Performance of web protocols over satellite links (Joerg Deutschmann)

We will present the performance of web protocols over satellite links. This includes HTTP(S)/1.1, HTTP/2, and QUIC. Using VPN tunnels allows us to disable and enable Performance Enhancement Proxies (PEPs). All tests were run with three different satellite internet providers, showing quite some differences.

The results are based on an accepted NetSys 2019 paper [1]. Nicolas Kuhn already presented the principle problem of QUIC over satellite links at the previous IETF103 meeting. Our results complement these findings; therefore a time slot of 10min would be sufficient (if you are on a very tight schedule, we might also squeeze it into a 5min time slot).


DNS Observatory: Monitoring Global DNS for Performance and Security (Pawel Foremski)

DNS Observatory is a new research project by Farsight Security that aims at monitoring the performance, content, and security of the global DNS. Leveraging a stream of 200k passive DNS observations per second, it tracks the world’s top nameservers, domains, IP addresses, and other phenomena. Each tracked object is continuously measured in 1-minute time windows using several statistics, including traffic volume, number of successful responses, distinct query names, returned IPs, median response delay, and more. The data is aggregated into larger time windows and stored as time series for visualization, trend analysis, and anomaly detection.

We present a preliminary analysis of the data collected since January 2019, which corresponds to over 1 trillion DNS transactions. We found evidence that 50% of world’s DNS traffic is likely handled by just <1k nameservers located in <10 networks. From the performance point of view, although most servers respond in <25ms, one in five needs >100ms, which suggests that many resolvers need to cross an ocean to reach a DNS zone authority. However, popular servers seem to be located closer to the resolvers, which leads to generally good performance of the world’s most busy servers.

In addition, we present a few case studies. First, we find and visualize trends in traffic volume, response delays, and other statistics - for select nameservers, domains, and IPs. Then, we show interesting effects of the IPv6 Happy Eyeballs algorithm on the DNS. Finally, we analyze the resilience of the world’s top nameservers to BGP hijacking attacks.

TBD (Jeisson Sánchez)

A novel algorithm based on a DNS query/response with different options to tests EDNS status support and to make a comparison between the DNS resolvers state before and after DNS Flag day. The tests are EDNS compliance and support of the extensions DNSSEC, EDNS-Client Subnet (ECS), Chain Query requests in DNS, DNS cookies, EDNS-Expire Option, Edns-Tcp-Keepalive Option, among others. The main contribution is a map of the discovery support of each extension in resolvers. For instance, RFC 7901 (Chain Query request in DNS) specifies the discovery of Chain query support in resolvers to complete a correct operation of DNSSEC client validation.

The algorithm processes the flags and response codes in answer section to classify the resolver status. The first one is a normal DNS operation with extensions, the second one is a normal DNS operation but with some extensions errors and the third one is a normal DNS operation without support to extensions. The algorithm was tested with approximately 20000 Chilean resolvers. The results shows an important advance after 1st of February. Each one of the results has a reason of the diagnostic according to intended best current practice “A Common operational Problem in DNS Servers”.

Native SCTP, DCCP, UDP-Lite and Home Gateway NATs (Runa Barik)

TCP and basic UDP support by NATs are already well studied. Supporting mechanisms (e.g. TAPS transport systems) that flexibly test a protocol and fall back to a default behavior in case of failure, in this talk, we present the results from a controlled experiment to observe the behavior of NATs from several vendors as well as the Linux (version 3.18.109 for MIPS architecture) and FreeBSD (the three different firewall variants: IPF, PF and IPFW) kernels with different transport protocols: SCTP, DCCP, and UDP-Lite. Some of our findings may be surprising, as they contradict common views such as "SCTP never works through a NAT". We also propose a simple alternative approach to support SCTP multi-homing with the existing Linux and FreeBSD NAT code. The study also reveals the end-to-end transparency of UDP with a zero checksum as an alternative to UDP-Lite.

FloodBox: A tool for Measuring the Impact of IP DiffServ Code Point in the Internet (Runa Barik)

DiffServ was designed to implement service provider quality of service (QoS) policies, where routers change and react upon the DiffServ Code Point (DSCP) in the IP header. However, nowadays, applications, for example WebRTC, are beginning to directly set the DSCP themselves, in the hope that this will yield a more appropriate service for their respective video, audio and data streams. In this talk, we present a tool called FloodBox to measure the impact that end systems perceive when they set the DSCP to a specific value without any prior agreement. The FloodBox, our extension of TraceBox, produces congestion in the network path via traffic floods and while the path is congested, we evaluate the performance of a specific code point with best effort code point CS0. Our study reveals that routers at approximately 2% of more than 100,000 links differentiate between the WebRTC DSCP values (EF, AF42 and CS1) and consistently and notably reduce delay in comparison with probes carrying a CS0. In contrast, routers at around 1% of these links increase the delay by a comparable amount, uniformly for EF, AF42 and CS1.