arXiv Science⌕ Search

arXiv · 1010.5623

Rethinking low extra delay background transport protocols

Abstract

BitTorrent has recently introduced LEDBAT, a novel application-layer congestion control protocol for data exchange. The protocol design starts from the assumption that network bottlenecks are at the access of the network, and that thus user traffic competes creating self-inducing congestion. To relieve from this phenomenon, LEDBAT is designed to quickly infer that self-induced congestion is approaching (by detecting relative changes of the one-way delay in the transmission path), and to react by reducing the sending rate prior that congestion occurs. Prior work has however shown LEDBAT to be affected by a latecomer advantage, where newly arriving connections can starve already existing flows. In this work, we propose modifications to the congestion window update mechanism of the LEDBAT protocol that aim at solving this issue, guaranteeing thus intra-protocol fairness and efficiency. Closed-form expressions for the stationary throughput and queue occupancy are provided via a fluid model, whose accuracy is confirmed by means of ns2 packet level simulations. Our results show that the proposed change can effective solve the latecomer issue, without affecting the other original LEDBAT goals at the same time.

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Giovanna Carofiglio, Luca Muscariello, Dario Rossi, Claudio Testa, Silvio Valenti. 2010-10-27. Rethinking low extra delay background transport protocols. https://arxiv.org/abs/1010.5623

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

On the Design of Physical Topology in OCS-based Clusters

Optical Circuit Switches (OCSes) are increasingly deployed in data center networks and AI clusters. By wiring the electrical ports of GPUs and electrical switches to the OCS ports, the physical interconnection pattern defines a \emph{physical topology}. \textbf{Topology Engineering (ToE)} seeks an OCS configuration that optimizes a traffic objective given traffic demands and physical constraints, but solving this joint problem is computationally expensive. A common approach is to \emph{decouple} the problem into two steps: first, compute a \emph{logical topology} that satisfies the traffic demands without considering the physical topology constraints and then map it onto the physical topology to obtain the OCS configuration. This, however, introduces a quality loss issue: the resulting logical topology sometimes cannot be realized exactly under the given physical topology. To address this problem, we show that it stems from a property missing in the physical topology. We propose \textbf{Decoupling Optimality} and the necessary and sufficient conditions under which a decoupled method will not lose quality. Examining existing physical topologies against these conditions reveals that they either fail them, or satisfy them at the cost of cluster scale or deployment generality. Our proposed \textbf{Cross Wiring} meets all the conditions, without sacrificing cluster scale or adding devices. On a 128-NPU testbed, the lack of \emph{Decoupling Optimality} increases training iteration time by up to 39.5\%, and a microbenchmark validates the importance of \emph{Decoupling Optimality} in both solution quality and solving speed. A testbed built from two MEMS OCSes validates the engineering feasibility of Cross Wiring.

cs.NI↗

Can LLMs help find Ambiguities in Protocol Specifications?

Internet protocol specifications written in RFCs are subject to ambiguities and multiple interpretations that can cause interoperability failure. While these have presumably cleared up after years of experience, such ambiguities can bedevil the adoption of newer protocols like 5G. The 5G specifications pair a formal message syntax (ASN.1) with message-handling procedures written in natural language. This creates semantic underspecification: a syntactically valid message can reach a state whose procedures never say how to handle it, so standard-compliant implementations diverge. We frame this as a gap or a fork in a partially specified communicating state machine, and present SpecLens, which puts that view in front of a language model as a scaffold. Stronger models do not remove the need for it: they broaden the search without disciplining it, and fewer than half their findings survive inspection. Across 36 procedures from six 3GPP and O-RAN protocols, experts accept 185 of 197 SpecLens findings, and 60 drive observable divergence between the OpenAirInterface and srsRAN implementations under differential test. While we use 5G as a canonical example of a newer protocol, we also show ambiguity results for the more mature DNS protocol.

cs.NI↗

MoSE: Mode-Switching Expander for Mixed LLM Training and Inference

AI clusters increasingly run large language model (LLM) inference and training on the same fabric. Prefill-decode (P-D) disaggregation creates key-value (KV) cache transfers between prefill and decode groups, whereas training collectives and all-to-all traffic benefit from near-uniform global connectivity. A static sparse topology can therefore be poorly matched to one of the two traffic patterns. We present Mode-Switching Expander (MoSE), a reconfigurable expander that treats topology design as a fixed-degree edge-allocation problem. MoSE reallocates the same sparse edge budget toward direct P-D connectivity in inference-heavy modes and restores a uniform random regular expander in training-heavy modes. We evaluate MoSE using a 1024-group flow-level topology model, shortest-path routing, and two mixed workloads. Across 20 seeds, MoSE reduces average and 95th-percentile (P95) load-aware KV communication cost by 90.8\% and 91.9\% relative to Static-Training in the inference-heavy mode. In the training-heavy mode, it reduces average and P95 training communication cost by 22.7\% and 27.6\% relative to stale Static-Inference. These results show that coarse-grained topology switching can support both workload modes without additional ports or routing changes.

cs.NI↗