Date: Thursday March 28, 10:50-12:20 (Morning session II)
Room: Congress Hall 2
Dave Plonka & Mirja Kühlewind
10 min
Olav Kvittem
5 mins
Joerg Deutschmann
10 mins
Pawel Foremski & Oliver Gasser
15 min
Jeisson Sánchez
15 min
Runa Barik
15 min
Runa Barik
10 min
Cherie Shi
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.
Website:
https://in.uninett.no/dragonlab/
Talk:
https://uninett.box.com/s/er5n0niqzkbxbbepx2ykifghee3332ti
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).
[1] www7content.cs.fau.de/~deutschmann/NetSys2019_preprint.pdf
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
(Cherie Shi)
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
(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.
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.