| name | nsdi-writing-style |
| description | Use when drafting or revising NSDI prose — building the operational-pain-to-design-principle arc, fitting argument and figures into 12 pages with references and appendices outside the cap, calibrating claims to trace and testbed evidence, and writing for reviewers who read tail percentiles before adjectives. |
NSDI Writing Style
An NSDI paper argues that a nameable design idea, embodied in a working networked
system, holds up under realistic traffic. The prose exists to make that chain
checkable. Format facts below are the NSDI '27 CFP as rendered on 2026-07-08.
The opening arc
NSDI first pages that work tend to execute five beats in order (see the rebuilt
example in
../../resources/worked-examples/01-introduction.md):
- Operational pain, evidenced — a failure shape, cost, or limit shown in a trace
or deployment, not asserted from intuition.
- Why the networked setting causes it — the distributed or stack-level reason
local fixes fail. This beat is also the scope defense; a paper that cannot write it
is drifting out of the CFP's "design of networked systems or the networking stack."
- The design principle, named — the transferable idea, stated so another team
could apply it to a different system.
- The built system — what was implemented, where it runs, what was not built.
- Claims with evidence addresses — each headline number tied to a section, a
workload, and a percentile.
Budget arithmetic before sentence polish
The '27 rule: 12 pages including footnotes, figures, and tables; references and
appendices may extend beyond. Two consequences shape the writing:
- Figures are inside the cap, so every plot pays rent. Cut the third bar chart saying
"ours is faster again"; keep the breakdown that explains why.
- Appendices exist but are overflow, not annex: reviewers judge the 12 pages. Nothing
load-bearing (a baseline, the key workload description, a correctness argument)
may live only past the references (
nsdi-supplementary).
A workable allocation for a 12-page systems paper:
| Section | Pages | Job |
|---|
| Intro + motivation measurement | 2 - 2.5 | Beats 1-3 with data |
| Design | 3 - 3.5 | Principle → mechanism → interfaces; failure handling explicit |
| Implementation | 0.5 - 1 | What exists, LoC/frameworks, honest deltas from design |
| Evaluation | 3.5 - 4 | Questions answered, not benchmarks toured |
| Related work + discussion | 1 - 1.5 | Positioning + stated limits |
Sentence-level calibration
Systems reviewers at this venue distrust superlatives and read distributions. Editing
passes that consistently improve NSDI drafts:
- Replace every "up to N×" with the percentile, workload, and range: "2.1-3.4× at
p99.9 on the replayed incident weeks."
- Replace "significantly / dramatically / novel" with the measured delta or the named
mechanism. Adjectives signal missing numbers.
- Convert passive mechanism descriptions into agent-explicit ones — which component
decides, on what signal, at what timescale.
- State the boundary honestly, in the body: the regime where the design loses
(incast, single replica, cold caches). NSDI culture treats a named limitation as
competence, and an unnamed one found by a reviewer as concealment.
- Keep terminology bijective: one name per component, one component per name, figures
and text agreeing exactly.
Weak: "Our novel scheduler significantly reduces latency (up to 4.1x)
compared to state-of-the-art approaches."
NSDI: "Shifting retries off congested paths cuts p99.9 latency 2.1-3.4x
vs tuned exponential backoff across the three incident classes
(§6.2); gains vanish when RTT < the lease renewal interval (§7)."
Anonymity constraints on prose
Double-blind shapes phrasing, with one NSDI-specific fork: research-track papers
neutralize identifying deployment details ("a large provider's fleet"), while
operational-track papers may keep real system and company names with author names
still withheld. Write self-citations in the third person; never delete a reference to
hide identity; cite a concurrent NSDI submission as "Under submission. Details omitted
for double-blind reviewing." The CFP endorses AI tools for grammar and clarity of
human-written text — the ideas, and the responsibility, stay human.
Revision-letter prose (one-shot resubmissions)
A resubmitted revision is read by the same reviewers against their own issue list, so
the writing task inverts: instead of impressing a stranger, show a known reader that
each demanded change exists. Keep new text visually traceable — the auxiliary
change-highlighted PDF must let a reviewer jump from issue to fix in seconds
(nsdi-author-response). Prose that quietly rewrites unrelated sections invites
re-litigation of settled points.
Figures as argument, not decoration
Because figures bill against the 12 pages, each one should be designed like a
paragraph with a topic sentence:
- Caption states the takeaway ("Leases cap retry amplification at 1.3× during all
three incident classes"), not the axes ("Latency vs. time").
- One visual idea per figure; a plot needing three sentences of legend explanation
is two plots or zero.
- CDFs for distribution claims, timelines for dynamic behavior, breakdowns for
"why" claims — the form should match the claim type (
nsdi-experiments).
- Readability at print scale: systems reviewers annotate paper printouts; 6-point
axis labels get skipped, and a skipped figure is a page of rent paid for nothing.
Self-edit checklist
Output format
[Arc check] beats 1-5 present? weakest beat + fix
[Budget] pages by section vs allocation; what to cut first
[Calibration] list of unbacked superlatives / missing percentiles
[Boundary] named failure regimes: <list or MISSING>
[Track-consistent anonymity] research-neutralized / operational-named
[Edit order] highest-leverage rewrite first
