--- name: sigcomm-writing-style description: Use when revising an ACM SIGCOMM paper for its house style — leading with measured operational pain, stating a design principle rather than a behavior, pairing every claim with testbed/trace/deployment evidence, reporting tails instead of superlatives, and fitting the argument into 12 figure-inclusive pages while keeping blinding clean. --- # 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 ```text [Writing diagnosis] clear / under-motivated / behavior-not-principle / mean-only / overloaded [First-page fix] [Claim discipline] table / figure / sweep / break point> [Tail reporting] [Compression cuts] [Anonymity edits] ```