%%%%%%%% NSDI 2027 PAPER TEMPLATE %%%%%%%%%%%%%%%%%
%
% The 24th USENIX Symposium on Networked Systems Design and Implementation
% May 11--13, 2027, Providence, RI, USA
%
% Format: <= 12 pages (excluding references), USENIX format
%         Two-column, 10pt on 12pt leading, Times Roman
%
% Official CFP: https://www.usenix.org/conference/nsdi27/call-for-papers
% Template source: https://www.usenix.org/conferences/author-resources/paper-templates
%
% IMPORTANT NOTES:
% - Three tracks: Traditional Research, Frontiers, Operational Systems
% - Indicate track on title page and submission form
% - PRESCREENING PHASE: Reviewers read ONLY the Introduction!
%   --> Introduction must articulate ALL track-specific criteria
% - Two deadlines: Spring (April 2026) and Fall (September 2026)
% - One-shot revision available for rejected papers
%
% TRACK REQUIREMENTS (must be clear from Introduction alone):
%   Research Track:    Novel idea + evaluation evidence
%   Frontiers Track:   Novel NON-INCREMENTAL idea (less evaluation needed)
%   Operational Track: Deployment setting, scale, lessons learned
%
% PRESCREENING CRITERIA (all must be evident in Introduction):
%   1. Subject falls within NSDI scope (networked/distributed systems)
%   2. Exposition understandable by NSDI PC member
%   3. Track-specific criteria met (see above)

\documentclass[letterpaper,twocolumn,10pt]{article}
\usepackage{usenix-2020-09}

% Recommended packages for networking/systems papers
\usepackage[utf8]{inputenc}
\usepackage{amsmath,amssymb}
\usepackage{graphicx}
\usepackage{booktabs}       % Professional tables
\usepackage{hyperref}
\usepackage{url}
\usepackage{xspace}
\usepackage{subcaption}     % Side-by-side figures
\usepackage{algorithm}      % Algorithm environment
\usepackage{algorithmic}    % Pseudocode formatting
\usepackage{listings}       % Code listings
\usepackage[capitalize,noabbrev]{cleveref}  % Smart cross-references

% Code listing style
\lstset{
  basicstyle=\footnotesize\ttfamily,
  numbers=left,
  numberstyle=\tiny,
  xleftmargin=2em,
  breaklines=true,
  tabsize=2,
  showstringspaces=false,
  frame=single,
  captionpos=b
}

% Custom commands -- replace \system with your anonymized name
\newcommand{\system}{SystemName\xspace}
\newcommand{\eg}{e.g.,\xspace}
\newcommand{\ie}{i.e.,\xspace}
\newcommand{\etal}{\textit{et al.}\xspace}
\newcommand{\para}[1]{\smallskip\noindent\textbf{#1.}}
\newcommand{\parait}[1]{\smallskip\noindent\textit{#1.}}

% Networking-specific unit macros
\newcommand{\us}{\,$\mu$s\xspace}
\newcommand{\ms}{\,ms\xspace}
\newcommand{\GB}{\,GB\xspace}
\newcommand{\MB}{\,MB\xspace}
\newcommand{\Gbps}{\,Gbps\xspace}
\newcommand{\Tbps}{\,Tbps\xspace}
\newcommand{\pps}{\,pps\xspace}

\begin{document}

% Indicate your track in the title page
% Options: [Research Track] / [Frontiers Track] / [Operational Systems Track]
\title{Your Paper Title Here}

\author{Paper \#XXX}  % Anonymized for submission (double-blind)
% Operational Systems track: may keep real company/system names for context
% Camera-ready:
% \author{
%   {\rm Author One}\\
%   Affiliation One\\
%   \texttt{email@example.com}
%   \and
%   {\rm Author Two}\\
%   Affiliation Two\\
%   \texttt{email@example.com}
% }

\maketitle

%----------------------------------------------------------------------
\begin{abstract}
% Guidelines for a strong NSDI abstract:
% - State the networking/systems problem you solve
% - Explain why existing approaches fail
% - Describe your key insight and approach
% - Summarize evaluation results with concrete numbers
%
% Keep to 150--200 words. Avoid citations in the abstract.

We present \system, a [describe system] for [networked systems problem].
[Problem statement: why existing approaches fall short.]
\system exploits the insight that [key observation] to achieve [capability].
We evaluate \system on [testbed/workloads] and demonstrate [X]$\times$
improvement in [throughput/latency/etc.] compared to [baseline],
while maintaining [other desirable property].
\end{abstract}

%----------------------------------------------------------------------
\section{Introduction}
\label{sec:intro}

% ╔══════════════════════════════════════════════════════════════════╗
% ║  CRITICAL: This section is used for PRESCREENING!              ║
% ║  Reviewers will read ONLY this section to determine:           ║
% ║  1. Subject falls within NSDI scope (networked/distributed)    ║
% ║  2. Exposition understandable by NSDI PC member                ║
% ║  3. Track-specific criteria met (see header comments)          ║
% ║                                                                ║
% ║  If your Introduction doesn't clearly articulate these,        ║
% ║  your paper WILL be rejected in prescreening.                  ║
% ╚══════════════════════════════════════════════════════════════════╝
%
% Recommended structure:
% 1. Problem context in networked/distributed systems (1--2 paragraphs)
% 2. Why existing solutions are insufficient (1 paragraph)
% 3. Key insight and approach overview (1 paragraph)
% 4. Contributions list (bulleted)
% 5. Results highlights with concrete numbers (1 paragraph)

The rapid growth of [networked systems context]~\cite{jain2013b4} has
created new challenges for [problem area]. Existing solutions such as
[prior work]~\cite{alizadeh2010dctcp} are designed for [assumption],
but modern networks require [new capability].

\para{Key Insight}
We observe that [insight about network behavior/workload pattern].
This observation enables \system to [capability].

We make the following contributions:
\begin{itemize}
  \item We characterize [problem] through measurements of [N]
        production [network/cluster] traces (\cref{sec:background}).
  \item We design \system, a [type of system] that leverages
        [technique] to achieve [goal] (\cref{sec:design}).
  \item We implement \system as a [module/protocol/service] with
        [X] lines of [language] (\cref{sec:implementation}).
  \item We evaluate \system on [testbed] with [workloads] and
        show [X]\% improvement in [metric] over state-of-the-art
        (\cref{sec:evaluation}).
\end{itemize}

%----------------------------------------------------------------------
\section{Background and Motivation}
\label{sec:background}

\subsection{Network Architecture Context}

Describe the relevant network architecture or protocol context.
Modern datacenter networks~\cite{singh2015jupiter, greenberg2009vl2}
employ [topology/protocol], which creates [challenge].

\subsection{Measurement Study}

% Concrete measurements from real traces strengthen motivation.
\Cref{fig:motivation} shows [measurement] from [N] production traces.
We identify [N] key findings:

\begin{figure}[t]
  \centering
  \fbox{\parbox{0.9\columnwidth}{\centering\vspace{3em}
    \textit{CDF or time-series plot from production trace analysis}
  \vspace{3em}}}
  \caption{[Description.] Analysis of [N] hours of production traffic
    reveals that [finding]: [X]\% of flows account for [Y]\% of bytes.}
  \label{fig:motivation}
\end{figure}

\para{Finding 1}
[First observation from trace analysis.]

\para{Finding 2}
[Second observation.] These findings motivate the design of \system.

%----------------------------------------------------------------------
\section{Design}
\label{sec:design}

\Cref{fig:architecture} presents the architecture of \system.

\begin{figure*}[t]
  \centering
  \fbox{\parbox{0.9\textwidth}{\centering\vspace{4em}
    \textit{System architecture: control plane, data plane, and their interaction}
  \vspace{4em}}}
  \caption{Architecture of \system. The control plane [function] while
    the data plane [function]. [Describe key interactions.]}
  \label{fig:architecture}
\end{figure*}

\subsection{Control Plane}

Describe the control plane design, including how decisions are made
and communicated~\cite{patel2013ananta}.

\subsection{Data Plane}

Describe the data plane design. The forwarding logic is specified
in \cref{alg:forwarding}.

\begin{algorithm}[t]
  \caption{Packet processing in \system}
  \label{alg:forwarding}
  \begin{algorithmic}[1]
    \STATE \textbf{Input:} packet $p$, flow table $F$, policy $\pi$
    \STATE \textbf{Output:} forwarding action $a$
    \STATE $f \leftarrow \text{FlowLookup}(p.\text{header}, F)$
    \IF{$f \neq \text{null}$}
      \STATE $a \leftarrow f.\text{action}$ \COMMENT{cache hit}
    \ELSE
      \STATE $a \leftarrow \pi.\text{Decide}(p)$ \COMMENT{policy lookup}
      \STATE $F.\text{Insert}(p.\text{header}, a)$
    \ENDIF
    \IF{$a.\text{type} = \text{ECMP}$}
      \STATE Select path based on flowlet gap: $\Delta t > \delta$
    \ENDIF
    \STATE \textbf{return} $a$
  \end{algorithmic}
\end{algorithm}

\subsection{Protocol Design}

The bandwidth allocation can be modeled using the max-min fairness
formulation:
\begin{equation}
  \label{eq:fairness}
  \max \min_{i \in \mathcal{F}} \frac{x_i}{w_i}
  \quad \text{s.t.} \quad
  \sum_{i: e \in p_i} x_i \leq c_e, \;\; \forall e \in \mathcal{E}
\end{equation}
where $x_i$ is the rate of flow $i$, $w_i$ is its weight, $p_i$ is
its path, $c_e$ is the capacity of link $e$, and $\mathcal{E}$ is
the set of all links.

\subsection{Handling Failures}

Describe fault tolerance mechanisms. \system handles [failure types]
through [mechanism], achieving [recovery time].

%----------------------------------------------------------------------
\section{Implementation}
\label{sec:implementation}

We implement \system in [X]K lines of [language].

\para{Switch Integration}
[Describe integration with switch hardware/software.]

\para{Host Agent}
[Describe the host-side component.]

\para{Controller}
[Describe the centralized/distributed controller.]

%----------------------------------------------------------------------
\section{Evaluation}
\label{sec:evaluation}

We evaluate \system to answer the following questions:
\begin{enumerate}
  \item Does \system improve [throughput/FCT/latency] over baselines?
  \item How does \system perform under different traffic patterns?
  \item What is the overhead of \system?
  \item How does \system handle failures?
\end{enumerate}

\subsection{Experimental Setup}
\label{sec:eval:setup}

\para{Testbed}
We deploy \system on a [topology] testbed with [N] servers and [M]
switches, connected via [link speed] links.

\para{Traffic Workloads}
We use traffic patterns from [source]~\cite{alizadeh2010dctcp}:
(1)~web search, (2)~data mining, and (3)~cache follower.
\Cref{tab:workloads} summarizes their characteristics.

\para{Baselines}
We compare against:
(1)~ECMP~\cite{hopps2000rfc},
(2)~[Protocol B]~\cite{jain2013b4}, and
(3)~[Protocol C].

\begin{table}[t]
  \caption{Traffic workload characteristics. Flow sizes follow
    the distributions from production datacenter traces.}
  \label{tab:workloads}
  \centering
  \begin{small}
  \begin{tabular}{@{}lrrl@{}}
    \toprule
    \textbf{Workload} & \textbf{Avg Size} & \textbf{Load} &
    \textbf{Distribution} \\
    \midrule
    Web Search   & 1.6\,KB  & 50\%  & Heavy-tailed  \\
    Data Mining   & 7.4\,KB  & 70\%  & Bimodal       \\
    Cache Follow  & 0.4\,KB  & 30\%  & Mostly small  \\
    ML Training   & 128\,MB  & 80\%  & All-to-all    \\
    \bottomrule
  \end{tabular}
  \end{small}
\end{table}

\subsection{Flow Completion Time}
\label{sec:eval:fct}

\Cref{tab:fct} shows flow completion times (FCTs) across workloads.
\system reduces the average FCT by [X]\% and the 99th-percentile
tail FCT by [Y]\% compared to [best baseline].

\begin{table}[t]
  \caption{Flow completion time comparison (normalized to ECMP).
    Lower is better. Bold indicates best result.}
  \label{tab:fct}
  \centering
  \begin{small}
  \begin{tabular}{@{}lcccc@{}}
    \toprule
    & \multicolumn{2}{c}{\textbf{Web Search}} &
      \multicolumn{2}{c}{\textbf{Data Mining}} \\
    \cmidrule(lr){2-3} \cmidrule(lr){4-5}
    \textbf{System} & \textbf{Avg} & \textbf{p99} &
    \textbf{Avg} & \textbf{p99} \\
    \midrule
    ECMP             & 1.00          & 1.00          & 1.00 & 1.00 \\
    Baseline B       & 0.85          & 0.78          & 0.88 & 0.82 \\
    Baseline C       & 0.82          & 0.71          & 0.84 & 0.75 \\
    \textbf{\system} & \textbf{0.68} & \textbf{0.52} & \textbf{0.72} & \textbf{0.58} \\
    \bottomrule
  \end{tabular}
  \end{small}
\end{table}

\subsection{Throughput Under Load}
\label{sec:eval:throughput}

\Cref{fig:throughput} shows aggregate throughput as network load
increases from 10\% to 90\%.

\begin{figure}[t]
  \centering
  \fbox{\parbox{0.9\columnwidth}{\centering\vspace{3em}
    \textit{Line chart: throughput vs.\ network load (10\%--90\%)}
  \vspace{3em}}}
  \caption{Aggregate throughput vs.\ network load. \system maintains
    [X]\% of bisection bandwidth at 80\% load, compared to
    [Y]\% for [baseline].}
  \label{fig:throughput}
\end{figure}

\subsection{Failure Recovery}
\label{sec:eval:failure}

We evaluate recovery time by failing [N] links during peak load.
\system recovers within [X]\ms, compared to [Y]\ms for [baseline].

\begin{figure}[t]
  \centering
  \fbox{\parbox{0.9\columnwidth}{\centering\vspace{3em}
    \textit{Time-series: throughput drop and recovery after link failure}
  \vspace{3em}}}
  \caption{Failure recovery. \system detects the failure within [X]\us
    and reroutes affected flows within [Y]\ms.}
  \label{fig:failure}
\end{figure}

%----------------------------------------------------------------------
\section{Discussion}
\label{sec:discussion}

\para{Deployment Considerations}
[Discuss practical deployment aspects.]

\para{Limitations}
[Honestly discuss limitations.]

%----------------------------------------------------------------------
\section{Related Work}
\label{sec:related}

% Organize by theme, clearly distinguish your work.

\para{Datacenter Transport Protocols}
DCTCP~\cite{alizadeh2010dctcp} and its successors address [aspect].
\system differs by [distinction].

\para{Traffic Engineering}
B4~\cite{jain2013b4} and Jupiter~\cite{singh2015jupiter} optimize
[aspect]. \system complements these by [distinction].

\para{Load Balancing}
[Other approaches]~\cite{hopps2000rfc, patel2013ananta} provide
[capability]. \system extends this with [technique].

%----------------------------------------------------------------------
\section{Conclusion}
\label{sec:conclusion}

We presented \system, a [type of system] that [key capability].
By exploiting [insight], \system achieves [X]$\times$ improvement
in [metric] over state-of-the-art. Our evaluation on [testbed]
with [workloads] demonstrates [key results].

%----------------------------------------------------------------------
{\footnotesize \bibliographystyle{acm}
\bibliography{references}}

\end{document}
