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.

1. Hardware architecture and physical-layer contributions (beamforming,

modulation, and similar).

1. 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.

| Track | Contract with reviewers | Wrong-track failure mode |

|---|---|---|

| Research | New design + implementation + practical evaluation | Prototype thin on evaluation reads as unfinished |

| Operational systems | Real-world use of a deployed system; anonymization relaxed (system/company names may stay) | Research prototype dressed as "operational" has no experience to report |

| Frontiers | Bold, high-novelty idea; complete evaluation not required | Incremental idea with partial results reads as an excuse, not a frontier |

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