Date: Thursday March 28, 10:50-12:20 (Morning session II)
Room: Congress Hall 2
Dave Plonka & Mirja Kühlewind
Pawel Foremski & Oliver Gasser
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 . 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 (Paweł Foremski, , Farsight Security / IITiS PAN,
Oliver Gasser, , Technical University of Munich)
DNS Observatory is a new research project that aims at monitoring the performance and security of the global Domain Name System (DNS). Leveraging a large real-time stream of passive DNS observations, it tracks the world’s top nameservers, domains, IP addresses, and more. Each of these tracked objects is continuously measured using several statistics, including traffic volume, number of successful responses, queried names, returned IP addresses, response delays, etc. The data is aggregated and stored as a time series for visualization, trend analysis, and anomaly detection.
We present a preliminary analysis of the data collected in the DNS Observatory since January 2019, which corresponds to over 1 trillion DNS transactions. We found evidence that 50% of the 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 take >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 IP addresses. Then, we show interesting effects of the Happy Eyeballs algorithm on the DNS. Finally, we assess the resilience of the world’s top nameservers to BGP hijacking attacks, by investigating their support for DNSSEC and RPKI.
EDNS Compliance Status of Resolvers (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”.
QUIC Connection Migration - deployment and results
QUIC connection migration is the feature that allows QUIC connections to survive network changes, such as when a smartphone user walks out of Wi-Fi range into cellular coverage. We will discuss how this feature was deployed in production at Google, and some aggregate numbers showing how it benefits users.
FloodBox: A tool for Measuring the Impact of IP DiffServ Code Point in the Internet
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.
Native SCTP, DCCP, UDP-Lite and Home Gateway NATs
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.