thedixitjain SIGCOMM Experiments
Use this before submission when the evaluation is not yet locked. At SIGCOMM the experiments are where a mechanism is believed or disbelieved, and the reviewer culture reads a setup for realism, fairness, and honesty about where the mechanism breaks.
Experiment audit
- Map each performance claim to a specific microbenchmark, testbed run, trace replay, deployment measurement, or documented break point.
- Choose baselines that fight back: the strongest deployed alternative, tuned fairly, not a straw man the mechanism was built to beat.
- Report the distribution. Give the relevant percentiles (P50, P99, and the tail that hurts) with variance over repeated trials, and hold the fair variable — throughput, offered load, fairness — fixed while you compare.
- Document the setup completely: topology, buffer sizes, workload or trace and its provenance, parameters, environment versions, run counts, and seeds.
- Map the break point: the workload or condition where the mechanism degrades to the baseline. A paper that never shows where its idea stops working invites the reviewer to assume it stops everywhere interesting.
- Audit for leakage between motivation and evaluation, unrepresentative traffic, and any mismatch between the claimed operating regime and the one actually tested.
The evidence ladder
| Rung | Evidence | What it proves | Limit |
|---|---|---|---|
| Microbenchmark | Isolated mechanism in a controlled setup | The mechanism does what the principle claims | Says nothing about real traffic |
| Testbed / emulation | Real switches or a faithful emulator under a workload | Behavior under contention and topology | Scale and workload realism bounded |
| Trace replay | A production or representative trace driving the testbed | Behavior under realistic traffic structure | Trace provenance must be defensible |
| Deployment | The mechanism in real operation | It survives the messy real world | Hard to isolate cause; strongest evidence |
Climb as high as the contribution's claim requires. A fabric or transport claim generally needs at least testbed-plus-trace evidence; simulation-only or mean-only results read as under-evaluated for such claims.
What experiments are for here
Not: "we beat every baseline on average across many workloads"
But: "under the traffic that causes the pain we measured, this mechanism
cuts the tail that hurts, at matched throughput, and here is exactly
where it stops helping."
One decisive experiment under the workload that motivated the paper outweighs five extra datasets that never stress the mechanism.
Vignette: evaluating a routing mechanism
A paper proposes backlog-aware rerouting. The matching plan: a microbenchmark showing the rerouting reacts at the intended timescale; a testbed replaying a production RPC trace to show the tail-FCT win at matched throughput; sweeps over incast ratio and buffer size to show the win is not a single-point artifact; and an adversarial workload that removes flowlet gaps to map the break point where the mechanism degrades to ECMP — each result tied to a numbered claim.
Output format
[Evaluation readiness] strong / adequate / weak
[Claim -> evidence map] <claim: microbenchmark / testbed / trace / deployment>
[Baseline check] <strongest deployed alternative, tuned fairly? yes/no>
[Tail reporting] <percentiles + variance + matched fair variable>
[Break point] <where the mechanism degrades, and to what>
[Decision-critical next run] <one experiment>
Source: brycewang-stanford/Awesome-Journal-Skills → SIGCOMM-Skills/skills/sigcomm-experiments/SKILL.md