sigcomm-writing-style

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>