arXiv subjects

Fatih Berkay Sarpkaya

Publications and source records attributed to Fatih Berkay Sarpkaya.

5 recordsLinked to original sources

arXiv2026

Extending Low Latency Service Across the Internet

Protocols such as L4S for low latency network services have attracted growing interest from major industry stakeholders such as Comcast, Apple, T-Mobile, and NVIDIA. However, L4S requires isolation between L4S flows and classic flows in order to maintain its low latency benefits and safe coexistence. The L4S architecture uses a DualPI2 AQM mechanism to provide this isolation when the bottleneck occurs at the home access link. In practice, however, bottlenecks may also occur at other locations in the network, such as peering points, ingress to wide area networks, or occasionally congested links in the core, where deploying DualPI2 AQM is not feasible. Without a solution to this problem, L4S may struggle to gain deployment, since its benefits may remain limited without end-to-end support. To address this challenge, we propose a deployment strategy that reduces the need to upgrade expensive core routers by using existing networking mechanisms such as BGP communities, SRv6, and priority queues with rate caps. We demonstrate the feasibility of this approach through large scale experiments on the FABRIC testbed. Our results demonstrate a practical deployment strategy for extending low latency service across the Internet, even across independently administered networks.

cs.NI↗

arXiv2026

Evaluation of TCP Congestion Control for Public High-Performance Wide-Area Networks

Practitioners of a growing number of scientific and artificial-intelligence (AI) applications use High-Performance Wide-Area Networks (HP-WANs) for moving massive data sets between remote facilities. Accurate prediction of the flow completion time (FCT) is essential in these data-transfer workflows because compute and storage resources are tightly scheduled and expensive. We assess the viability of three TCP congestion control algorithms (CUBIC, BBRv1, and BBRv3) for massive data transfers over public HP-WANs, where limited control of critical data-path parameters precludes the use of Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCEv2), which is known to outperform TCP in private HP-WANs. Extensive experiments on the FABRIC testbed indicate that the configuration control limitations can also hinder TCP, especially through microburst-induced packet losses. Under these challenging conditions, we show that the highest FCT predictability is achieved by combination of BBRv1 with the application of traffic shaping before the HP-WAN entry points.

cs.NI↗

arXiv2025

BBR's Sharing Behavior with CUBIC and Reno

TCP BBR's behavior has been explained by various theoretical models, and in particular those that describe how it co-exists with other types of flows. However, as new versions of the BBR protocol have emerged, it remains unclear to what extent the high-level behaviors described by these models apply to the newer versions. In this paper, we systematically evaluate the most influential steady-state and fluid models describing BBR's coexistence with loss-based flows over shared bottleneck links. Our experiments, conducted on a new experimental platform (FABRIC), extend previous evaluations to additional network scenarios, enabling comparisons between the two models and include the recently introduced BBRv3. Our findings confirm that the steady-state model accurately captures BBRv1 behavior, especially against single loss-based flows. The fluid model successfully captures several key behaviors of BBRv1 and BBRv2 but shows limitations, in scenarios involving deep buffers, large numbers of flows, or intra-flow fairness. Importantly, we observe clear discrepancies between existing model predictions and BBRv3 behavior, suggesting the need for an updated or entirely new modeling approach for this latest version. We hope these results validate and strengthen the research community's confidence in these models and identify scenarios where they do not apply.

cs.NI↗

arXiv2024

To Adopt or Not to Adopt L4S-Compatible Congestion Control? Understanding Performance in a Partial L4S Deployment

With few exceptions, the path to deployment for any Internet technology requires that there be some benefit to unilateral adoption of the new technology. In an Internet where the technology is not fully deployed, is an individual better off sticking to the status quo, or adopting the new technology? This question is especially relevant in the context of the Low Latency, Low Loss, Scalable Throughput (L4S) architecture, where the full benefit is realized only when compatible protocols (scalable congestion control, accurate ECN, and flow isolation at queues) are adopted at both endpoints of a connection and also at the bottleneck router. In this paper, we consider the perspective of the sender of an L4S flow using scalable congestion control, without knowing whether the bottleneck router uses an L4S queue, or whether other flows sharing the bottleneck queue are also using scalable congestion control. We show that whether the sender uses TCP Prague or BBRv2 as the scalable congestion control, it cannot be assured that it will not harm or be harmed by another flow sharing the bottleneck link. We further show that the harm is not necessarily mitigated when a scalable flow shares a bottleneck with multiple classic flows. Finally, we evaluate the approach of BBRv3, where scalable congestion control is used only when the path delay is small, with ECN feedback ignored otherwise, and show that it does not solve the coexistence problem.

cs.NI↗

arXiv2024

To Switch or Not to Switch to TCP Prague? Incentives for Adoption in a Partial L4S Deployment

The Low Latency, Low Loss, Scalable Throughput (L4S) architecture has the potential to reduce queuing delay when it is deployed at endpoints and routers throughout the Internet. However, it is not clear how TCP Prague, a prototype scalable congestion control for L4S, behaves when L4S is not yet universally deployed. Specifically, we consider the question: in a partial L4S deployment, will a user benefit by unilaterally switching from the status quo TCP to TCP Prague? To address this question, we evaluate the performance of a TCP Prague flow when sharing an L4S or non-L4S bottleneck queue with a non-L4S flow. Our findings suggest that the L4S congestion control, TCP Prague, has less favorable throughput or fairness properties than TCP Cubic or BBR in some coexistence scenarios, which may hinder adoption.

cs.NI↗