# Nsdi Topic Selection > Use when judging whether a project belongs at NSDI, picking among its research, operational-systems, and frontiers tracks, or re-routing to SIGCOMM, OSDI, SOSP, FAST, or SIGMETRICS — testing the networking-stack contribution, the CFP's out-of-scope lines, and which of the two yearly deadlines to aim at. - Skill: `thedixitjain/nsdi-topic-selection` (Agent Skill) - Install (CLI): `npx skillmds add thedixitjain/nsdi-topic-selection` - Raw SKILL.md: https://api.skillmd.com/api/skills/thedixitjain/nsdi-topic-selection/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: thedixitjain (https://skillmd.com/u/thedixitjain) - Updated: 2026-09-08 - Page: https://skillmd.com/skills/thedixitjain/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. | 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 ```text 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 ```text [NSDI fit] strong / arguable / out of scope (cite which scope clause) [Stack element changed] [Realistic traffic] [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 ``` --- **Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `NSDI-Skills/skills/nsdi-topic-selection/SKILL.md`