IRTF maprg agenda for IETF-118 (Prague)

Date: Wednesday, 8 November 2023, Session I 0930-1130

Full client with Video:

Room: Congress Hall 2

IRTF Note Well:


Overview and Status - Mirja/Dave (5 min)

QUIC(k) Enough in the Long Run? Sustained Throughput Performance of QUIC Implementations - Roland Bless (10 mins)

Dissecting Performance of Production QUIC - Theo Benson (10 mins)

Using the Spin Bit and ECN with QUIC: Adoption and Challenges in the Wild - Ike Kunze, Constantin Sander (15 mins)

Characterizing open DNS resolver misbehavior for DNSSEC queries - Sudheesh Singanamalla (remote) (15 mins)

Transparent Forwarders: An Unnoticed Component of the Open DNS Infrastructure - Maynard Koch (10 mins)

RoVista: Measuring and Analyzing the Route Origin Validation (ROV) in RPKI - Weitong Li (remote) (15 mins)

Adaptive Address Family Selection for Latency-Sensitive Applications on Dual-stack Hosts - Maxime Piraux (10 mins)

IPv6 Hitlist - Johannes Zirngibl (10 mins)

I Tag, You Tag, Everybody Tags! - Yasir Zaki (remote) (10 mins)


QUIC(k) Enough in the Long Run? Sustained Throughput Performance of QUIC Implementations

Authors: M. König, O. P. Waldhorst and M. Zitterbart


QUIC aims to become a general-purpose transport protocol, and numerous
implementations of the QUIC protocol already exist. Earlier evaluations
often examined QUIC in conjunction with HTTP/3.0 or focused on latency
metrics. The measurement studies in this paper focus on actual QUIC
implementations with respect to their ability to achieve high sustained
throughput in network scenarios with data rates of 10 Gbit/s. We compare
six popular QUIC implementations developed in different programming
languages with TCP. Our findings show significant performance
improvements in several QUIC implementations compared to prior
evaluations. However, it is not a homogeneous picture, as current QUIC
implementations often behave quite differently. We observed that in
environments with low RTTs or an increased number of packet losses, most
of the surveyed QUIC implementations struggle unexpectedly and cannot
compete with TCP regarding sustained throughput performance.


Characterizing open DNS resolver misbehavior for DNSSEC queries

Authors: Sudheesh Singanamalla


Today's Domain Name System (DNS) resolvers are complex systems that often provide service capabilities beyond just translating human readable domain names to resources like IP addresses. Many organizations opt to host their own DNS resolvers, allowing them to comply with regulations through DNS policy-based filtering enforcement. Regardless of the network size, whether intentional or by misconfiguration, many ostensibly internal DNS resolvers are accessible over the public Internet and resolve incoming queries. The presence of these so-called open resolvers across the Internet invites questions as to their correctness, especially in regards to ostensibly secure protocols such as DNSSEC. Over the last couple decades, the DNS community has developed a number of RFC specifications highlighting in detail how DNS resolvers should behave. In this work, we scan the IPv4 address space for open DNS resolvers and record standards specifications violations based on their DNSSEC-based responses.
We present our results from an active scan, and characterize trends in open resolvers over 101 days in 2023 through third party scanner datasets. Surprisingly, we find that 75% of open resolvers respond incorrectly to DNSSEC requests for invalid zones and that 96% of open resolvers return incorrect IP addresses for


Transparent Forwarders: An Unnoticed Component of the Open DNS Infrastructure

Authors: Marcin Nawrocki, Maynard Koch, Thomas C. Schmidt, Matthias Wählisch


In this paper, we revisit the open DNS (ODNS) infrastructure
and, for the first time, systematically measure and analyze transparent
forwarders, DNS components that transparently relay between stub
resolvers and recursive resolvers. Our key findings include four
takeaways. First, transparent forwarders contribute 26% (563k) to the
current ODNS infrastructure. Unfortunately, common periodic scanning
campaigns such as Shadowserver do not capture transparent forwarders and
thus underestimate the current threat potential of the ODNS. Second, we
find an increased deployment of transparent forwarders in Asia and South
America. In India alone, the ODNS consists of 80% transparent
forwarders. Third, many transparent forwarders relay to a few selected
public resolvers such as Google and Cloudflare, which confirms a
consolidation trend of DNS stakeholders. Finally, we introduce
DNSRoute++, a new traceroute approach to understand the network
infrastructure connecting transparent forwarders and resolvers. Ongoing
measurements are available on


Dissecting Performance of Production QUIC

Authors: Theophilus Benson


IETF QUIC, the standardized version of Google’s UDP-based layer-4 network protocol, has seen increasing adoption from large Internet companies for its benefits over TCP. Yet despite its rapid adoption, performance analysis of QUIC in production is scarce. Most existing analyses have only used unoptimized open-source QUIC servers on non-tuned kernels: these analyses are unrepresentative of production deployments which raises the question of whether QUIC actually outperforms TCP in practice.

In this talk, I will discuss one of the first comparative studies on the performance of QUIC and TCP against production endpoints hosted by Google, Facebook, and Cloudflare under various dimensions: network conditions, workloads, and client implementations. First, I will describe a tool we created to systematically visualize and analyze the root causes of performance differences between the two protocols. Then, I will also discuss several key observations that we made using our tool. Taken together, our observations illustrate the fact that QUIC’s performance is inherently tied to implementation design choices, bugs, and configurations which implies that QUIC measurements are not always a reflection of the protocol and often do not generalize across deployments.



Does It Spin? On the Adoption and Use of QUIC’s Spin Bit

Authors: Ike Kunze (RWTH Aachen University), Constantin Sander (RWTH Aachen University), Klaus Wehrle (RWTH Aachen University)


Encrypted QUIC traffic complicates network management as traditional transport layer semantics can no longer be used for RTT or packet loss measurements. Addressing this challenge, QUIC includes an optional, carefully designed mechanism: the spin bit. While its capabilities have already been studied in test settings, its real-world usefulness and adoption are unknown. In this paper, we thus investigate the deployment and utility of the spin bit on the web. Analyzing our long-term measurements of more than 200M domains, we find that the spin bit is enabled on ~10% of those with QUIC support and for 50% / 60% of the underlying IPv4 / IPv6 hosts. The support is mainly driven by medium-sized cloud providers while most hyperscalers do not implement it. Assessing the utility of spin bit RTT measurements, the theoretical issue of reordering does not significantly manifest in our study and the spin bit provides accurate estimates for around 30.5% of connections, but drastically overestimates the RTT for another 51.7%. Overall, we conclude that the spin bit, even though an optional feature, indeed sees use in the wild and is able to provide reasonable RTT estimates for a solid share of QUIC connections, but requires solutions for making its measurements more robust.


ECN with QUIC: Challenges in the Wild

Authors: Constantin Sander (RWTH Aachen University), Ike Kunze (RWTH Aachen University), Leo Blöcher (RWTH Aachen University), Mike Kosek (Technical University of Munich), Klaus Wehrle (RWTH Aachen University)


TCP and QUIC can both leverage ECN to avoid congestion loss and its retransmission overhead. However, both protocols require support of their remote endpoints and it took two decades since the initial standardization of ECN for TCP to reach 80 % ECN support and more in the wild. In contrast, the QUIC standard mandates ECN support, but there are notable ambiguities that make it unclear if and how ECN can actually be used with QUIC on the Internet. Hence, in this paper, we analyze ECN support with QUIC in the wild: We conduct repeated measurements on more than 180 M domains to identify HTTP/3 websites and analyze the underlying QUIC connections w.r.t. ECN support. We only find 20 % of QUIC hosts, providing 6 % of HTTP/3 websites, to mirror client ECN codepoints. Yet, mirroring ECN is only half of what is required for ECN with QUIC, as QUIC validates mirrored ECN codepoints to detect network impairments: We observe that less than 2 % of QUIC hosts, providing less than 0.3 % of HTTP/3 websites, pass this validation. We identify possible root causes in content providers not showing QUIC ECN support and network impairments hindering ECN. We thus also characterize ECN with QUIC distributedly to traverse other paths and discuss our results w.r.t. QUIC and ECN innovations beyond QUIC.


RoVista: Measuring and Analyzing the Route Origin Validation (ROV) in RPKI

Authors: Weitong Li (Virginia Tech), Emile Aben (RIPE NCC), Md. Ishtiaq Ashiq (Virginia Tech), Zhexiao Lin (UC Berkeley), Romain Fontugne (IIJ Research Lab), Taejoong Chung (Virginia Tech), Amreesh Phokeer (ISOC)


The Resource Public Key Infrastructure (RPKI) is a system to add security to the Internet routing. In recent years, the publication of Route Origin Authorization (ROA) objects, which bind IP prefixes to their legitimate origin ASN, has been rapidly increasing. However, ROAs are effective only if the routers use them to verify and filter invalid BGP announcements, a process called Route Origin Validation (ROV).

There are many proposed approaches to measure the status of ROV in the wild, but they are limited in scalability or accuracy. In this paper, we present RoVista, an ROV measurement framework that leverages IP-ID side channel and in-the-wild RPKI-invalid prefix. With over 20 months of longitudinal measurement, RoVista successfully covers more than 28K ASes where 63.8% of ASes have derived benefits from ROV, although the percentage of fully pro- tected ASes remains relatively low at 12.3%. In order to validate our findings, we have also sought input from network operators.

We then evaluate the security impact of current ROV deploy- ment and reveal misconfigurations that will weaken the protection of ROV. Lastly, we compare RoVista with other approaches and conclude with a discussion of our findings and limitations.


Adaptive Address Family Selection for Latency-Sensitive Applications on Dual-stack Hosts

Authors: Maxime Piraux, Olivier Bonaventure (UCLouvain)


Latency is becoming a key factor of performance for Internet
applications and has triggered a number of changes in its protocols. Our
work revisits the impact on latency of address family selection in
dual-stack hosts. Through RIPE Atlas measurements, we analyse the
address families latency differences and establish several observations
based on our findings. First, while the global performance of IPv4 and
IPv6 is balanced, a majority of pairs of source and destination have a
significant difference in latency between IPv4 and IPv6. These
differences are stable for a majority of pairs, but some can experience
no difference or an opposite difference during some time.

The talk will go over these findings and their impact on application
performance given the broad use of Happy Eyeballs. While the paper also
presents an low-latency address family selection technique, I'll briefly
mention this part in the talk to focus on the measurements aspects of
the paper.


IPv6 Hitlist

Authors: Johannes Zirngibl


The ongoing IPv6 Hitlist service [1] is an important source for IPv6
scans. It has been collecting IPv6 address candidates since 2018 and
publishes responsive addresses and aliased prefixes on a regular basis.
While it has not seen major updates for several years, in 2022, it was
cleaned from the impact of the Great Firewall of China, aliased prefixes
were revisited and IPv6 target generation algorithms were applied to
increase the number of responsive addresses by 174% to 8.8M. [2]
In 2023, it was further extended to around 10M responsive addresses and
analyzed regarding the stability over time and its composition in
respect to network categories. [3]
These extensions and new insights support researchers to better scan and
analyze IPv6 (based) deployments on the Internet.

[2] Johannes Zirngibl, Lion Steger, Patrick Sattler, Oliver Gasser, and Georg Carle. 2022. “Rusty Clusters? Dusting an IPv6 Research Foundation”. Internet Measurement Conference
[3] Lion Steger, Liming Kuang, Johannes Zirngibl, Georg Carle, Oliver Gasser. 2023. “Target Acquired? Evaluating Target Generation Algorithms for IPv6”. Network Traffic Measurement and Analysis Conference



Tag, You Tag, Everybody Tags!

Authors: Hazem Ibrahim (New York University Abu Dhabi), Rohail Asim (New York University Abu Dhabi (NYUAD)), Matteo Varvello (Nokia), Yasir Zaki (New York University Abu Dhabi (NYUAD))


Location tags enable tracking of personal belongings. This is achieved locally, e.g, via Bluetooth with a paired phone, and remotely, by piggybacking on the location reported by location-reporting devices which come into proximity of a tag. There has been anecdotal evidence that location tags are also misused to stalk people. This paper studies the performance of the two most popular location tags (Apple's AirTag and Samsung's SmartTag) through controlled experiments -- with a known large distribution of location-reporting devices -- as well as in-the-wild experiments -- with no control on the number and kind of reporting devices encountered, thus emulating real-life use-cases. We find that both tags achieve similar performance, e.g, they are located 55\% of the times in about 10 minutes within a 100 m radius. It follows that real time stalking via location tags is impractical, even when both tags are concurrently deployed which achieves comparable accuracy in half the time. Nevertheless, half of a victim's movements can be backtracked accurately (10 m error) with just a one-hour delay.