CoNEXT Reproducibility
Build the reproducible-networking story alongside the experiments, not after acceptance. CoNEXT runs
a dedicated reproducibility committee that awards optional ACM badges, and the single most
missed rule is that badge eligibility requires opting in before the paper submission deadline —
you cannot bolt it on later. Even for authors who skip badging, a reproducible artifact strengthens
a double-anonymous, one-shot-revision review.
The timing trap (read this first)
[Before the submission deadline] OPT IN for ACM badging (required for eligibility)
[At submission] anonymized, runnable artifact referenced from the paper
[Within ~1 week of acceptance] send a ONE-PAGE artifact description to the reproducibility
committee with pointers to code and other artifacts
[Camera-ready / post-accept] committee evaluates for Available / Functional / Reusable /
Reproduced badges (see conext-artifact-evaluation)
Miss the opt-in and the strongest artifact in the world cannot earn a badge this cycle.
What "reproducible" means for a networking paper
Networking reproducibility is harder than "here is the code," because the result depends on an
environment:
- Traces: the exact captures, with vantage points, dates, and anonymization documented, plus the
extraction scripts that turn raw captures into the paper's inputs.
- Configs: the exact parameters, topology, and settings used for each figure — not a
representative example.
- Environment: hardware models, firmware, kernel/OS versions, link rates, and buffer depths for
a testbed; container/VM images where feasible.
- Pipeline: a scripted path from raw data/trace to each table and figure, so the numbers
regenerate rather than being hand-copied.
Pin provenance at collection time
You cannot reconstruct provenance after the campaign ends:
- Record capture vantage points, timestamps, and anonymization method as you collect.
- Snapshot configs and firmware/OS versions at run time; a later "we think it was v2.1" is not
reproducible.
- For ML-for-networking, pin model identifiers and dates and cache raw model outputs — a package
that needs live API calls re-samples rather than reproduces.
Honest data-availability posture
- If you can release traces/code, do — with a DOI-issuing archive (Zenodo/figshare/Software
Heritage) and an open license.
- If operator agreements or privacy limits block release, say so and why, and release what you
can (aggregate data, synthetic traces, the analysis pipeline). "Available upon request" reads as a
scored weakness, not a neutral placeholder.
- Keep the availability statement honest and matched to what the artifact actually contains — a
reviewer or the committee will check.
Anonymity of the artifact (double-anonymous review)
- Re-host the artifact behind an anonymizing service before submission; scrub commit metadata,
internal hostnames, and owner-identifying paths.
- Topology diagrams and configs can leak an operator or institution — sanitize AS numbers, hostnames,
and IP ranges you own.
- The reproducibility material referenced at review time must not de-anonymize you.
The one-page artifact description
After acceptance, the committee wants a one-page description that lets an evaluator start
quickly:
- What the artifact contains (code, traces, configs, testbed scripts) and pointers to each.
- The hardware/software the evaluator needs, and any hardware you must provide access to (some
networking artifacts need specific switches/NICs — flag this early).
- A short "getting started" path and the claims the artifact supports.
Pre-submission reproducibility audit
[Opt-in] badge opt-in done BEFORE the submission deadline? (if badging) yes/no
[Traces] captures + vantage points + dates + extraction scripts present? yes/no
[Configs] exact per-figure configs and topology recorded? yes/no
[Environment] hardware/firmware/OS versions pinned; image where feasible? yes/no
[Pipeline] raw -> figure regenerates by script? yes/no
[Availability] honest statement; DOI archive or a documented reason not to release? yes/no
[Anonymity] artifact re-hosted anonymously; metadata scrubbed? yes/no
Output format
[Reproducibility status] ready / gaps
[Badge intent] opt-in before submission? yes/no/n-a
[Provenance] traces/configs/environment pinned at collection time
[Availability] what is released, where (DOI), and any documented restriction
[Anonymity] artifact anonymized for double-anonymous review
[One-pager] artifact description drafted for the committee (post-accept)
1---2name: conext-reproducibility3description: Use when building the reproducibility story for an ACM CoNEXT paper — pinned traces and configs, a runnable artifact, an honest data-availability posture, and the one-page artifact description the CoNEXT reproducibility committee needs — remembering that the ACM badge opt-in is due before the submission deadline.4---56# CoNEXT Reproducibility78Build the reproducible-networking story alongside the experiments, not after acceptance. CoNEXT runs9a dedicated **reproducibility committee** that awards **optional ACM badges**, and the single most10missed rule is that **badge eligibility requires opting in before the paper submission deadline** —11you cannot bolt it on later. Even for authors who skip badging, a reproducible artifact strengthens12a double-anonymous, one-shot-revision review.1314## The timing trap (read this first)1516```text17[Before the submission deadline] OPT IN for ACM badging (required for eligibility)18[At submission] anonymized, runnable artifact referenced from the paper19[Within ~1 week of acceptance] send a ONE-PAGE artifact description to the reproducibility20 committee with pointers to code and other artifacts21[Camera-ready / post-accept] committee evaluates for Available / Functional / Reusable /22 Reproduced badges (see conext-artifact-evaluation)23```2425Miss the opt-in and the strongest artifact in the world cannot earn a badge this cycle.2627## What "reproducible" means for a networking paper2829Networking reproducibility is harder than "here is the code," because the result depends on an30environment:3132- **Traces:** the exact captures, with vantage points, dates, and anonymization documented, plus the33 extraction scripts that turn raw captures into the paper's inputs.34- **Configs:** the exact parameters, topology, and settings used for each figure — not a35 representative example.36- **Environment:** hardware models, firmware, kernel/OS versions, link rates, and buffer depths for37 a testbed; container/VM images where feasible.38- **Pipeline:** a scripted path from raw data/trace to each table and figure, so the numbers39 regenerate rather than being hand-copied.4041## Pin provenance at collection time4243You cannot reconstruct provenance after the campaign ends:4445- Record capture vantage points, timestamps, and anonymization method **as you collect**.46- Snapshot configs and firmware/OS versions **at run time**; a later "we think it was v2.1" is not47 reproducible.48- For ML-for-networking, pin model identifiers and dates and **cache raw model outputs** — a package49 that needs live API calls re-samples rather than reproduces.5051## Honest data-availability posture5253- If you can release traces/code, do — with a DOI-issuing archive (Zenodo/figshare/Software54 Heritage) and an open license.55- If operator agreements or privacy limits block release, **say so and why**, and release what you56 can (aggregate data, synthetic traces, the analysis pipeline). "Available upon request" reads as a57 scored weakness, not a neutral placeholder.58- Keep the availability statement **honest and matched** to what the artifact actually contains — a59 reviewer or the committee will check.6061## Anonymity of the artifact (double-anonymous review)6263- Re-host the artifact behind an **anonymizing service** before submission; scrub commit metadata,64 internal hostnames, and owner-identifying paths.65- Topology diagrams and configs can leak an operator or institution — sanitize AS numbers, hostnames,66 and IP ranges you own.67- The reproducibility material referenced at review time must not de-anonymize you.6869## The one-page artifact description7071After acceptance, the committee wants a **one-page** description that lets an evaluator start72quickly:7374- What the artifact contains (code, traces, configs, testbed scripts) and pointers to each.75- The hardware/software the evaluator needs, and any hardware you must provide access to (some76 networking artifacts need specific switches/NICs — flag this early).77- A short "getting started" path and the claims the artifact supports.7879## Pre-submission reproducibility audit8081```text82[Opt-in] badge opt-in done BEFORE the submission deadline? (if badging) yes/no83[Traces] captures + vantage points + dates + extraction scripts present? yes/no84[Configs] exact per-figure configs and topology recorded? yes/no85[Environment] hardware/firmware/OS versions pinned; image where feasible? yes/no86[Pipeline] raw -> figure regenerates by script? yes/no87[Availability] honest statement; DOI archive or a documented reason not to release? yes/no88[Anonymity] artifact re-hosted anonymously; metadata scrubbed? yes/no89```9091## Output format9293```text94[Reproducibility status] ready / gaps95[Badge intent] opt-in before submission? yes/no/n-a96[Provenance] traces/configs/environment pinned at collection time97[Availability] what is released, where (DOI), and any documented restriction98[Anonymity] artifact anonymized for double-anonymous review99[One-pager] artifact description drafted for the committee (post-accept)100```