sigcomm-experiments
GitHub用于ACM SIGCOMM实验设计与审计，指导从微基准到部署的证据链构建。强调选择强基线、报告尾部百分位与方差、固定公平变量、记录完整设置及映射机制失效点，确保评估的真实性、公平性与严谨性。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill sigcomm-experiments -g -y
SKILL.md
Frontmatter
{
"name": "sigcomm-experiments",
"description": "Use when designing or auditing ACM SIGCOMM experiments — climbing the evidence ladder from microbenchmarks to testbed and trace replay to deployment, choosing baselines that match the deployed state of the art, reporting tail percentiles and variance over repeated trials, mapping break points, and holding the fair variable fixed."
}
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>
Version History
- 9f86f09 Current 2026-07-19 17:35
