SearcharxivSearch

arXiv subjects

Jan Rüth

Publications and source records attributed to Jan Rüth.

16 recordsLinked to original sources

Tracking the QUIC Spin Bit on Tofino

QUIC offers security and privacy for modern web traffic by closely integrating encryption into its transport functionality. In this process, it hides transport layer information often used for network monitoring, thus obsoleting traditional measurement concepts. To still enable passive RTT estimations, QUIC introduces a dedicated measurement bit - the spin bit. While simple in its design, tracking the spin bit at line-rate can become challenging for software-based solutions. Dedicated hardware trackers are also unsuitable as the spin bit is not invariant and can change in the future. Thus, this paper investigates whether P4-programmable hardware, such as the Intel Tofino, can effectively track the spin bit at line-rate. We find that the core functionality of the spin bit can be realized easily, and our prototype has an accuracy close to software-based trackers. Our prototype further protects against faulty measurements caused by reordering and prepares the data according to the needs of network operators, e.g., by classifying samples into pre-defined RTT classes. Still, distinct concepts in QUIC, such as its connection ID, are challenging with current hardware capabilities.

cs.NI

Sharding and HTTP/2 Connection Reuse Revisited: Why Are There Still Redundant Connections?

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.24M 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.

cs.NI

Video Conferencing and Flow-Rate Fairness: A First Look at Zoom and the Impact of Flow-Queuing AQM

Congestion control is essential for the stability of the Internet and the corresponding algorithms are commonly evaluated for interoperability based on flow-rate fairness. In contrast, video conferencing software such as Zoom uses custom congestion control algorithms whose fairness behavior is mostly unknown. Aggravatingly, video conferencing has recently seen a drastic increase in use - partly caused by the COVID-19 pandemic - and could hence negatively affect how available Internet resources are shared. In this paper, we thus investigate the flow-rate fairness of video conferencing congestion control at the example of Zoom and influences of deploying AQM. We find that Zoom is slow to react to bandwidth changes and uses two to three times the bandwidth of TCP in low-bandwidth scenarios. Moreover, also when competing with delay aware congestion control such as BBR, we see high queuing delays. AQM reduces these queuing delays and can equalize the bandwidth use when used with flow-queuing. However, it then introduces high packet loss for Zoom, leaving the question how delay and loss affect Zoom's QoE. We hence show a preliminary user study in the appendix which indicates that the QoE is at least not improved and should be studied further.

cs.NI

L, Q, R, and T -- Which Spin Bit Cousin Is Here to Stay?

Network operators utilize traffic monitoring to locate and fix faults or performance bottlenecks. This often relies on intrinsic protocol semantics, e.g., sequence numbers, that many protocols share implicitly through their packet headers. The arrival of (almost) fully encrypted transport protocols, such as QUIC, significantly complicates this monitoring as header data is no longer visible to passive observers. Recognizing this challenge, QUIC offers explicit measurement semantics by exposing the spin bit to measure a flow's RTT. Ongoing efforts in the IETF IPPM working group argue to expose further information and enable the passive quantification of packet loss. This work implements and evaluates four currently proposed measurement techniques (L-, Q-, R-, and T-bit). We find that all techniques generally provide accurate loss estimations, but that longer algorithmic intervals for Q and R, yet foremost for T, complicate detecting very small loss rates or loss on short connections. Deployment combinations of Q & R as well as Q & L, thus, have the best potential for accurately grasping the loss in networks.

cs.NI

MUST, SHOULD, DON'T CARE: TCP Conformance in the Wild

Standards govern the SHOULD and MUST requirements for protocol implementers for interoperability. In case of TCP that carries the bulk of the Internets' traffic, these requirements are defined in RFCs. While it is known that not all optional features are implemented and nonconformance exists, one would assume that TCP implementations at least conform to the minimum set of MUST requirements. In this paper, we use Internet-wide scans to show how Internet hosts and paths conform to these basic requirements. We uncover a non-negligible set of hosts and paths that do not adhere to even basic requirements. For example, we observe hosts that do not correctly handle checksums and cases of middlebox interference for TCP options. We identify hosts that drop packets when the urgent pointer is set or simply crash. Our publicly available results highlight that conformance to even fundamental protocol requirements should not be taken for granted but instead checked regularly.

cs.NI

Perceiving QUIC: Do Users Notice or Even Care?

QUIC, as the foundation for HTTP/3, is becoming an Internet reality. A plethora of studies already show that QUIC excels beyond TCP+TLS+HTTP/2. Yet, these studies compare a highly optimized QUIC Web stack against an unoptimized TCP-based stack. In this paper, we bring TCP up to speed to perform an eye-level comparison. Instead of relying on technical metrics, we perform two extensive user studies to investigate QUIC's impact on the quality of experience. First, we investigate if users can distinguish two protocol versions in a direct comparison, and we find that QUIC is indeed rated faster than TCP and even a tuned TCP. Yet, our second study shows that this perceived performance increase does mostly not matter to the users, and they rate QUIC and TCP indistinguishable.

cs.NI

DeePCCI: Deep Learning-based Passive Congestion Control Identification

Transport protocols use congestion control to avoid overloading a network. Nowadays, different congestion control variants exist that influence performance. Studying their use is thus relevant, but it is hard to identify which variant is used. While passive identification approaches exist, these require detailed domain knowledge and often also rely on outdated assumptions about how congestion control operates and what data is accessible. We present DeePCCI, a passive, deep learning-based congestion control identification approach which does not need any domain knowledge other than training traffic of a congestion control variant. By only using packet arrival data, it is also directly applicable to encrypted (transport header) traffic. DeePCCI is therefore more easily extendable and can also be used with QUIC.

cs.NI

A Performance Perspective on Web Optimized Protocol Stacks: TCP+TLS+HTTP/2 vs. QUIC

Existing performance comparisons of QUIC and TCP compared an optimized QUIC to an unoptimized TCP stack. By neglecting available TCP improvements inherently included in QUIC, comparisons do not shed light on the performance of current web stacks. In this paper, we can show that tuning TCP parameters is not negligible and directly yields significant improvements. Nevertheless, QUIC still outperforms even our tuned variant of TCP. This performance advantage is mostly caused by QUIC's reduced RTT design during connection establishment, and, in case of lossy networks due to its ability to circumvent head-of-line blocking.

cs.NI

An Empirical View on Content Provider Fairness

Congestion control is an indispensable component of transport protocols to prevent congestion collapse. As such, it distributes the available bandwidth among all competing flows, ideally in a fair manner. However, there exists a constantly evolving set of congestion control algorithms, each addressing different performance needs and providing the potential for custom parametrizations. In particular, content providers such as CDNs are known to tune TCP stacks for performance gains. In this paper, we thus empirically investigate if current Internet traffic generated by content providers still adheres to the conventional understanding of fairness. Our study compares fairness properties of testbed hosts to actual traffic of six major content providers subject to different bandwidths, RTTs, queue sizes, and queueing disciplines in a home-user setting. We find that some employed congestion control algorithms lead to significantly asymmetric bandwidth shares, however, AQMs such as FQ_CoDel are able to alleviate such unfairness.

cs.NI

Blitz-starting QUIC Connections

In this paper, we revisit the idea to remove Slow Start from congestion control. To do so, we build upon the newly gained freedom of transport protocol extendability offered by QUIC to hint bandwidth estimates from a typical web client to a server. Using this bandwidth estimate, we bootstrap congestion windows of new connections to quickly utilize available bandwidth. This custom flow initialization removes the common early exit of Slow Start and thus fuels short flow fairness with long-running connections. Our results indicate that we can drastically reduce flow completion time accepting some losses and thereby an inflated transmission volume. For example, for a typical DSL client, loading a 2 MB YouTube video chunk is accelerated by nearly 2x. In the worst case, we find an inflation of the transfer volume by 12% due to losses.

cs.NI

Application-Agnostic Offloading of Packet Processing

As network speed increases, servers struggle to serve all requests directed at them. This challenge is rooted in a partitioned data path where the split between the kernel space networking stack and user space applications induces overheads. To address this challenge, we propose Santa, a new architecture to optimize the data path by enabling server applications to partially offload packet processing to a generic rule processor. We exemplify Santa by showing how it can drastically accelerate kernel-based packet processing - a currently neglected domain. Our evaluation of a broad class of applications, namely DNS, Memcached, and HTTP, highlights that Santa can substantially improve the server performance by a factor of 5.5, 2.1, and 2.5, respectively.

cs.NI

A First Look at QUIC in the Wild

For the first time since the establishment of TCP and UDP, the Internet transport layer is subject to a major change by the introduction of QUIC. Initiated by Google in 2012, QUIC provides a reliable, connection-oriented low-latency and fully encrypted transport. In this paper, we provide the first broad assessment of QUIC usage in the wild. We monitor the entire IPv4 address space since August 2016 and about 46% of the DNS namespace to detected QUIC-capable infrastructures. Our scans show that the number of QUIC-capable IPs has more than tripled since then to over 617.59 K. We find around 161K domains hosted on QUIC-enabled infrastructure, but only 15K of them present valid certificates over QUIC. Second, we analyze one year of traffic traces provided by MAWI, one day of a major European tier-1 ISP and from a large IXP to understand the dominance of QUIC in the Internet traffic mix. We find QUIC to account for 2.6% to 9.1% of the current Internet traffic, depending on the vantage point. This share is dominated by Google pushing up to 42.1% of its traffic via QUIC.

cs.NI

Characterizing a Meta-CDN

CDNs have reshaped the Internet architecture at large. They operate (globally) distributed networks of servers to reduce latencies as well as to increase availability for content and to handle large traffic bursts. Traditionally, content providers were mostly limited to a single CDN operator. However, in recent years, more and more content providers employ multiple CDNs to serve the same content and provide the same services. Thus, switching between CDNs, which can be beneficial to reduce costs or to select CDNs by optimal performance in different geographic regions or to overcome CDN-specific outages, becomes an important task. Services that tackle this task emerged, also known as CDN broker, Multi-CDN selectors, or Meta-CDNs. Despite their existence, little is known about Meta-CDN operation in the wild. In this paper, we thus shed light on this topic by dissecting a major Meta-CDN. Our analysis provides insights into its infrastructure, its operation in practice, and its usage by Internet sites. We leverage PlanetLab and Ripe Atlas as distributed infrastructures to study how a Meta-CDN impacts the web latency.

cs.NI

Demystifying TCP Initial Window Configurations of Content Distribution Networks

Driven by their quest to improve web performance, Content Delivery Networks (CDNs) are known adaptors of performance optimizations. In this regard, TCP congestion control and particularly its initial congestion window (IW) size is one long-debated topic that can influence CDN performance. Its size is, however, assumed to be static by IETF recommendations---despite being network- and application-dependent---and only infrequently changed in its history. To understand if the standardization and research perspective still meets Internet reality, we study the IW configurations of major CDNs. Our study uses a globally distributed infrastructure of VPNs giving access to residential access links that enable to shed light on network-dependent configurations. We observe that most CDNs are well aware of the IW's impact and find a high amount of customization that is beyond current Internet standards. Further, we find CDNs that utilize different IWs for different customers and content while others resort to fixed values. We find various initial window configurations, most below 50 segments yet with exceptions of up to 100 segments---the tenfold of current standards. Our study highlights that Internet reality drifted away from recommended and standardized practices.

cs.NI

Hidden Treasures - Recycling Large-Scale Internet Measurements to Study the Internet's Control Plane

Internet-wide scans are a common active measurement approach to study the Internet, e.g., studying security properties or protocol adoption. They involve probing large address ranges (IPv4 or parts of IPv6) for specific ports or protocols. Besides their primary use for probing (e.g., studying protocol adoption), we show that - at the same time - they provide valuable insights into the Internet control plane informed by ICMP responses to these probes - a currently unexplored secondary use. We collect one week of ICMP responses (637.50M messages) to several Internet-wide ZMap scans covering multiple TCP and UDP ports as well as DNS-based scans covering > 50% of the domain name space. This perspective enables us to study the Internet's control plane as a by-product of Internet measurements. We receive ICMP messages from ~171M different IPs in roughly 53K different autonomous systems. Additionally, we uncover multiple control plane problems, e.g., we detect a plethora of outdated and misconfigured routers and uncover the presence of large-scale persistent routing loops in IPv4.

cs.NI

Digging into Browser-based Crypto Mining

Mining is the foundation of blockchain-based cryptocurrencies such as Bitcoin rewarding the miner for finding blocks for new transactions. The Monero currency enables mining with standard hardware in contrast to special hardware (ASICs) as often used in Bitcoin, paving the way for in-browser mining as a new revenue model for website operators. In this work, we study the prevalence of this new phenomenon. We identify and classify mining websites in 138M domains and present a new fingerprinting method which finds up to a factor of 5.7 more miners than publicly available block lists. Our work identifies and dissects Coinhive as the major browser-mining stakeholder. Further, we present a new method to associate mined blocks in the Monero blockchain to mining pools and uncover that Coinhive currently contributes 1.18% of mined blocks having turned over 1293 Moneros in June 2018.

cs.CR