INFOCOM Artifact Evaluation
Use this when you want to release an artifact. The first thing to internalize: INFOCOM has no
standing artifact-evaluation track and no mandatory badge process (as of 2026-07-09; 待核实
whether a cycle introduces one). Unlike SIGCOMM/NSDI/USENIX ATC — where a separate committee runs
your artifact and awards badges — an INFOCOM artifact is entirely optional and self-directed.
That changes the goal: you package not to pass an evaluator, but to make a large, skeptical,
no-rebuttal reviewer pool believe your numbers.
What the absence of a formal track changes
| At an artifact-track venue (SIGCOMM/NSDI/ATC) |
At INFOCOM |
| A committee runs your artifact on a deadline |
No one is required to run it |
| Badges (Available/Functional/Reproduced) are awarded |
No INFOCOM badge exists (待核实 per cycle) |
| Packaging is a graded deliverable |
Packaging is a credibility investment you choose |
| The artifact can lift a borderline decision |
A released package pre-empts "I don't believe this" in the PDF |
Because no evaluator is guaranteed, the payoff of a release is reviewer trust and post-publication
impact, not a badge. Optimize for a reader who might look, and for the researchers who will
build on your simulator after publication.
IEEE reproducibility options you can opt into
- IEEE DataPort — deposit datasets/traces with a DOI and a license.
- DOI-issuing archives — Zenodo, figshare, or Software Heritage for a simulator or code release
with a permanent identifier and an OSI-approved license.
- Some IEEE venues offer code/data availability badges; INFOCOM does not mandate them — confirm
the current cycle's specifics before claiming one (待核实).
What a credible networking release contains
| Contribution type |
First thing a reader checks |
Common failure to avoid |
| An algorithm/protocol |
A README and one run command on a small example |
Only-runs-on-authors'-cluster; undocumented deps |
| A simulation study |
The scripts that regenerate the paper's figures from logged runs |
Numbers in the PDF no script reproduces |
| A dataset/trace |
The data plus its provenance and preprocessing |
Query shipped, data missing; source unstated |
| A learning-for-networking result |
Cached inputs/outputs, model IDs, seeds |
Requires live API keys; not reproducible |
Packaging plan (optional but persuasive)
[Container] a Dockerfile or a pinned environment (requirements/lockfile) for the simulator/tool
[README] one screen: what it is, how to install, how to run a small demo, how to regenerate
each figure, expected runtime and outputs
[Mapping] an explicit table: paper claim/figure -> script -> expected result
[Config] the exact topology, traffic model, seeds, and parameters used in the paper
[Data] the trace/dataset (or documented access), not just the generator
[License] an OSI-approved license so others can build on it
[Archive] deposit in a DOI-issuing repository (Zenodo/DataPort/Software Heritage)
Double-blind timing
- At submission: if you link an artifact for reviewers, anonymize it — no owner strings, cluster
paths, lab names, or identifying repo — and host it behind an anonymizing service. Nothing
decision-critical may live only there (reviewers need not open it).
- After acceptance: replace anonymized placeholders with the public, licensed, DOI-issuing
archive, and make the camera-ready's statements match it.
Vignette: releasing a scheduling simulator + trace
A paper contributes an edge-scheduling algorithm evaluated by trace-driven simulation. A credible
optional release: a Docker image with the custom simulator pre-built; a run_demo.sh that runs one
small scenario in under a minute; a figures/ directory whose scripts regenerate each plot from
logged runs; a claim-to-script table in the README; the request trace (or documented access) with
its provenance; and an MIT/Apache license with a Zenodo DOI. State honestly which figures are
turnkey and which need the full (slow) trace.
Calibration
- There is no artifact deadline because there is no artifact track — do not invent one; the
only related deadline is the IEEE Xplore camera-ready (
infocom-camera-ready).
- If a future cycle adds an artifact/badge process, confirm its rules, timing, and anonymity model
on the current call before advising (待核实).
Output format
[Release decision] release / no release, with reason
[Target] credibility only / IEEE DataPort / DOI archive / (badge if a cycle offers one, 待核实)
[Contents] <simulator/tool + config + data + license>
[Ten-minute test] does install + demo succeed on a clean machine? yes/no
[Figure mapping] <figure -> script -> expected result present? yes/no>
[Anonymity] anonymized for review; de-anonymized DOI archive for camera-ready? yes/no
1---2name: infocom-artifact-evaluation3description: Use when packaging IEEE INFOCOM code, simulators, and datasets for credibility and optional IEEE reproducibility badges, given that INFOCOM runs no standing artifact-evaluation track, covering DOI-issuing archives, evaluator-proof documentation, what the absence of a formal track changes, and how a released package strengthens a no-rebuttal submission.4---56# INFOCOM Artifact Evaluation78Use this when you want to release an artifact. The first thing to internalize: **INFOCOM has no9standing artifact-evaluation track and no mandatory badge process** (as of 2026-07-09; 待核实10whether a cycle introduces one). Unlike SIGCOMM/NSDI/USENIX ATC — where a separate committee runs11your artifact and awards badges — an INFOCOM artifact is **entirely optional and self-directed**.12That changes the goal: you package not to pass an evaluator, but to make a large, skeptical,13no-rebuttal reviewer pool believe your numbers.1415## What the absence of a formal track changes1617| At an artifact-track venue (SIGCOMM/NSDI/ATC) | At INFOCOM |18|---|---|19| A committee runs your artifact on a deadline | No one is required to run it |20| Badges (Available/Functional/Reproduced) are awarded | No INFOCOM badge exists (待核实 per cycle) |21| Packaging is a graded deliverable | Packaging is a credibility investment you choose |22| The artifact can lift a borderline decision | A released package pre-empts "I don't believe this" in the PDF |2324Because no evaluator is guaranteed, the payoff of a release is **reviewer trust and post-publication25impact**, not a badge. Optimize for a reader who *might* look, and for the researchers who will26build on your simulator after publication.2728## IEEE reproducibility options you can opt into2930- **IEEE DataPort** — deposit datasets/traces with a DOI and a license.31- **DOI-issuing archives** — Zenodo, figshare, or Software Heritage for a simulator or code release32 with a permanent identifier and an OSI-approved license.33- Some IEEE venues offer **code/data availability badges**; INFOCOM does not mandate them — confirm34 the current cycle's specifics before claiming one (**待核实**).3536## What a credible networking release contains3738| Contribution type | First thing a reader checks | Common failure to avoid |39|---|---|---|40| An algorithm/protocol | A README and one run command on a small example | Only-runs-on-authors'-cluster; undocumented deps |41| A simulation study | The scripts that regenerate the paper's figures from logged runs | Numbers in the PDF no script reproduces |42| A dataset/trace | The data plus its provenance and preprocessing | Query shipped, data missing; source unstated |43| A learning-for-networking result | Cached inputs/outputs, model IDs, seeds | Requires live API keys; not reproducible |4445## Packaging plan (optional but persuasive)4647```text48[Container] a Dockerfile or a pinned environment (requirements/lockfile) for the simulator/tool49[README] one screen: what it is, how to install, how to run a small demo, how to regenerate50 each figure, expected runtime and outputs51[Mapping] an explicit table: paper claim/figure -> script -> expected result52[Config] the exact topology, traffic model, seeds, and parameters used in the paper53[Data] the trace/dataset (or documented access), not just the generator54[License] an OSI-approved license so others can build on it55[Archive] deposit in a DOI-issuing repository (Zenodo/DataPort/Software Heritage)56```5758## Double-blind timing5960- **At submission:** if you link an artifact for reviewers, anonymize it — no owner strings, cluster61 paths, lab names, or identifying repo — and host it behind an anonymizing service. Nothing62 decision-critical may live only there (reviewers need not open it).63- **After acceptance:** replace anonymized placeholders with the public, licensed, DOI-issuing64 archive, and make the camera-ready's statements match it.6566## Vignette: releasing a scheduling simulator + trace6768A paper contributes an edge-scheduling algorithm evaluated by trace-driven simulation. A credible69optional release: a Docker image with the custom simulator pre-built; a `run_demo.sh` that runs one70small scenario in under a minute; a `figures/` directory whose scripts regenerate each plot from71logged runs; a claim-to-script table in the README; the request trace (or documented access) with72its provenance; and an MIT/Apache license with a Zenodo DOI. State honestly which figures are73turnkey and which need the full (slow) trace.7475## Calibration7677- There is **no artifact deadline** because there is **no artifact track** — do not invent one; the78 only related deadline is the IEEE Xplore camera-ready (`infocom-camera-ready`).79- If a future cycle adds an artifact/badge process, confirm its rules, timing, and anonymity model80 on the current call before advising (**待核实**).8182## Output format8384```text85[Release decision] release / no release, with reason86[Target] credibility only / IEEE DataPort / DOI archive / (badge if a cycle offers one, 待核实)87[Contents] <simulator/tool + config + data + license>88[Ten-minute test] does install + demo succeed on a clean machine? yes/no89[Figure mapping] <figure -> script -> expected result present? yes/no>90[Anonymity] anonymized for review; de-anonymized DOI archive for camera-ready? yes/no91```