thedixitjain SIGCOMM Writing Style
Use this when revising the main paper. A SIGCOMM paper has to make a networking mechanism feel inevitable: the reader should see the measured problem, the principle that solves it, and the evidence that it works under real conditions — inside 12 pages where figures count. Reopen the current CFP for format specifics.
Revision rules
- Lead with measured pain. Put the operational cost in numbers on the first page — which percentile, how bad, under what traffic — not "congestion is a well-known problem." An asserted motivation is the first thing a SIGCOMM reviewer discounts.
- Name the design principle. State the invariant your mechanism defends, not just what it does. "Steer at the timescale congestion forms" is a principle; "avoids hotspots" is a behavior.
- Pair every claim with evidence. Each performance claim maps to a table, a figure, a sweep, or a documented break point — and the evidence lives on a testbed, trace, or deployment, not in simulation alone for a fabric claim.
- Report the distribution. Tails are usually the point in networking; give percentiles and variance over repeated trials, and hold the fair variable (throughput, load) fixed.
- Spend the 12 pages on the spine. Figures count against the cap, so every figure must earn its space; push depth to appendix and artifact without making the body incomplete.
- Keep blinding clean. Anonymize authorship and deployment identity — a named backbone plus a topology detail can deanonymize as surely as a byline.
Sentence-level rewrites
| Draft pattern | SIGCOMM-safe rewrite |
|---|---|
| "significantly improves performance" | "cuts 99th-percentile FCT by 2.4x at matched throughput" |
| "congestion is a serious problem" | "incast inflates P99 short-flow FCT by 3.1x on our testbed" |
| "our system avoids hotspots" | "reroutes flowlets on instantaneous backlog, so response tracks queue buildup" |
| "outperforms in most cases" | claim scoped to the workloads and topologies actually tested |
| "we evaluate in simulation" | "we measure on a 128-server testbed replaying a production trace" |
Structure discipline
- The first page carries problem, principle, mechanism, and headline evidence; a reviewer should be able to accept-or-reject on the first page and have the rest confirm it.
- Every declarative claim near a number is something a reviewer may try to reproduce; do not write a sentence you cannot back with a run.
- Separate what you measured from what you designed from what you conjecture; mixing an unproven stability claim into a measured-result paragraph is a credibility leak.
- Motivate with measurement, then build the mechanism; the "measurement motivates mechanism" arc (as in VL2) reads as native SIGCOMM.
Vignette: compressing into 12 figure-inclusive pages
A draft with eight figures and a sprawling background section: keep the measured-motivation figure and the two decision-critical tail plots in the body, fold three micro-benchmarks into one multi-panel figure, move two sweeps to an appendix with forward references, and compress background into contribution contrasts. The test of a good cut: a reviewer reconstructs the whole argument from the body alone, and no surviving figure is decorative.
Output format
[Writing diagnosis] clear / under-motivated / behavior-not-principle / mean-only / overloaded
[First-page fix] <measured pain + principle + headline evidence>
[Claim discipline] <claim -> table / figure / sweep / break point>
[Tail reporting] <percentiles + variance + fixed fair variable>
[Compression cuts] <merge / move / delete>
[Anonymity edits] <authorship + deployment phrases to neutralize>
Source: brycewang-stanford/Awesome-Journal-Skills → SIGCOMM-Skills/skills/sigcomm-writing-style/SKILL.md