---

name: sigcomm-artifact-evaluation description: Use when packaging an ACM SIGCOMM paper's code, traces, topologies, and configuration for the artifact-evaluation committee — choosing ACM badges (Artifacts Available, Evaluated, Results Reproduced) as claim calibration, building downscaled topologies and trace substitutes, and making a networking testbed result rebuildable by a reviewer.

SIGCOMM Artifact Evaluation

Use this for the post-acceptance artifact submission. SIGCOMM helped establish artifact evaluation in networking, and the venue's "runnable papers" culture sets a high bar: a committee attempts to build and, where a badge requires it, reproduce your headline result. Reopen the current Call for Artifacts for this edition's exact badge set and dates (待核实 for 2026).

Badge selection is claim calibration

Choose the badges you can honestly support; the badge is a promise about what a stranger can verify, not a participation ribbon.

ACM badge	What it promises	What the AEC will do
Artifacts Available	Permanent public retrieval via an archival DOI	Confirm the archive resolves and is complete
Artifacts Evaluated (Functional)	The artifact builds and runs as documented	Follow your README end to end on their setup
Results Reproduced	The paper's main results follow from the artifact	Re-run to obtain the headline numbers within tolerance

Aim the highest badge at the result you most want believed, and be candid where hardware or scale makes full reproduction infeasible.

The networking-specific hard part

Generic artifact tooling cannot judge what SIGCOMM evaluators care about most: a result measured on a rack of switches or a wide-area testbed rarely rebuilds on a laptop. Plan for the gap:

• Downscale the topology. Ship a small emulated or Mininet-style topology that reproduces the mechanism's behavior, with a documented map from the downscaled run to the paper's full-scale figure.
• Substitute the trace legally. If the production trace cannot ship, provide a synthetic or public-trace substitute with the same statistical character, and state exactly which figures used which input.
• Pin the environment. Kernel and NIC features, switch firmware or programmable-data-plane toolchain versions, and clock/timestamp sources all move results; record them.
• Expose the run count. Every reported percentile needs its replication count and the seed or workload driver, or the tail cannot be reproduced.

What evaluators open first

artifact/
  README            # 5-minute smoke run FIRST, then the full path
  smoke/            # one command -> one small figure that proves it runs
  topology/         # downscaled + a map to the paper's full-scale setup
  traces/           # substitute inputs + provenance + which-figure-uses-what
  configs/          # exact parameters per experiment
  scripts/          # regenerate each figure from logged results
  results/          # logged raw outputs the plots are built from
  ENVIRONMENT.md    # kernel/NIC/switch/toolchain versions, hardware

Assume the evaluator runs the smoke path first and stops if it fails, so make one command produce one convincing small figure before anything else is polished.

Vignette: packaging a data-center transport result

A paper reports a tail-FCT win on a 128-server testbed. Turnkey plan: a Mininet topology that reproduces the incast dynamic at small scale; a synthetic RPC workload matching the trace's flow-size distribution; a driver that emits the FCT distribution over 20 replays; and a script that plots the 99th percentile directly from logged results so the artifact figure and the paper figure cannot diverge. The README states plainly which numbers are full-scale (paper) and which are downscaled (artifact).

Output format

[Badges sought] available / functional / reproduced — each justified
[Smoke path] one command -> one figure? yes/no
[Topology] full-scale -> downscaled map documented
[Trace handling] shipped / substituted (+ provenance) / described
[Environment] kernel/NIC/switch/toolchain pinned
[Fixes before AEC upload] <ordered list>