Due to its large address space, IPv6 remains a challenge for Internet measurements. Thus, IPv6 scans often resort to hitlists that, however, mainly cover core Internet infrastructure and servers. Contrarily, a recent approach to source addresses leveraging NTP servers promises to discover more user-related hosts. Yet, an in-depth analysis of hosts found by this approach is missing and its impact remains unclear.

Internet congestion management is once again undergoing radical change: QUIC has ignited a cambrian explosion in congestion control (CC) implementations while the many versions of BBR alone have increased the diversity in algorithms used with TCP, both making the congestion landscape more complex. At the same time, the interplay of CC and AQM is also evolving but congestion unresponsiveness remains a threat. In particular, L4S crucially requires a fine-grained CC and AQM interaction to provide its benefits and suffers from unresponsive traffic. Overall, we need more responsive traffic on the Internet as well as mechanisms that can cope with unresponsiveness. We present Congestion-Responsive Queuing (CRQ), our L4S-inspired system which is designed to promote responsive CC, manage unresponsive traffic, and handle QUIC and TCP flows alike. Similar to L4S, CRQ uses two queues for flow isolation. Yet, in contrast to L4S, we isolate flows based on their actual congestion responsiveness, moving responsive flows to one queue and leaving the remaining flows in the other. Our evaluation with an eBPF prototype highlights the efficacy of our design and shows that CRQ can provide effective incentives for responsive CC.

The resilience of the Internet to high traffic loads fundamentally relies on hosts responding to congestion, i.e., that they back off when the network is overloaded. Despite the corresponding wide-spread deployment of congestion control, unresponsive hosts still represent a danger and can wipe out all benefits of modern congestion management approaches, such as L4S. Hence, identifying (and isolating) unresponsive flows can contribute to improving the Internet’s resilience. Yet, existing approaches only provide broad or probabilistic solutions which become inapplicable with QUIC or also harm benign traffic.In this paper, we propose SpinTrap, a speed trap for Internet flows designed to identify unresponsive traffic. Leveraging the QUIC spin bit, SpinTrap first monitors the sending behavior of QUIC flows before assessing their congestion responsiveness by checking for reduced sending rates as reaction to congestion signals (packet loss and ECN markings). Evaluating our eBPF prototype, we show that SpinTrap can accurately track the sending rates and assess the responsiveness of QUIC traffic, singling out flows that do not react to congestion. As such, SpinTrap provides a novel building block for Internet congestion management that can help in improving the Internet’s resilience.

Containerization allows bundling applications and their dependencies into a single image. The containerization framework Docker eases the use of this concept and enables sharing images publicly, gaining high momentum. However, it can lead to users creating and sharing images that include private keys or API secrets—either by mistake or out of negligence. This leakage impairs the creator’s security and that of everyone using the image. Yet, the extent of this practice and how to counteract it remains unclear.

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 spin bit's deployment and utility on the web.

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 supporting ECN via QUIC 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.

HTTP/2 and HTTP/3 avoid concurrent connections but instead multiplex requests over a single connection. Besides enabling new features, this reduces overhead and enables fair bandwidth sharing. Redundant connections should hence be a story of the past with HTTP/2. However, they still exist, potentially hindering innovation and performance. Thus, we measure their spread and analyze their causes in this paper. We find that 36% - 72% of the 6.24 M HTTP Archive and 78% of the Alexa Top 100k websites cause Chromium-based webbrowsers to open superfluous connections. We mainly attribute these to domain sharding, despite HTTP/2 efforts to revert it, and DNS load balancing, but also the Fetch Standard.