Pith. Sign in

RECORD

Bringing Reconfigurability to the Network Stack

PaperPDF from arXiv

data files

Paper breakdownThe authors' claims, conditions and measurements, as JSON Signed receiptProof this review has not been altered
X Bluesky LinkedIn Reddit Hacker News
Akshay Narayan, Aurojit Panda, Mohammad Alizadeh, Hari Balakrishnan, Arvind Krishnamurthy, Scott Shenker

Networking and Internet Architecture · Submitted 13 Nov 2023

abstract compiled · 2026-09-23 · no language-model review

The authors' main claim Our evaluation shows cases where this results in 16x higher throughput and 63% lower latency than current portable approaches while imposing minimal overheads when compared to a hand-optimized versions that use deployment-specific communication primitives.

how it is stated · asserted 1.00 read the record →

Comment (0) Read on arXiv ↗
Cite ▾
arXiv ID2311.07753 (version 1)
Pith IDE4GHQZPH, Pith's permanent record of this paper and its review
CitationAkshay Narayan, Arvind Krishnamurthy, Aurojit Panda, Hari Balakrishnan, Mohammad Alizadeh, Scott Shenker. "Bringing Reconfigurability to the Network Stack." arXiv:2311.07753 (2023). https://pith.science/paper/E4GHQZPH
Claim paper

The compiled record

The paper's own sentences, arranged. Each label is drawn from a closed vocabulary; the number beside it is the probability the classifier gave that label. Numbers in the tables are the authors', checked by code. No sentence in this record was written by a model.

Open the compiled record

Compiled by classifier-1.13.0 via TypeSafe API, question bank abstract-p1-20260923, 2026-09-23: 1 request, 4,291 input tokens.

What the abstract itself states, as probabilities: claims first 0.06 · states limitation 0.32 · human participants 0.03 · controlled comparison 0.89 · randomized assignment 0.01 · states quantitative result 0.99 · compares with prior results 0.97 · mentions code or data availability 0.05.

The abstract, sentence by sentence

arXiv listing abstract v1. Results and the main claim are underlined; .

Reconfiguring the network stack allows applications to specialize the implementations of communication libraries depending on where they run, the requests they serve, and the performance they need to provide. Specializing applications in this way is challenging because developers need to choose the libraries they use when writing a program and cannot easily change them at runtime. This paper introduces Bertha, which allows these choices to be changed at runtime without limiting developer flexibility in the choice of network and communication functions. Bertha allows applications to safely use optimized communication primitives (including ones with deployment limitations) without limiting deployability. Our evaluation shows cases where this results in 16x higher throughput and 63% lower latency than current portable approaches while imposing minimal overheads when compared to a hand-optimized versions that use deployment-specific communication primitives.

background contribution method result interpretation main claim

What the classifier reports for each sentence. The number is the probability it gave the label.
#sentencerolethe authors' own workstates the main conclusionstrength
s0 Reconfiguring the network stack allows applications to specialize the implementations of communication libraries depending on where they run, the requests they serve, and the performance they need to provide. background 1.00 0.09 0.05 asserted 0.93
s1 Specializing applications in this way is challenging because developers need to choose the libraries they use when writing a program and cannot easily change them at runtime. background 0.73 0.07 0.03 asserted 1.00
s2 This paper introduces Bertha, which allows these choices to be changed at runtime without limiting developer flexibility in the choice of network and communication functions. contribution 1.00 0.81 0.28 asserted 1.00
s3 Bertha allows applications to safely use optimized communication primitives (including ones with deployment limitations) without limiting deployability. contribution 0.95 0.63 0.14 asserted 0.98
s4 Our evaluation shows cases where this results in 16x higher throughput and 63% lower latency than current portable approaches while imposing minimal overheads when compared to a hand-optimized versions that use deployment-specific communication primitives. result 1.00 0.96 0.52 asserted 1.00

What kind of paper the classifier reports this is: method or tool 1.00 · evidence from observation or experiment 1.00.

What was examined, and what was not

sources read
  • arXiv listing abstract v1
not examined
  • full text
  • figures and tables
  • references and citing sentences
  • relations to other papers
levels run
  • P abstract
not run
  • S sections
  • T body sentences
  • C citations
  • R cross-paper relations

Every quoted sentence on this record is the authors'. Every label is from Pith's closed vocabulary, with the probability shown beside it. Every number in the measurements table is the authors', checked by code. Record as JSON

The paper
Original abstract

Reconfiguring the network stack allows applications to specialize the implementations of communication libraries depending on where they run, the requests they serve, and the performance they need to provide. Specializing applications in this way is challenging because developers need to choose the libraries they use when writing a program and cannot easily change them at runtime. This paper introduces Bertha, which allows these choices to be changed at runtime without limiting developer flexibility in the choice of network and communication functions. Bertha allows applications to safely use optimized communication primitives (including ones with deployment limitations) without limiting deployability. Our evaluation shows cases where this results in 16x higher throughput and 63% lower latency than current portable approaches while imposing minimal overheads when compared to a hand-optimized versions that use deployment-specific communication primitives.

Human review

How Pith checks papers → · Full audit of this paper →

References

Discussion

Know something about this paper? Leave a comment, or highlight any passage above to comment on it.