nsdi-topic-selection

NSDI Topic Selection

Venue choice at NSDI is a scope question before it is a quality question. The notes below reflect the NSDI '27 Call for Papers as rendered on 2026-07-08; the scope paragraph, track list, and exclusions are rewritten each edition, so reread usenix.org/conference/nsdi27/call-for-papers before committing a team to a deadline.

The scope sentence that decides most cases

The CFP's negative space is unusually explicit. Three families are declared out of scope regardless of quality:

1. Work with no contribution to the design of networked systems or the networking stack — a distributed application that merely uses the network is not enough.
2. Hardware architecture and physical-layer contributions (beamforming, modulation, and similar).
3. Sensing and localization work.

The positive test is the venue's full name: design principles, implementation, and practical evaluation of networked and distributed systems. Ask: which layer of a networked system does this change, and what realistic traffic has been pushed through the change? If neither clause has an answer, no amount of polish fixes the fit.

Three tracks, three evidence contracts

NSDI '27 reviews three tracks; the choice is made at submission and sets the bar the paper is judged against.

The frontiers track is the newest lever: it exists precisely for work that fails the research track's evaluation bar because the idea is early, not because the experiments were skipped. Do not use it to launder an under-evaluated conventional design.

Routing among the siblings

Where does the center of gravity sit?  (verify each venue's live CFP)
network/distributed system, built + measured      -> NSDI (research)
deployed at scale, lessons are the contribution   -> NSDI (operational systems)
early, reshapes how a problem is framed           -> NSDI (frontiers)
protocol/measurement result, networking community
  but no built-system requirement                 -> SIGCOMM
host OS, runtime, or kernel is the object         -> OSDI / SOSP
storage stack end to end                          -> FAST
performance modeling / queueing analysis          -> SIGMETRICS
mobile/wireless system with PHY entanglement      -> MobiCom (PHY itself: out of NSDI scope)

The NSDI/OSDI boundary is the one most often argued. Both are USENIX systems venues, but they cut the stack differently: when the network or the distributed coordination is the object of design, the work is NSDI's; when the host — kernel, scheduler, memory, storage — is the object and the network is plumbing, it is OSDI/SOSP material. A useful probe: delete the multi-node aspect from the evaluation. If the contribution survives on one machine, NSDI reviewers will notice too.

The NSDI/SIGCOMM boundary is cultural as much as topical: overlapping communities, but NSDI expects a built system whose design is validated end to end, while a measurement-only or protocol-analysis paper without an implementation story travels better to SIGCOMM. ML topics cut both ways at NSDI: systems for ML and ML for systems are named in scope, but a paper whose delta is model accuracy has left the venue.

Calendar as a routing input

NSDI's two deadlines per edition change the routing calculus in ways single-deadline siblings cannot match. As of 2026-07-08:

• NSDI '27 spring deadline (papers April 23, 2026) has passed; notification lands July 23, 2026.
• NSDI '27 fall deadline is open: abstracts September 10, papers September 17, 2026 (11:59 pm US EDT).

Consequences worth planning around: a near-ready project can target September rather than waiting most of a year; a spring submission that draws a one-shot revision gets a structured second life at a later deadline (nsdi-review-process); but a spring rejection without revision locks the paper out of the fall deadline — so submitting a half-built system "to get feedback" costs a real option. Eight submissions per author is the cap across both deadlines.

Borderline cases, adjudicated

Recurring gray zones and how the scope sentence resolves them:

• ML training/serving system: in scope when the contribution is communication, placement, or coordination across machines ("systems for ML"); out when the delta is model quality with a distributed backdrop.
• Measurement study: strong at NSDI when it ends in a design consequence — a mechanism, defense, or operator-actionable finding; measurement without consequence travels better to IMC.
• Single-host networking stack (kernel bypass, NIC offload): genuinely contested territory with OSDI; NSDI-favored when end-to-end, multi-node behavior is the object of evaluation.
• Wireless system: in scope above the physical layer; the moment the contribution is beamforming or modulation, the CFP's exclusion applies.

Fit probes before committing a deadline

• Name the networking-stack or distributed-design element that is new. One sentence, no adjectives.
• Name the realistic traffic: which trace, testbed, or deployment exercises the design? "We will find a workload later" means the fall deadline, not this one.
• Name the operational constraint the design respects (failure domains, incremental deployability, tail behavior) — NSDI's reviewer culture reads for these.
• Confirm the honest track. Deployment stories need a deployment; frontiers ideas need genuine novelty, not missing baselines.
• Check the exclusion list once more — sensing/localization and PHY work get desk attention, not sympathy.

Output format

[NSDI fit] strong / arguable / out of scope (cite which scope clause)
[Stack element changed] <one sentence>
[Realistic traffic] <trace / testbed / deployment named, or "missing">
[Track] research / operational / frontiers (why this contract)
[Deadline math] fall '26-09-17 vs next spring; option cost if rejected
[Re-route] SIGCOMM / OSDI / SOSP / FAST / SIGMETRICS / MobiCom + reason