nsdi-topic-selection
GitHub辅助判断论文是否适合NSDI会议，识别研究、运维、前沿三个轨道，并指导路由至SIGCOMM、OSDI等兄弟会议。基于CFP范围与排除项，评估网络系统贡献及提交截止日期。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill nsdi-topic-selection -g -y
SKILL.md
Frontmatter
{
"name": "nsdi-topic-selection",
"description": "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."
}
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:
- 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.
- Hardware architecture and physical-layer contributions (beamforming, modulation, and similar).
- 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
Version History
- 9f86f09 Current 2026-07-19 17:07
